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

[David Faure]

On Friday 25 September 2015 14:09:14 René J.V. Bertin wrote:
> 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).

Yes that was clear and on purpose.
The intent was not to use XDG-like directories on all platforms, but rather to "do what the platform recommends/forces us to do" - which is QSP.

You don't *really* need XDG on OSX. You need files to be found, it's just easier to do that by coying what we do on Linux/BSD ;)

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

That is KStandardDirs, and I certainly do NOT want to bring that back. It would go exactly against "all apps use the same conventions"
because apps using QSP and apps using KStandardDirs would do things differently. And because it assumed XDG layout everywhere,
which looks strange on OSX, looks a lot stranger on Windows, and is just not allowed on Android or iOS.
 
> > 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.

I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from KF5, say KTextEdit, and my users lost
all of their previous configuration because this brought in kcoreaddons, which toggled a global switch in QSP!!! You guys suck!!!" :-)

> > 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 ;)

Hidden magic is good because it's hidden so people won't break it? I can't agree to this line of argumentation.
Hidden magic is *usually* bad because it fools expectations. And on top of that, it can still be broken - unknowingly - because it's so hidden.
Anyway, meta discussions won't help, let's dive into specifics again ;)

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

Sure, unittests are easy (self contained), whichever solution we end up with.

> > .... which means the suggested solution here would break third-party libs which
> > install 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...

Hmm. You envision a world where a single packaging system controls all the Qt based libs.
I suppose this is the case for Macports (and its alternatives like Fink, assuming people can't
mix-n-match between the two)? Or can an app in Macports link to a lib from the "real" OSX
(I guess I mean for instance /Library)?


If indeed this is about a self-contained world where all libs and apps should use the same paths,
then we're back to the easiest solution: a Qt patch for Macports.
Or the equivalent, an upstream Qt change which is enabled when configuring Qt for Macports.

If however this is about a mix-and-match world where some libs install files into XDG-like paths
and some other libs install files into OSX-like paths, and some apps link to both of these libs,
then neither a compile-time Qt patch nor your idea of a per-app behavior switch would work.
Only a per-call solution would work.


I see in your followup that you want to be able to link to Qt from OSX (when I say that, I mean outside
Macports), so it's not a fully self-contained world. But why do you want to be able to link with Qt from
OSX but not with Qt-based libs from OSX? (I'm saying you're excluding that case because of your
line above, "the packagers must ensure all libs are patched too"). That only works if all libs are
from Macports, surely.

> > 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).

That doesn't mean it's not the right solution. It's all a matter of describing correctly the problem,
for people who know less about e.g. Macports.

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

A little bit too much magic for me, and I suspect for Qt devs as well.
I could even imagine a case where an app would want per-call choice: if you want to
use shared-mime-info from /usr/share/mime but still to save configuration into ~/Library/Preferences?
Don't know if that makes sense.

> There's a problem with that approach, though: Qt itself uses QSP

Yes but that is a feature, not a bug :)
Here's what I mean, in more details.

There are two use cases for QStandardPaths (Config and Data locations, the rest is trivial).

Case 1: a library installs a file in e.g. share/kxmlgui5/katepart/katepart5ui.rc and wants to be
able to find it again at runtime. In that case, you certainly don't want some app toggling the behavior
of QSP for that library to something else than what it expected, it wouldn't be able to find the file again.
This argument of course assumes that there are Qt-based libs on OSX right now which install files
into "native OSX" paths, and which would be broken by a switch to XDG paths like the one above.
I don't know if such libs exist, but we can't assume they don't, and break them out of ignorance.

Case 2: writing and reading user-specific files, into writableLocation(). This matters a lot less IMHO.
Whether you save stuff into ~/.config or ~/Library/Preferences, you can find it again later as long
as nobody changes QSP behavior on you.
The qlogging.ini file that Qt is looking up falls into this category, it's a user file, not a file installed by Qt.
However it could be considered confusing if you install *one* Qt on OSX, set up a qlogging.ini file for it
(in ~/Library/Preferences), and it works for your OSX apps, but not for your Macports apps because
they toggle QSP behavior *globally* so these apps are looking for this file in ~/.config.
This is an argument in favour of a per-call switch! Qt using Native would keep it looking into the same
location, no matter where apps want to save config files.


I would just like to take one step back and make sure this is going into a direction that makes sense.
Let's assume you can toggle QSP behavior to XDG somehow (per call or globally or whatever).
What then? Macports users will have to set XDG_* env vars for the apps to work? I thought
setting env vars wasn't an option?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5