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

[Ian Wadham]

On 02/01/2015, at 1:00 AM, René J.V. Bertin wrote:
> On Thursday January 01 2015 14:41:37 David Faure wrote:
>> But if /opt/local is such a common prefix on Mac, maybe we can extend 
>> qstandardpaths on mac to know about it...
> 
> It's a common prefix for those who use MacPorts . That doesn't mean that the majority of Qt(5) users and developers have MacPorts installed ...
> 
>> 
>> So, how about something like the patch below? Can you test it? Should we also 
>> honour $XDG_DATA_DIRS and $XDG_CONFIG_DIRS, in case someone sets up MacPorts 
>> with a different prefix than /opt/local?
>> 
>> http://www.davidfaure.fr/2014/qstandardpaths_mac.mm.diff
> 
> For starters I wouldn't out-comment the reference  to XDG_CONFIG_DIRS but apart from that, how would this work out for users who have a Qt5 installed through MacPorts (so presumably have stuff in ${prefix}/etc/xdg) but also versions installed elsewhere ... like embedded in app bundles?
> Example: both VirtualBox and Parallels Desktop are built atop Qt (v4 right now but that will change sometime soon I presume). What happens with such an application when it is started in presence of a Qt5 MacPorts installation? I presume that you envision to override the standard QStandardPaths with the information from ${prefix}/etc/xdg when that path exists. That'd work for the MacPorts install, but I'm not even sure if that'd be desirable for pure Qt5 applications installed through MacPorts ... let alone for those other applications should the patch be mainstreamed!

Yes, indeed.  KDE apps and utilities are not the only fishes in the MacPorts pond
that use Qt.

Just yesterday on the MacPorts there was an enquiry on the MacPorts users' list
related to QGIS http://www.qgis.org/ and GRASS http://grass.osgeo.org/.  These
are large bodies of Geographic Information System (GIS) software and QGIS is
currently based on Qt 4, with +grass as an add-on (or variant, in MacPorts terms).
We do not want to affect the work of various urban planning departments and
environmental research groups around the world.

I agree with the general approach in David's patch, including making all XDG_*
environment variables available for testing and non-default installations.

Perhaps there could be some way for an XDG-based program, from KDE or
otherwise, to tell QStandardPaths to setXDGModeEnabled(bool xdgMode).

The default would be xdgMode = false, and then QSP would work as defined
in http://doc-snapshot.qt-project.org/qt5-5.4/qstandardpaths.html.

The next question would be how to trigger XDG mode without hand-coding it
into every KDE app or utility?  We could put something in the build, via a KF5
Portgroup in MacPorts, but how to get it into Qt at runtime?

Something like this came up a year or more ago, when we found that qt4-mac
was not using raster graphics as a default (but the Linux and Windows versions
of Qt 4 were).  I solved it by patching KApplication (downstream only) to call Qt
and set raster graphics, just before QApplication is created.

But now, in KF5, there will be no more KApplication.  Also there may be non-GUI
KF5 programs that need to use QStandardPaths (e.g. kdeinit5 and friends?).

@David:  Can you suggest some way to proceed?  Is there some execution path
every KF5 program has to follow when it starts?  Could we insert something like
QStandardPaths::setXDGModeEnabled(true) there?

Cheers, Ian W.