[KDE/Mac] Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

Sat Jan 2 14:21:36 UTC 2016

> 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://test@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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20160102/ec4fdaf8/attachment.html>