[KDE/Mac] QStandardPaths possible solution

[Ian Wadham]

Hi René,

On 11/01/2015, at 12:52 PM, René J.V. Bertin wrote:
> So I applied the latest patch from gerrit to Qt 5.3.2, and in the end got this from qtdiag:
> 
</snip>
>  GenericConfigLocation: "Preferences" */Users/bertin/Library/Preferences* /opt/local/libexec/qt5/config
> 
> In other words, I've been sleeping on the job again, talking about using the install prefix, and not realising that in my own work to make the Qt ports co-installable, -prefix != ${prefix} because I use -prefix=${prefix}/libexec/qt5 :-/
> 
> I am calling configure with the options
> 
>>        -prefix         ${qt_dir}              \
>>        -docdir         ${qt_docs_dir}         \
>>        -headerdir      ${qt_includes_dir}     \
>>        -plugindir      ${qt_plugins_dir}      \
>>        -importdir      ${qt_imports_dir}      \
>>        -qmldir         ${qt_qml_dir}          \
>>        -datadir        ${qt_data_dir}         \
>>        -libdir         ${qt_frameworks_dir}   \
>>        -bindir         ${qt_bins_dir}         \
>>        -translationdir ${qt_translations_dir} \
>>        -sysconfdir     ${qt_sysconf_dir}      \
>>        -examplesdir    ${qt_examples_dir}     \
>>        -testsdir       ${qt_tests_dir}        \
>>        -hostdatadir    ${qt_host_data_dir}
> 
> (I only changed the paths passed in, not the options used). Is there another path specification option that can be used to get the path /opt/local/share (${prefix}/share) where it belongs??

I do not know what there is in Qt 5's install processes, but, if all else fails:-

 a) We could get each app's Info.plist file to pass in a Custom Key,
      with value "/opt/local/" (or whatever else suits that app, if the app
      does not come from the KDE Community or Qt/Digia).

OR

b) We could get launchctl to set an environment variable, for all
     the current user's processes, to some value like "/opt/local/".

OR

c) We could use Qt's QSettings class and the plist files it recognises
    in an Apple OS X environment.

a) is trickier to do, but we already have to supply CMake with
Info.plist.template files, so that apps coming from the KDE
Community and Qt/Digia(?) can run on the Apple desktop.
And we have shared PortGroup files in MacPorts to configure
all apps from a particular provider or having a particular build-style.

qstandarddirs_mac.mm would then have to have code like that
in http://iosdevelopertips.com/core-services/read-info-plist-key-value-pairs.html

And the Info.plist.template file would have to contain an extra XML key-value pair.  See
https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html#//apple_ref/doc/uid/TP40009254-SW1
for documentation on the syntax for key-value pairs.

c) is another possibility: I see http://doc.qt.io/qt-5/qsettings.html#details has some
support for plist files on Apple, including settings on a plist file for all apps from a
given provider.  See:
http://doc.qt.io/qt-5/qsettings.html#fallback-mechanism
http://doc.qt.io/qt-5/qsettings.html#platform-specific-notes

We would also need an installed plist file or files, containing one or more
key-value pairs to support XDG standards in Qt-based apps from however
many providers we wish to support, including one, if preferred (e.g. a dummy
"Qt" provider whose name is the same for all apps based on Qt 5).

b) is easier to do, but Apple would not like it and might not support it forever.
Also, all MacPorts apps and non-MacPorts apps that use Qt 5 would be
forced to use the same XDG prefix or default $XDG_*_DIRS values.

I think a) or c) would be more flexible and future-proof.

Well, there are a few options.  Pick one… :-)

Cheers, Ian W.