<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, 8:51 a.m. CET, <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, 9:45 a.m. CET, <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, 3:51 p.m. CET, <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, 9:49 p.m. CET, <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, 10:48 p.m. CET, <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, 10:56 p.m. CET, <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, 12:45 p.m. CET, <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, 1:35 p.m. CET, <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>





 <p>On January 2nd, 2016, 2:05 p.m. CET, <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;">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>
 </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;">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? ;)</p></pre>
<br />










<p>- René J.V.</p>


<br />
<p>On December 25th, 2015, 10:14 p.m. CET, 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, 10: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>