'Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead'

[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;">
 On December 2nd, 2015, 7:51 a.m. UTC, David Faure wrote:
 <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;">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.</pre> </blockquote>

On December 2nd, 2015, 8:45 a.m. UTC, René J.V. Bertin wrote:
 <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;">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. 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. 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. 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?</pre> \
</blockquote>

On December 6th, 2015, 2:51 p.m. UTC, David Faure wrote:
 <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;">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 ?</pre> </blockquote>

On December 25th, 2015, 8:49 p.m. UTC, René J.V. Bertin wrote:
 <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;">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.</pre> </blockquote>

On December 25th, 2015, 9:48 p.m. UTC, David Faure wrote:
 <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;">I don't understand what you're \
saying. kded5 isn't starting any other processes, is it?</pre> </blockquote>

On December 25th, 2015, 9:56 p.m. UTC, René J.V. Bertin wrote:
 <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;">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.</pre> </blockquote>

On January 2nd, 2016, 11:45 a.m. UTC, David Faure wrote:
 <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;">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.</pre> </blockquote>

On January 2nd, 2016, 12:35 p.m. UTC, René J.V. Bertin wrote:
 <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;"> If a user wants to prepare the runtime \
infrastructure, he/she should run kdeinit5, not kded5. </blockquote>
The thing with that is that s/he would then have to launch 2 applications. \
<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;"> Apps started \
standalone, who then make a dbus call to kded might indeed start kded first </blockquote>
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. 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?</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;">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 <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).</pre>

<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] 