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

[Ian Wadham]

On 05/01/2015, at 11:52 PM, David Faure wrote:
> Thanks for this concrete suggestion.

I try my best… :-)

>> 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.
> 
> Whooops! I definitely didn't want to replace the list, but to append or 
> prepend to it.
> Sorry if this created any confusion... this was definitely not my intention.
> 
>> 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;
> 
> Sounds good.

Thanks.

>> 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]). 
> 
> And not just apps coming from the KDE community, but any Qt app that install 
> stuff into /opt/local/share…

Yes, indeed.  However, the apps coming from the KDE Community would be
the vast majority at present.  I think they are also the main users of DBus, FWIW.

>> 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].
> 
> Plus apps not built by MacPorts, of course.

Not sure what they do.  I don't think they would link to MacPorts' copy
of Qt.  Not every Mac has MacPorts and FOSS, some have Homebrew
or even Fink to install FOSS.  But the vast majority of Macs would have
no facility to install FOSS, apart from the FOSS embedded in software
from Apple and other sources.

It is a situation I would like to change, as I hope you would too.

>> 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().
> 
> OK. You can take that code from qstandardpaths_unix.cpp ;-)

I know ;-)

> I could update my patch, but I'm coding blind, so it would be much better if 
> someone with a Qt build from sources (git) on OS X could finish the patch and 
> then submit it to gerrit.

I think Jeremy is on it already.  I'll be having a look soon.

>> [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.
> 
> Surely there are other apps doing that, not just KDE apps?

Dunno.  MacPorts has about 20,000 packages, but I install only a
small subset… :-)

> The only thing I'm wondering about is: this approach will force users to
> export XDG_DATA_DIRS=/opt/local/share

No.  No more than it does in Linux.  We are just proposing /opt/local/share as
a default location for $XDG_DATA_DIRS instead of /usr/local/share:/usr/share.

> This is why I was wondering if this couldn't be the default value, much like 
> /usr/local/share:/usr/share is the default value for XDG_DATA_DIRS on 
> freedesktop platforms.
> It would make sense, if this is the default prefix for MacPorts installs.

Exactly.

The XDG_* variables should be supported in our QSP patch, for the benefit
of KF5's Apple OS X CI, kdesrc-build users on Apple OS X and people like
me, who, through an accident of fate and horrid, plastic Toshiba hardware,
find themselves developing KDE Community code on a MacBook… :-)

We should probably also support configuring the Macports XDG base,
for guys like René Bertin and Nicolas Pavillon (the Macports developer),
who want to develop and test private installations of MacPorts.  That
comes later and could probably be done in several ways, none of
which need to involve Shell environment variables, as I discussed in
an earlier email.

Thank you very much for your interest and help, David.

I wonder if we can talk sometime about "background" parts of a KDE 4
installation and their role in the future of Frameworks, KF5 and Qt 5.  I mean
things like kinit, klauncher, kded, kbuildsycoca, drkonqi… and even
components such as KWallet and Baloo, for which the Apple OS X desktop
has equivalents (i.e. Keychain and Spotlight).  René already did some work
to unify KWallet and Keychain.

All the best, Ian W.