[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