about XDG_RUNTIME_DIR

[René J. V. Bertin]

Rainer Müller wrote:

Ah, this is the message to which Clemens appeared to be replying. Missed it 
somehow...

> Adding environment variables is complicated and involves interruption by
> the required logout/reboot. If possible, we should avoid it and patch
> the default settings for libraries and applications instead.

Of course. I am not at all suggesting we should use it.

> For runtime files, such as sockets, this looks like an unusual location

Well, who are we to question the Qt guys' wisdom? ;)
More seriously, the native QStandardPaths locations have been decided with App 
Store rules in mind, and the (perceived?) applications of the locations in 
question. What strikes me as surprising here is that the application name isn't 
appended to Library/Application Support instead of leaving that for the 
application to do.

> to me. Putting them in $HOME is unnecessary, as they would not need to
> be preserved (not even across reboots, and especially not in backups).

Yep. That would apply to ~/.cache too; I spend considerable time discarding all 
backups of that directory from TM a while ago.

> Were there any sandbox limitations involved in this choice?

I have no idea.
I've started a thread about this on Qt's devel ("development") ML, "glib's and 
Qt's RuntimeLocation [OS X]" (cf. gmane.comp.lib.qt.devel).

> I have not verified it, but it looks like this is the solution deployed
> by GLib:
> 
> https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir

I think I saw a hit pointing me to glib when I did a search to see who uses 
XDG_RUNTIME_DIR. Not sure if glib is the source of the keyring entries I found 
in ~/.cache though.

> I agree this could become a problem for application interaction when
> GLib and Qt use different paths, so we should set a common default.

But it's the question whether this is indeed likely to be the case. Glib has a 
function for obtaining its user runtime directory, so any software not using 
that function has a bug we can patch (and report) - if it even has any business 
plodding around in somebody else's runtime directory instead of using a higher 
level function provided by the corresponding API.

I'm a bit more concerned about interaction with Qt4-based applications because 
they may indeed be rolling their own.

> However, do we also want to support interaction between applications
> managed by MacPorts and those installed manually?

Good question. Probably yes between Qt(5) apps from MacPorts and "outside". That 
is one reason why I do not simply patch QStandardPaths to become XDG-compliant 
unconditionally in my qt5-kde port, but use an activator to select XDG-compliant 
mode. That way "pure Qt" applications that do not need to interact with other 
XDG-compliant applications (not just at the level of RuntimeLocation) can behave 
as Qt applications are expected to.

BTW, if you ask the question differently the answer becomes easier: should an 
application A behave the same way when installed through MacPorts or manually - 
and that would include its settings? But then there is of course the additional 
question just how many of such applications there are which might be affected by 
the kind of choice (standard locations) we're talking about here.

And I must admit that I have accepted the fact that KF5 applications installed 
through MacPorts (thus using shared resources in $prefix/share because that's 
what MacPorts has always done) and hypothetical future KF5 applications 
installed as standalone all-inclusive app bundles will ignore each other's 
existence. I think that's not going to be an issue because the target user 
populations are (hopefully) different.

R.