[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[David Faure]

On Sunday 04 January 2015 16:35:09 Ian Wadham wrote:
> Hi Jeremy, David and René,
> 
> On 04/01/2015, at 9:57 AM, Jeremy Whiting wrote:
> > In trying this I think we have a couple of options as Rene pointed out.
> > 
> > 1. Support reading XDG_CONFIG_DIRS

and XDG_DATA_DIRS, which is the most important one. I can easily add that to 
my patch, it's in the code I took this from.

> > 2. Support some compiled in or runtime programatically added alternative
> > path(s)
> > 
> > 1 would certainly be much faster and would fix the CI systems and building
> > with kdesrc-build on mac (and a similar approach could be done on
> > windows), but has the drawback of using environment variables, which
> > would need to also be set by applications when launching them. This seems
> > like a big drawback imo. 

Unless there's a "post install" script that adds the env vars to the user's 
environment. That's how things work on Windows.

The Linux way for binary packages is to install them into a standard path that 
doesn't require env vars (/usr), and my patch was trying to do the same by 
using /opt/local as such a standard path. But since MacPorts apparently offers 
the user to use any prefix of their choice, this isn't enough. So in the end 
MacPorts seems to be closer to the Windows way (choose your install path, 
we'll take care of making it work) than the Linux way (binary packages go into 
a predefined standard install path).


> I have done a bit of digging around.
> 
> a) http://lxr.kde.org/ident?v=kf5-qt5&_i=QStandardPaths&_remember=1 already
>     returns "3442 references in 857 files" to QStandardPaths.  More will be
> added... 

So? This is a fact, but I'm not sure which conclusions you're drawing from it.
If you're saying "bad, we'll affect all this code and that's risky", then I 
would disagree. The fact that it's very much used means that the changes will 
be used consistently, which is a good thing.

> b) References occur from all over Frameworks and KF5, not just GUI
> apps. 

Certainly.

> c) There should be a way to get a KDE app to recognise itself as a
> KDE app

I strongly disagree.
One of the main goals of KF5 is to kill the distinction between a KDE app and 
a Qt app, especially from a technical point of view.

It's all Qt apps now.
It's just that some apps use additional libraries.

If you take a Qt-only app and make it use one framework, does that make it a 
KDE app in your view? My answer: the question makes no sense, there is no such 
thing as a "KDE app" from a technical point of view.
At best, one can call a "KDE app" an "application produced by the KDE 
community", but surely who is the author of an app shouldn't make any 
technical difference on how Qt behaves.

In fact this issue affects applications not made by the KDE community too.
Imagine, say, Scribus, or the apps you mentionned, QGIS and GRASS,
using QMimeType.
If you install these apps via MacPorts, say into /opt/local (or worse, in any 
prefix of your choice), and they install files under ${prefix}/share, and try 
to look them up with QSP (GenericDataLocation), THIS WILL NOT WORK.

So either
1) they put files under /Library
or 
2) they currently don't use QStandardPaths to look up these files.

Fixing QSP would *help* these apps, I'm pretty sure.

So let's forget about "KDE apps", please. This is about making QSP work with 
the MacPorts directory layout. It will benefit "apps produced by the KDE 
community", but not only these, from what I understand of the way MacPorts 
works.

> , by using a setting introduced via the Info.plist template [1]. 
> Notably, there is supposed to be a LSEnvironment property via which you can
> set environment variables on a per-run basis [2].  But I have not been able
> to get this working yet (testing with qgetenv()).  OTOH you can define your
> own Custom Keys and values (see also [1]) and read their values via
> Objective-C code as in [3]. d) I have not tried this yet, but presumably
> qstandardpaths_mac.mm could test such a value, the first time it is called,
> to see if it has been called within a KDE app.  THEN QSP could set XDG_*
> environment variables, or whatever, if not already set externally.  Such a
> Custom Key could even have a value based on the MacPorts installation
> prefix (the one whose default is /opt/local).

I have nothing against this solution, as long as you replace "KDE app" with 
"MacPorts app expecting a XDG-like directory layout" (prefix/share, 
prefix/etc.).

Whether that's all MacPorts apps or just a few, I don't know.
But if MacPorts is about bringing FOSS from the Linux/BSD world to Mac, then 
I'm pretty sure they all expect a XDG-like directory layout, and therefore 
that definition above can be simplified to "MacPorts apps".

> e) Note that kdeinit4 and
> kded4 (and one or two others) are built as pseudo GUI apps on Apple OS X,
> because they may have to execute real GUI apps. So perhaps such apps could
> spread the word, via the Shell, to whatever non-GUI things they may start,
> such as kbuildsycoca or KIO processes. 

No, no, please not. This is monolithic thinking.
One should be able to start an application directly, without either kdeinit4 
or kded4 running.

If Scribus decides to use KConfig, it should be able to find files in 
/opt/local/etc/xdg, whichever way it's started.
Or better example, if it decides to use Sonnet, it should be able to find
the file that sonnet itself installs under /opt/local/kf5/sonnet/, whichever 
way the app is started. This should work for any application using sonnet, not 
just "apps produced by the KDE community".

> f)[...] maybe they would need to be hand-coded to
> tell QStandardPaths to adopt XDG behaviour. 

See? That's exactly what we can't do. Should the sonnet documentation say "if 
you want to use this library, please also remember to call 
QStandardPaths::enableXdgMode(true)" ? (or any other manual per-app setting).
Ouch!

My suggested solution is rather that QSP always adds MacPorts paths to its 
search paths, whether it finds these from an env var or a config file.

If there's some sort of "registry" (.plist files or whatever the format may 
be) where MacPorts could write out the prefix(es) it's using to install apps, 
then QSP could read that and add theses prefixes to its search paths.

The alternative: Qt is documented to find stuff in the default MacPorts prefix 
(/opt/local) automatically, advanced users who want to use another path have 
to set XDG_* env vars.

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