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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users