El divendres, 1 de març de 2019, a les 11:21:04 CET, Harald Sitter va escriure: > On Thu, Feb 28, 2019 at 8:20 PM Albert Astals Cid <aa...@kde.org> wrote: > > > > El dijous, 28 de febrer de 2019, a les 12:43:07 CET, Harald Sitter va > > escriure: > > > ...and I don't understand why > > > > > > Hi! > > > > > > this commit [1] wrapped KonfUpdate::log's update.log stream in `#if 0` > > > and thus disabling the update.log writing, replacing it with logging > > > to stderr instead. Why it does that eludes me though. It seems > > > entirely unrelated to the rest of the commit. > > > > Yep, maybe he was testing on windows, that code had issues on windows, > > disabled it for the moment and then forgot to reenable? > > > > Sound we try CC'ing Alex Richardson in case he remembers? Or you did and it > > got lost because he's on the list? > > He's in the CC of my original mail. > > > > Should the update.log writing happen? I expect this won't be super > > > reliable because I think these days the application itself forks > > > kconf_update. > > > > I don't understand what you mean with this. kconf_update has always been > > its own application as far as i know. > > I noticed KConfig::checkUpdate which would invoke the helper per > config (i.e. there could be multiple helpers running at the same time, > since checkUpdate could be called by multiple applications at the same > time) which would then cause out-of-order writes to the log from the > different inputs. Specifically it looks that the qtextstream was > buffered. After a second look checkUpdate seems to be a possibility > *in addition* to kded's global update run, my original thinking was > that the kded updating went away in favor of more atomic updating. > > I find myself agreeing with Aleix that simply using QDebug is probably > the smart way to move forward. > > Unfortunately I now have even more questions... namely: wouldn't every > application actually need to checkUpdate in case they are run in a > !plasma environment without kded? Otherwise kconf_update would never > get run. IOW: in a kde frameworks world order isn't the assumption > that kded is not running and therefore KConfig itself needs to run the > update?
Probably. The docu of KConfig::checkUpdate is kind of clear about that if you really need an update you should be using this method. A different thing is if people are reading the documentation :D Cheers, Albert > > HS >
