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

[Ian Wadham]

Hi Jeremy,

Thank you very much for giving some thought to this topic.

On 11/12/2014, at 4:18 AM, Jeremy Whiting wrote:
> I am probably coming at this from the wrong perspective (linux side) but I see the QSP issue as follows. On linux we have paths for standard stuff (cache, data, etc.) with defaults for each ~/.local/share/ /usr/share /usr/local/share/ for example for GenericDataLocation for example, but QStandardPaths also checks an environment variable so these defaults can be overridden (XDG_DATA_DIR for this example). On mac osx and windows this is not the case, there are defaults, but no environment variables to override the defaults. This causes a problem because the software developed for linux expects data, configs, etc. to be in these locations, but on mac osx (maybe just when using macports, but also when installing stuff into custom prefixes like /opt/local or /kde or anything non standard) the default locations aren't where the data, configs etc. are installed.
> 
> For kde software based on qt5 and kf5 this needs to be fixed, and I see two possible solutions, one of which seems like a better idea to me, but I'm not an experienced mac developer, so I would like to ask your opinion.
> 1. We patch Qt5 itself as Marko has done to look in the linux environment variable locations in addition to the standard mac paths. This seems ok to me, but feels like a workaround/hack because these environment variables are meant for XDG compliant desktop environments, not really intended for other environments (as David Faure pointed out I believe).

Firstly, I think there is a difference in *style* between Linux and OS X when it comes to installing apps.
Linux (or KDE at least) installs files into categories, such as executable, data, config, etc, each category
having its own directory tree, such as bin, share/apps, etc.  So bits of an app might be found in several 
locations, as supported by the XDG directories spec and the $XDG_* overrides of the XDG defaults.

By contrast, Apple OS X tries to get everything for an application into one place in /Applications, plus a place
to put writable stuff, such as user's config.  In theory, you should be able to uninstall an Apple or third-party
app (except for apps managed by MacPorts) by just dragging the app from /Applications to Trash.  This
worked fine for me when I uninstalled DivX… but then it went on nagging me to update it, even though it
was no longer installed… :-)  However, I soon found where those scripts were hiding… ;-)

To observe the Apple style, open Applications in the Finder, right-click on iTunes and take the "Show
Package Contents" option.  You will not see an awful lot at first, but try opening Contents->Resources
and you will see what I mean…  Everything but the kitchen sink is there.  iPhoto has a lot of stuff there
too and some extra stuff in /Library->Application Support->iPhoto.

Try the same thing with /Applications->MacPorts->KDE4-><any KDE 4 app> and you will see that Contents
contains a minimal set of files, a minimal Resources subdir and a minimal Info.plist file.  MacPorts puts the
rest of the app's files "somewhere else".

<APPDIR>/../Resources is also an option for installing additional files that come with a KDE 4 or KF 5 app,
where <APPDIR> is the directory containing the application's executable.  It is also on the list of defaults
for DataLocation in QStandardPaths (QSP) for OS X.

But I really do not think we should follow the Apple OS X installation style.  The reason is that MacPorts
tends to maintain what I think of as a "kosher kitchen", separate areas for separate types of cooking.  So
MacPorts tries to install everything it can in the /opt/local tree and NOT in /usr and /usr/local.  BTW, I am
old enough to remember when KDE used to install itself in /opt, and even old enough not to have heard
of /opt before, when I first installed KDE… :-)

MacPorts uses /opt/local mainly because OS X, being descended from Unix, has "synonyms" in /usr and
/usr/local for certain low-level libraries, utilities and include-files.  If you mix them in your build, the
results can be extremely misleading and annoying.  MacPorts prefers to build using its own versions
of said libraries, utilities and include-files (Open Source versions, which are often more recent…).

The benefits of this policy, in MacPorts, are total reproducibility of builds and dependency chains, and
complete ease of installing, deactivating and uninstalling particular applications, KDE4, KF5 or otherwise.

So this is why I support the use of Linux-like paths for KF5 and Qt5 applications and Frameworks, pace
David Faure.  I have great respect for David, but he is not God, just the god of the KDE community… :-)
What I am talking about here is a "Linux-like" implementation of QStandardPaths, but with completely
different default paths, to suit MacPorts and the MacPorts "port" of qt5-mac.  They are the paths that
should be in operation when a user clicks on the icon for a KF5 or Qt5 app.

$XDG_* values can be an added bonus, allowing geeks and MacPorts maintainers to set up versions
of apps that reference their own directories for QSP locations, much as I do now in KDE 4 with $KDEDIR
etc.  We cannot really rely on environment variables in all versions (past, present and future) of an Apple
OS X platform.  René has mentioned ~/.MacOSX/environment.plist as a way to set environment variables,
but that is deprecated in OS X 10.7 (Lion), which I have, and was dropped in OS X 10.8 (Mountain Lion).
In Lion, you do not get that file created by default.  Maybe you never did.

I googled "Apple OS X environment.plist" and got scads of hits, but this one seems to sum things up nicely:
http://stackoverflow.com/questions/603785/environment-variables-in-mac-os-x/4567308#4567308

> 2. We patch Qt5 itself similar to how Marko has done, but in a way that it will likely get upstreamed into Qt itself. For this I suggest some native mac osx way of doing overrides. Maybe a new environment variable (MAC_DATA_DIR?) or if environment variables aren't common (as it sounds from reading other e-mails on this list) set overrides in some info.plist or some mac way to set overrides or settings and patch Qt5 to read that to find overrides.

No.  See above thoughts and also more detail on environment variables in Apple OS X.  Our (MacPorts)
default locations and $XDG_* to override them would be my preference.

One thought though.  QSP appends an "organisation name" as well as an app name to its DataLocation
(or future AppDataLocation and AppLocalDataLocation) paths.  It gets "organisation name" from
QCoreApplication.  I do not know (yet) where QCoreApplication gets it from, but this might be a way
to introduce a variation into various paths used in MacPorts with Qt5 or Qt4.  I notice that the QSP doco
says, "<APPNAME> is usually the organization name, the application name, or both, or a unique name
generated at packaging."  We just have to get "a unique name generated at packaging" somehow.

> In this way the tests can set some info.plist or whatever and run with their custom overrides for these paths and can find the files where they expect. Then some master kde or macports info.plist can set the overrides it needs such as making it look for data in /usr/local/share or /opt/local/share or whatnot. This has the advantage that it makes QSP act similarly to linux and also that it can likely get upstreamed into qt5 itself.

As René says, Info.plist is a bit like a *.desktop file for an app in KDE on Linux.  CMake generates it
in KDE 4 on OS X from a template provided, I think, by KDE Macros.  The template is pretty rudimentary.
I assume *.desktop files for starting KDE 4 apps are ignored on OS X, unless the app is started by
KLauncher maybe, but they *are* installed.  OTOH, other types of *.desktop files *do* get used, e.g.
when loading plugins.

> Thoughts?

Well, that's my 2c.

Cheers, Ian W.