<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/128202/">https://git.reviewboard.kde.org/r/128202/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 18th, 2016, 11:17 a.m. CEST, <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;">AFAIK emerge is not an OS X utility, but something ported from elsewhere. Does it use <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">-DBUNDLE_INSTALL_DIR</code> and if not, why?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">A few remarks re: kded5. AFAICT this is one of those things that should <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">not</em> be installed by each and every application somewhere in its appbundle. I don't think it'd work to run multiple instances of it?
As to finding it: there are 2 ways to address that particular issue. First, kded5 probably ought to be built as a non-app-bundle agent (https://git.reviewboard.kde.org/r/126170/ and the associated https://git.reviewboard.kde.org/r/126161/; kdeinit5/klauncher should probably also <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">not</em> be run independently by each and every standalone application that needs them?!).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The second approach concerns all services that are to be auto-started using <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">.desktop</code> files or equivalent: those files need to be rewritten so that their Exec key contains an appropriate value. In standalone app bundle builds this could of course also be handled by amending <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">PATH</code> as the very first thing when starting up, or even before that by using a wrapper script as the <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">BundleExec</code>.</p></pre>
</blockquote>
<p>On June 18th, 2016, 11:37 a.m. CEST, <b>Christoph Cullmann</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;">For the bundle dir, see my response below, for kded5: actually, thou shall not use it on mac nor windows.</p></pre>
</blockquote>
<p>On June 18th, 2016, 12:06 p.m. CEST, <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;">It's you who brought up kded5, and please know what you're talking about before making statements like that (better yet, do not make them at all unless they have a salient emoticon). There are things kded5 does that are going to be required on MS Windows and OS X too until they're migrated away from kded, like cookie management for instance. Maybe we shouldn't use sycoca5 on our platforms either, or any KDE application that depends on the Kded framework?</p></pre>
</blockquote>
<p>On June 18th, 2016, 12:17 p.m. CEST, <b>Christoph Cullmann</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;">kded5 was just an example, I should pick my examples better it seems.
The same happens with other stuff that goes there.
And no, I keep my position: Thou shall not use kded5 on Windows nor Mac for ported stuff. And yes, that is work. But e.g. KDevelop, Kate, Krita, ... seem to work just fine without it beside some minor regressions.</p></pre>
</blockquote>
<p>On June 18th, 2016, 12:22 p.m. CEST, <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;">ksycoca doesn't require kded anymore, the functionality is entirely contained in the kservice module.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">kcookiejar is still a kded module but I plan to make it a kiod module. Not much difference though (apart from dependencies), it'd still require DBus. The current strategy seems to be that KIO is not really needed for Windows / OSX app bundles. I hope we can find solutions though, but it doesn't seem to be a priority.</p></pre>
</blockquote>
<p>On June 18th, 2016, 1:01 p.m. CEST, <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;">If kded5 becomes unnecessary that's fine ... and statements like "thou shalt not use it" becomes the BS I already consider it to be and to which I'm so allergic.</p></pre>
</blockquote>
<p>On June 18th, 2016, 1:41 p.m. CEST, <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;">This may be cultural and probably not very PC (but it's been simmering for quite a while).
When I mention allergic above I think that in fact what's going on is that statements that reek of <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">dass ist verboten</em> are still kind of delicate to make for certain parts of, ahem, the rest of the world.
Rephrase that as "you're not really supposed to" or "we don't support that", and the effect changes to something like "ok, we'll support it ourselves, just please try not to make that any more difficult than necessary".</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Extreme example: running a full Plasma session on OS X. That's a rather futile endeavour if we're talking about using the Cocoa QPA, but if someone wants to try, why forbid it? Let them, they're on their own but should they manage they might actually cater to a (possibly growing) minority of users who're unhappy of where Apple are taking OS X (pardon, "macOS"). I strongly doubt that would get Apple and KDE on a collision course...
And of course it's a very different thing if we're talking about using the Xcb QPA -- Qt do seem to be open to considering official support for a "Qt/X11" build on OS X because they acknowledge there is a market for that.</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;">Sorry for my rapid firing on this ticket.</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;">The current strategy seems to be that KIO is not really needed for Windows / OSX app bundles</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I guess I should check with the KDEvelop people, but I see quite a few kioslaves being spawned by KDevelop. What's the real problem with KIO, that it depends on kdeinit5/klauncher or that it requires (lots of) separate, external modules and helper applications? As I just posted on my kinit/OS X RR, it might (should?) be possible to refactor things in such a way that kdeinit5 and klauncher are no longer required as separate agents. From what I understand they exist as such in an attempt to cache KDE's shared libraries in a central server process, and thus speed up application launch. That's a moot point on OS X where fork/exec is used; fork/exec' is something that could just as well be done by the requesting application itself. As far as I can tell the klauncher socket used only for requests to and returns from klauncher, not for communication between the helper app (ex. kioslave) and the client.</p></pre>
<br />
<p>- René J.V.</p>
<br />
<p>On June 18th, 2016, 12:38 p.m. CEST, Christoph Cullmann 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, KDE Frameworks, Alex Merry, and David Faure.</div>
<div>By Christoph Cullmann.</div>
<p style="color: grey;"><i>Updated June 18, 2016, 12:38 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
extra-cmake-modules
</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;">Current behavior: Even if you have some own installation prefix like emerge, ECM assumes all stuff in the global /Applications/KDE
This doesn't work as stuff like kded5 is not found after installation.
Making it relative resolves this issue.</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;">emerge okular works a bit more with this patch, e.g. kde4support is able to detect kded5.</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>kde-modules/KDEInstallDirs.cmake <span style="color: grey">(f518a4a)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/128202/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>