[KDE/Mac] QStandardPaths possible solution

[Ian Wadham]

Hi Jeremy,

On 08/01/2015, at 12:08 AM, Jeremy Whiting wrote:
> Ok I got this qt built with dbus at last, and almost all frameworks build against it now with XDG_DATA_DIRS set (to /usr/local/share since I'm building with kdesrc-build) And it seems to fix the issues of finding data files from the /usr/local/share location fine. I ran kanagram with it and it finds it's vocabulary files fine, etc. I guess the next step is submitting this to gerrit?

I guess you mean Qt's patch review system, using Gerrit software.

> Does this patch look ok to everyone here? If you see anything I should
> change speak up now, otherwise I'll post it to gerrit tomorrow.

But where is the patch you refer to?  In what follows, I will rely on memory
of what I think I have seen, maybe it was in one of these emails:
Mon, Jan 5, 2015 at 2:46 PM or 06/01/2015, at 7:51 AM (those might be
Australian times/dates BTW).

Yes, I do have some things to say.

1) If you are going to submit this for inclusion in Qt 5, I think we
really DO need to have a way of configuring the base directory,
otherwise you are going to be going through all that "Why are you
using /opt/local?  Why aren't you using /usr/local?" business again.

Also, configurability will cater for Homebrew and any other FOSS
on Apple OS X that wants to use an XDG-like structure.

2) Looking at the documentation on QStandardPaths at
http://doc-snapshot.qt-project.org/qt5-5.4/qstandardpaths.html,
a notional prefix called <APPROOT> is used to describe the
typical Blackberry and Android paths.  We could do something
similar for XDG-like paths on Apple OS X.  Blackberry does not
use "APPROOT" in its code, but Android uses something like it.
It looks to see if "APPROOT_FILES" is defined, and if so, it uses
that path.  On Windows and OS X, the notional prefix <APPDIR>
appears, but it is defined as the directory where the *executable*
resides, so no use to us.

I suggest our patch could look for APPROOT_XDG.

3) If APPROOT_XDG is not defined, do nothing: forget about XDG.

4) If APPROOT_XDG is defined, PREPEND the appropriate XDG paths
(for faster searching).  I believe the currently-proposed patch is appending
XDG paths, i.e. after all the Apple OS X paths.

5) APPROOT_XDG could be defined with different values by MacPorts,
Homebrew, Fink or even individual apps that use Qt. and XDG structure.

6) MacPorts could set APPROOT_XDG to ${prefix}, default /opt/local.
But it might be nicer to set it to something that is defined by the portfile
or portgroup for the app, via the build or perhaps via the Info.plist file.  That
way, different MacPorts apps could follow different settings, if required.  For
example QGIS, which uses Qt, might want to use the Apple standard dirs,
to assist in communication with the GRASS app, which does not use Qt.
All that is a side-issue for MacPorts, i.e. external to Qt and our patch.

7) I think success with the Qt reviewers will be helped if what we are doing
is explained a little in the documentation for QStandardPaths.  So I am
attaching another proposed patch (to qstandardpaths.cpp), to take care
of that [1].  My base-file came from a Qt repository for Qt 5.4, so I hope the
line numbers correspond to what you are using.  Please adjust them if
required.

8) What are we doing about config and cache dirs?  Do we need something
about them in the patch(es) (yours and mine)?  I have not written anything.

Also where does $XDG_RUNTIME_DIR get into the act?  Is it used/usable in KF5?

And how about the other $XDG_* environment variables?  There are five of them,
but I have only seen $XDG_DATA_DIRS in our patch so far.

Hope this helps.

Cheers, Ian W.

> On Tue, Jan 6, 2015 at 6:20 AM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> On Tue, Jan 6, 2015 at 5:41 AM, René J.V. <rjvbertin at gmail.com> wrote:
> On Tuesday January 06 2015 05:20:07 Jeremy Whiting wrote:
> 
> > Yep, I noticed that in the sources also. Separate patches makes sense to
> > me, but I don't think patches to 5.3 (or 5.4 for that matter) will make it
> > upstream since those are frozen. We can keep those in
> 
> Really? 5.4 will remain at 5.4.0 which was release about one (1) month ago?! Is it such a bad release, or has the Qt Company become so good that they can skip the patchlevel releases? I presume that 5.4 and 5.5 are ABI incompatible as to be expected, no?
> 
> No there will be 5.4.1 and such, but I think those are only for bug fixes, not new features. I'm not sure if this change qualifies as a bug fix or not. I would think not, but I could be wrong.
>  
> > macports/homebrew/fink packages of qt 5.3 and 5.4 though I suppose.
> 
> Of course ... what other choice do we have?
> 
> Yep. 
> 
> R.

[1]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qstandardpaths_doc.patch
Type: application/octet-stream
Size: 3470 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150108/c7e22d8f/attachment-0001.obj>
-------------- next part --------------