Review Request 128202: Fix problem with install prefix & application bundles

Sat Jun 18 12:10:54 UTC 2016

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote:
> > AFAIK emerge is not an OS X utility, but something ported from elsewhere. Does it use `-DBUNDLE_INSTALL_DIR` and if not, why?
> > 
> > A few remarks re: kded5. AFAICT this is one of those things that should *not* 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 *not* be run independently by each and every standalone application that needs them?!).
> > 
> > The second approach concerns all services that are to be auto-started using `.desktop` 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 `PATH` as the very first thing when starting up, or even before that by using a wrapper script as the `BundleExec`.
> 
> Christoph Cullmann wrote:
>     For the bundle dir, see my response below, for kded5: actually, thou shall not use it on mac nor windows.
> 
> René J.V. Bertin wrote:
>     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?
> 
> Christoph Cullmann wrote:
>     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.
> 
> David Faure wrote:
>     ksycoca doesn't require kded anymore, the functionality is entirely contained in the kservice module.
>     
>     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.
> 
> René J.V. Bertin wrote:
>     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.
> 
> René J.V. Bertin wrote:
>     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 *dass ist verboten* 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".
>     
>     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.

Sorry for my rapid firing on this ticket.

> The current strategy seems to be that KIO is not really needed for Windows / OSX app bundles

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.

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128202/#review96661
-----------------------------------------------------------

On June 18, 2016, 12:38 p.m., Christoph Cullmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128202/
> -----------------------------------------------------------
> 
> (Updated June 18, 2016, 12:38 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Alex Merry, and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   kde-modules/KDEInstallDirs.cmake f518a4a 
> 
> Diff: https://git.reviewboard.kde.org/r/128202/diff/
> 
> 
> Testing
> -------
> 
> emerge okular works a bit more with this patch, e.g. kde4support is able to detect kded5.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160618/3782a216/attachment.html>