[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead
From: "David Faure" <faure () kde ! org>
Date: 2016-01-02 13:05:22
Message-ID: 20160102130522.30660.6109 () mimi ! kde ! org
[Download RAW message or body]
--===============4006296567960054975==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Dec. 2, 2015, 7: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?
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).
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126170/#review89022
-----------------------------------------------------------
On Dec. 25, 2015, 9: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, 9: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
>
>
--===============4006296567960054975==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/126170/">https://git.reviewboard.kde.org/r/126170/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On December 2nd, 2015, 7:51 a.m. UTC, <b>David \
Faure</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Please kind in mind that kded must be able to pop up \
dialogs, though. (cookie dialog, SSL cert messagebox + dialog, etc. etc.).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If making it an "agent" doesn't prevent it from \
showing GUI elements now and then, then no problem.</p></pre> </blockquote>
<p>On December 2nd, 2015, 8:45 a.m. UTC, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">With \
the earlier approach of setting <code style="text-rendering: inherit;color: \
#4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">LSUIElement</code> that is guaranteed to be the case.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I just checked; launching Qt's Assistant with <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1</code> 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.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">IOW, I'm not really sure I understand why kded5 doesn't retain that \
presence with <code style="text-rendering: inherit;color: #4444cc;padding: \
0;white-space: normal;margin: 0;line-height: \
inherit;">QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM</code> 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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">OTOH: the only dialogs I have seen \
under KDE4 that are related to kded (unknown cert) were posted when kded4 was <em \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">not</em> running. Ditto for cookie related things. Under what circumstances \
is kded supposed to present a GUI?</p></pre> </blockquote>
<p>On December 6th, 2015, 2:51 p.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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 \
?</p></pre> </blockquote>
<p>On December 25th, 2015, 8:49 p.m. UTC, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If kded5 is used to start kdeinit5 for instances, \
everything launched through there will launch in the background.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">So I'm going to go back to the original proposition, because an LSUIElement \
app is exactly what kded ought to be.</p></pre> </blockquote>
<p>On December 25th, 2015, 9:48 p.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
don't understand what you're saying. kded5 isn't starting any other processes, is \
it?</p></pre> </blockquote>
<p>On December 25th, 2015, 9:56 p.m. UTC, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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?</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">NB: starting kded5 \
through kdeinit5 does <em style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">not</em> work on OS X. I've had a quick \
look to understand why, but quickly gave up due to the complexity of the \
code.</p></pre> </blockquote>
<p>On January 2nd, 2016, 11:45 a.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On January 2nd, 2016, 12:35 p.m. UTC, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">If a user wants to prepare the runtime infrastructure, he/she should run \
kdeinit5, not kded5.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">The thing with that is that s/he would then have to \
launch 2 applications.</p> <blockquote style="text-rendering: inherit;padding: 0 0 0 \
1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: \
inherit;"> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Apps started standalone, who then make a dbus call to \
kded might indeed start kded first</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If that is also how <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">kdeinit5 --kded</code> 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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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?</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">dbus \
starting async is an issue no matter what, but unrelated to which process starts all \
this.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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 \
<code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">qdbus org.kde.kded5 \
/modules/desktopnotifier</code> or /modules/favicons if you have libkonq installed, \
or just /org/kde/kded5 to start with).</p></pre> <br />
<p>- David</p>
<br />
<p>On December 25th, 2015, 9:14 p.m. UTC, René J.V. Bertin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for KDE Software on Mac OS X and KDE Frameworks.</div>
<div>By René J.V. Bertin.</div>
<p style="color: grey;"><i>Updated Dec. 25, 2015, 9:14 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kded
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">There should be no reason to build <code \
style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: \
0;line-height: inherit;">kded5</code> as an app bundle on OS X, and with recent \
feedback in mind I postulated that marking it "nongui" (<code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">ecm_mark_nongui_application</code>) would be acceptable on other platforms \
too.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Additionally, <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">kded5</code> 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.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 \
.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/CMakeLists.txt <span style="color: grey">(5e95df8)</span></li>
<li>src/kded.cpp <span style="color: grey">(c7fdfee)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/126170/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============4006296567960054975==--
[Attachment #3 (text/plain)]
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic