[KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J.V. Bertin]

On Thursday September 24 2015 22:56:37 David Faure wrote:
> [warning: long, and I change my mind mid-way; I left it all so you can follow my reasoning]

Seems like a gradual change of mind :)

> If you're really only thinking of apps made by the KDE community, I would be
> surprised to see any one of them not linking to kcoreaddons.

Point is I don't know ... but it will probably be the case. Apps that link with more than just 1 or an eclectic selection of KF5 frameworks, and that (indeed) are supposed to interact with each other. That latter is the crucial bit of course: without interaction (direct IPC or indirectly via shared resources even if as trivial as icons) there is no real point in imposing specific locations that all those interacting apps agree upon. We can probably even be more selective: resources that are not part of some Freedesktop specification but are by definition/design shared *only* among KF5 applications can probably be anywhere (under a common root that can be configured, preferably) as long as it's indeed a shared location. We'll probably be excluding KDE4 applications here; if I understand correctly they can continue to work as they do currently on OS X/MacPorts since their's no Plasma desktop to comply with; as long as the KDE4 libraries and KF5 frameworks and respective other shared stuff don't enter into conflict.
(FWIW, with GUI applications being built as app bundles anyway, it ought even be possible to have, say, Kate4 and Kate5 installed in parallel.)

> I want to stay on record saying that this goes against the modularity principle
> of KF5 for other applications, of course. If someone wants to only use KItemModels,

The modularity principle for *other* applications? Does that mean that there's official leeway for, erm, non-other applications to require a common subset? 
Also, it strikes me as bit of a gamble not to have implemented a framework for dealing with what one might call Freedesktop or XDG compliance, but to have left that to QStandardPaths, basically. It must have been clear from the onset that QSP complies with Freedesktop/XDG conventions only in standard Unix/Linux Qt builds (OS X being a "deviant" Unix configuration).

I guess that outlines another possible solution: create a framework that can provide the required glue on platforms where this might be required or desired, with build switches to control optional behaviour *and* ensure that all applications still end up using the same conventions.

> So OK, kcoreaddons could switch QSP behavior on Mac, provided that
> it's documented with a huge warning, and that it can be turned off. It breaks
> the principle of least surprise ("ever since my app started using one tiny
> unrelated class out of KF5, my users lost all their previous configuration!").

This shouldn't happen when things are done correctly. The choice what locations are to be used should be made at a global level and apply for the whole installed KF5 environment. That's why I went with a link-time switch that gets set immutably when an application is loaded. It's not intended to provide things like runtime switchable configuration profiles.

> In addition to that, we should still make sure that KF5 frameworks work with
> the default Apple-conformant QSP (either because they don't link to KCoreAddons,

You yourself came up with quite a few good arguments why this would be undesirable if not impossible, but those may have been made with a coherent set of "KDE Desktop" applications in mind.

> or because someone turned off the QSP-switching), but I totally understand if you want to
> leave that to somebody else (to each man his own battle).

I might actually be tempted to participate, but only after everything works to satisfaction in my own use case scenario whatever :) I'd probably want to have an uptodate KDevelop to do that kind of work, for instance, and installed via MacPorts or Fink ;)

> Now, if a global object in kcoreaddons switches QSP behavior, how can someone
> turn that off? 

I'd argue that that shouldn't be possible, that the way the switch is flipped should be set when applications are linked, in the build system. Or in a shared header file, that'd be fine too AFAIC. Though in that case there should be a way to override the header's setting, of course. It should be fine to link an application with an explicit choice for the QSP behaviour, that seems evident.

> In details, my idea would be:
> KCoreAddons has in a cpp file: Q_CONSTRUCTOR_FUNCTION(func1) where func1 switches QSP to XDG mode.
> If an app doesn't want that: Q_CONSTRUCTOR_FUNCTION(func2) where func2 switches QSP path to OSX mode.
> If it's guaranteed that the ctor func in the app runs last we're fine. Otherwise we need a tristate logic
> (default, forcedToXDG, forcedToOSX) where kcoreaddons would say "switch to xdg unless forced to OSX").
> Any OSX linker experts around? :)

Do you have specific Linux-linker features in mind?

> The advantage of this solution compared to your initial question: no build system hackery
> (which would break the principle of least surprise even more, I would say).

What I like about a build system modification (esp. at the level of Qt component selection) is that it's done in places that aren't likely to evolve frequently. And where, if they do, people will be careful. My experience with modifying source code (e.g. to make X11 calls conditional) is that not everyone is very careful to leave such modifications in place, let alone ensure that an upstream change doesn't break them. I won't call it lack of respect, but sometimes it feels like that ;)
And that is when it's clear that the code has been made conditional on the platforms it's supposed to build on. I fear that the risk for that kind of thing will be even larger when an "exotic" platform relies on a patching mechanism to alter parts of the code that are not clearly conditional.

> 
> One thing I like about this, as a side effect, is that my unittests which need to
> have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS
> but I have to skip such unittests on OSX/Windows) could then be enabled on OSX.

You should also be able to do that with a build system modification that leaves a choice, no?

> .... which means the suggested solution here would break third-party libs which
> installed stuff into default QSP paths, and then we toggle the mode to XDG, and they
> can't find their stuff anymore...

It'd be the responsibility of packagers to ensure that those 3rd party libraries are patched too, or built with the same switch setting...

> Maybe this needs to be per-method-call then.... :
> * if libA installs stuff into XDG paths, then it would find it using QSP::locate(type, filename, XDG)
> * the alternative would be QSP::locate(type, filename, Native), which would be the default.

Funny, that was my first approach to solve the issue, and it was rejected at the time (though possibly by a Qt dev).

> This seems more correct to me after all, no? Porting the KDE code would be just running
> one perl script, don't worry about that part.

This could work though, and to avoid that perl script it could be handled purely in the QSP headerfile with a default mode option that is defined at build time; MacPorts or Fink devs could add an appropriate -DQT_USES_XDG_QSP or equivalent to their build settings, while without that the mode argument would default to Native. 

R.