> On Dec. 2, 2015, 8:51 a.m., David Faure wrote: > > Please kind in mind that kded must be able to pop up dialogs, though. > > (cookie dialog, SSL cert messagebox + dialog, etc. etc.). > > > > If making it an "agent" doesn't prevent it from showing GUI elements now > > and then, then no problem. > > René J.V. Bertin wrote: > With the earlier approach of setting `LSUIElement` that is guaranteed to > be the case. > > I just checked; launching Qt's Assistant with > `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that > the application remains in the background; it can be brought into the > foreground, and it retains its presence in the Dock and app switcher. > > IOW, I'm not really sure I understand why kded5 doesn't retain that > presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's > possible that all the env. variable does is postpone the actions that lead to > that presence. If that's true than we'd have to come back to the more > appropriate previous revision of this patch. > > OTOH: the only dialogs I have seen under KDE4 that are related to kded > (unknown cert) were posted when kded4 was *not* running. Ditto for cookie > related things. Under what circumstances is kded supposed to present a GUI? > > David Faure wrote: > Here is an easy way to test this: do the same change for kiod in kio > (it's like a mini kded) and then > cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org > should bring up a password dialog. > > Except that with Qt 5.6 from git here (from some time ago) it asserts in > DBus (looking into that now)... but hopefully you have Qt 5.5 ? > > René J.V. Bertin wrote: > OK, here's a reason NOT to use > QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: it has to be unset, and I'm > not sure when this would have to/could be done such that the variable is > picked up for kded5 itself, but not by anything that is launched subsequently. > > If kded5 is used to start kdeinit5 for instances, everything launched > through there will launch in the background. > > So I'm going to go back to the original proposition, because an > LSUIElement app is exactly what kded ought to be. > > David Faure wrote: > I don't understand what you're saying. kded5 isn't starting any other > processes, is it? > > René J.V. Bertin wrote: > kdeinit5 is auto-started as part of what I think is normal behaviour. So > if kded5 is started first, that's what starts kdeinit5. Shouldn't it? > > My reasoning here is that users might be interested in the possibility to > prepare the KDE runtime infrastructure with an inoffensive and non-invasive > daemon process that is part of the infrastructure itself. It is my experience > with KDE4/Mac that not doing so, but leaving the bootstrapping until you > start some larger and (much) more complex application (or suite; think > starting Akonadi) can lead to subtle but annoying stability issues. > > NB: starting kded5 through kdeinit5 does *not* work on OS X. I've had a > quick look to understand why, but quickly gave up due to the complexity of > the code. > > David Faure wrote: > If a user wants to prepare the runtime infrastructure, he/she should run > kdeinit5, not kded5. > kdeinit5 is the master of everything; kded is just a bunch of on-demand > services. > > Apps started standalone, who then make a dbus call to kded might indeed > start kded first, which would in turn start kdeinit. > But yeah, unset any env vars in kdeinit that shouldn't be set for the > apps it starts, that makes sense. > > René J.V. Bertin wrote: > > If a user wants to prepare the runtime infrastructure, he/she should > run kdeinit5, not kded5. > > The thing with that is that s/he would then have to launch 2 applications. > > > Apps started standalone, who then make a dbus call to kded might indeed > start kded first > > If that is also how `kdeinit5 --kded` starts kded, then that won't work. > The KDE daemon has always been tricky on OS X, and it just works best in > practice to let that application be the KDE bootstrap utility. We have to > take into consideration the fact that the session dbus itself is started > asynchronously through launchd, which makes relying on its presence (and > being operational) in order to launch other services tricky at best. > > A "bunch of on-demand services" itself started on explicit user demand > and which activates the master of everything KDE when that's necessary > (without relying on the session dbus) ... what is wrong with the KDE Daemon > being the master puppet player like that, instead of startked on full Plasma > systems? > > David Faure wrote: > Users don't have to start kded by hand, it's dbus-activated when apps > need it. Starting kdeinit is enough. In theory it's all autostarted, but I > had to start kdeinit before ctest for instance, so that ctest doesn't wait > for kdeinit to exit. > > I want kded to be less and less important in the future, it shouldn't mix > on-demand services and plasma-session startup stuff, and some of the kded > modules themselves should be turned into library code (like I did for > kbuildsycoca, next are cookies etc.). And some services should move to kiod > (like I did for kpassswdserver). Overall I don't want kded to be a required > runtime dependency. > > dbus starting async is an issue no matter what, but unrelated to which > process starts all this. > > kdeinit5 --kded isn't what I was talking about (that's only used in > startkde), but rather dbus activation of kded (which you can test with `qdbus > org.kde.kded5 /modules/desktopnotifier` or /modules/favicons if you have > libkonq installed, or just /org/kde/kded5 to start with).
This is a bit a waste of time :) I'm not proposing any changes to kded5 to support the use I see for it, other than unsetting a few env. variables (which you agreed is appropriate anyway, but even that's a moot point because I'm back to a patch where the offending variable isn't set in the first place). How we use the product is largely our affair, no? ;) - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126170/#review89022 ----------------------------------------------------------- On Dec. 25, 2015, 10:14 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126170/ > ----------------------------------------------------------- > > (Updated Dec. 25, 2015, 10:14 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kded > > > Description > ------- > > There should be no reason to build `kded5` as an app bundle on OS X, and with > recent feedback in mind I postulated that marking it "nongui" > (`ecm_mark_nongui_application`) would be acceptable on other platforms too. > > Additionally, `kded5` doesn't have any more reason to appear in the Dock or > app switcher, on OS X, so I have added the code to make it an agent. > > > Diffs > ----- > > src/CMakeLists.txt 5e95df8 > src/kded.cpp c7fdfee > > Diff: https://git.reviewboard.kde.org/r/126170/diff/ > > > Testing > ------- > > On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 . > > > Thanks, > > René J.V. Bertin > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
