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

[Ian Wadham]

Hi all,

On 04/01/2015, at 9:57 AM, Jeremy Whiting wrote:
> In trying this I think we have a couple of options as René pointed out.
> 
> 1. Support reading XDG_CONFIG_DIRS
> 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.
> 2 would take a bit of thought but would be more usable (think kde applications .app bundles that could be opened directly without setting any environment variables or other tricks) The problem with this approach is that it doesn't fix the CI system issue of needing to set custom data paths for unit tests.
> 
> Thoughts on these ideas? My plan at the end of december was to submit and revise Marko's patch which does similar to your patch david except that it does extract XDG_DATA_DIRS (and doesn't touch XDG_CONFIG_DIRS yet).

Here is another idea.

QStringList QStandardPaths::standardLocations(StandardLocation type)
in file src/corelib/io/qstandardpaths_mac.mm assembles a list of locations
into "QStringList dirs" and ends up by returning "dirs", after prepending a
local (writeable) location.

David's patch replaces the value of "dirs", for some cases in the switch()
statement, with a value derived from calling xdgDataDirs().  The latter
currently returns a list of one string, namely the constant "/opt/local/share",
but could easily be modified to return a list based on $XDG_DATADIRS
or a value based on the MacPorts ${prefix}, as it was at build time.

My idea is simply to move the *second* hunk of David's patch, in its
entirety, to insert it at the line following:

----------------------------------------------------------------------------------------------------- 
    QStringList QStandardPaths::standardLocations(StandardLocation type)
    {
        QStringList dirs;

----------------------------------------------------------------------------------------------------- 

The effect of this would be to *prepend* the list from xdgDataDirs() to the
standard (Apple OS X) list provided by QSP.  So the order of paths for
directories of the required type would be:

    1. Local directory (writeable)
    2. XDG-type directories, based on MacPorts' builds of apps that come
        from releases by the KDE Community (colloquially called "KDE
        apps" in the MacPorts world, and in the world at large, I imagine [1]).
    3. Standard Apple OS X directories, which *might* be used by Qt-based
        apps that are built by MacPorts but not released by the KDE Community
        (e.g. QGIS) [2].

I think we should also implement, in the patch, support for *all* XDG-type
directories AND the corresponding XDG_* environment variables,
including XDG_*_HOME directories, in either ::standardLocations()
or ::writableLocation().

I hope the above ideas would take care of all the cases we have discussed,
including Apple OS X CI (acting on the KDE Community's repositories), test
setups on Apple computers using kdesrc-build and similar test setups using
MacPorts prefixes other than /opt/local.

Cheers, Ian W.

[1] I think "KDE" is a brand that has become so well-known that it has passed
     into common language … like Sellotape.  Still, I am glad that the KDE
     Community is now distinguishing between apps, libraries and the desktop
     and freeing apps from many of the dependencies that built up in KDE 4.

[2] Installation locations used by apps within MacPorts are determined by
     MacPorts port developers.  In KDE 4, the developers use the same kind
     of directory tree as Linux distros and KDE developers do, but based on
     /opt/local for read-only files.  However, KDE 4 apps follow Apple OS X
     conventions for locating KDE 4 user-files and custom configuration files.
     I have no idea why that is.