RE: RCF: Basedir specification for non-Linux
Indeed, inasmuch as Mac software packaged in “app” format is expected to be pretty much self-contained, it may not make sense for such software to consult $XDG_DATA_DIRS or $XDG_CONFIG_DIRS. Their default data and configuration would normally be packaged together with them, instead. User-specific data and configuration can still be read from $XDG_DATA_HOME and $XDG_CONFIG_HOME, however, and can still override built-in defaults. However, a Mac app that wants to rely on XDG basedir and standard tools supporting that also has the alternative of using a wrapper script or similar mechanism to set appropriate (internal pointing) values of $XDG_DATA_DIRS and $XDG_CONFIG_DIRS. That seems a bit of a hack, but not necessarily inappropriate under the circumstances. The self-containment of this installation format is fundamentally at odds with the basedir concept of multiple applications sharing system-wide configuration and data locations. Regards, John Bollinger From: xdg On Behalf Of Chanslor Rosenthal Sent: Tuesday, April 27, 2021 1:06 PM To: xdg@lists.freedesktop.org Subject: Re: RCF: Basedir specification for non-Linux Caution: External Sender. Do not open unless you know the content is safe. Forwarding my own message to the list because my client failed to reply-to the list. I am embarrassed. Apologies to elektra@markus-raab! Begin forwarded message: From: Chanslor Rosenthal mailto:chans...@icloud.com>> Date: April 27, 2021 at 11:03:23 AM PDT To: elek...@markus-raab.org<mailto:elek...@markus-raab.org> Subject: Re: RCF: Basedir specification for non-Linux For what it's worth, I do not (frequently) port to Mac, but I *do* frequently develop for Linux on Mac. I work on an outdated MBP, test against my Debian server and Manjaro desktop, a newer Mac, and sometimes other Linux devices. I mention this because, when I do that, I almost always leave the spec unchanged *for user files*. Things don't get tricky until you arrive at executables. Things get *very* tricky when you arrive at executables. "Straight" Unix programs are, for the most part, where they are supposed to be, but desktop Mac programs work more like an AppImage and do not live anywhere nor have anything resembling a desktop entry. Special-casing it may be the only good solution. Some kind of parser would probably be the easiest solution, a companion package that locates Mac locations from FreeDesktop-specified paths and envvars. Just my two cents. Other people do much more intensive work porting full desktop apps and etc. Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: RCF: Basedir specification for non-Linux
Forwarding my own message to the list because my client failed to reply-to the list. I am embarrassed. Apologies to elektra@markus-raab! Begin forwarded message: > From: Chanslor Rosenthal > Date: April 27, 2021 at 11:03:23 AM PDT > To: elek...@markus-raab.org > Subject: Re: RCF: Basedir specification for non-Linux > > For what it's worth, I do not (frequently) port to Mac, but I *do* frequently > develop for Linux on Mac. I work on an outdated MBP, test against my Debian > server and Manjaro desktop, a newer Mac, and sometimes other Linux devices. > > I mention this because, when I do that, I almost always leave the spec > unchanged *for user files*. Things don't get tricky until you arrive at > executables. > > Things get *very* tricky when you arrive at executables. "Straight" Unix > programs are, for the most part, where they are supposed to be, but desktop > Mac programs work more like an AppImage and do not live anywhere nor have > anything resembling a desktop entry. > > Special-casing it may be the only good solution. Some kind of parser would > probably be the easiest solution, a companion package that locates Mac > locations from FreeDesktop-specified paths and envvars. > > Just my two cents. Other people do much more intensive work porting full > desktop apps and etc. ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: RCF: Basedir specification for non-Linux
Dear XDG List, 26.04.21 at 23:46 piegames wrote: in discussions around applications adopting the basedir specification, the handling of non-Linux systems (especially Windows and MacOS) is something that really comes up a lot. Yes. Env vars were obviously the most convenient solution for implementation/adoption but are a big compromise on many other aspects, even on Linux, e.g., with support of cron, at, sudo, ... It simply lacks an easy mechanism how to globally change the XDG variables and this is probably also the main criticism Windows+MacOS folks have, as they are used to have a global place to change configs "which simply works". *Technically*, the specification is platform-independent, as it only depends on the concept of environment variables. However, this is not an accepted solution, as it is not native to these respective platforms. Instead, a common solution is to use the specification only on Linux and the respective native equivalents on other platforms. I also think that XDG envs in its current form are practically not platform-independent (although I agree that they technically are). Which is also why Elektra https://www.libelektra.org has different resolving techniques for the path names of configuration files for different operating systems. Thus, I have the following idea: if we set the default value for $XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective native equivalents for non-Linux platforms, it would make things easier to adopt on the application side. I am not sure if this is a breaking change, as the specification is not really explicit whether it even applies to other platforms at the moment. I don't think the "setting the default" would be a breaking change, the spec does not say where the environment variables are set. A disadvantage is that – at least on Windows – the destination paths are not computable anymore, and the Known Folders API needs to be called in order to get the values. Yes, it would be a compromise but probably still be an improvement. As temporary (compromise) solution it probably makes sense to set the XDG env vars: 1. on Windows/MacOS with dedicated startup scripts reading from APIs like KnownFolders 2. on Linux with a script that gets XDG vars from Elektra to have a global place to set XDG vars, with the script executed at all places like login shells, desktop environment, at, cron, sudo, ... Btw. in Elektra we played around with intercepting getenv via LD_LIBRARY_PATH. The current implementation does not work in Windows but it would allow the return value to be computed at runtime. https://www.libelektra.org/tutorials/intercept-environment But also this can only be called transition solution. As long term solution I would prefer to make the basedir specification independent of the implementation detail of environment variables, so that it can be directly integrated in Elektra. Specifically, I would like to have https://www.libelektra.org and other portable config abstraction mechanisms to be completely compliant to the basedir specification, which would require allowing to get/set the XDG variables via other mechansims (not only env vars). best regards, -- Markus Raab http://www.complang.tuwien.ac.at/raab/ TU Wien markus.r...@complang.tuwien.ac.at Compilers and Languages Phone:+43 650 480 4700 Argentinierstr. 8, 1040 Wien, Austria DVR 0005886 OpenPGP_signature Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: RCF: Basedir specification for non-Linux
On Mon, 26 Apr 2021 at 23:46:46 +0200, piegames wrote:
> in discussions around applications adopting the basedir specification,
> the handling of non-Linux systems (especially Windows and MacOS) is
> something that really comes up a lot.
I think the right way to think about this is Windows vs. macOS
vs. "basically Unix", rather than specifically Linux being special.
Implementations of the basedir spec on non-Linux Unix OSs like the BSD
family usually use the basedir spec as-is - there's really no reason why
Linux and, for example, FreeBSD should be different here. They're more
similar than they are different (at least from a user point of view), and
they both use something resembling traditional Unix filesystem layouts
for the OS, so they might as well both use the basedir spec for paths
in the home directory.
Windows is really outside the scope of freedesktop.org because it's
neither Free/Open Source Software nor Unix, and it has its own conventions
for where files go. A large part of the purpose of freedesktop.org is
that it gives open-source OSs our own equivalent of the conventions that
Microsoft sets for Windows developers, so that developers can target
"the Linux platform" or "the Free desktop platforms" and have things
work reasonably consistently - but on Windows we don't need that,
because there's only one Windows, and Microsoft already designed it.
macOS is technically a FreeBSD derivative, but the
traditional/conventional paths are different; it could make sense to
special-case it, like Windows, or it could make sense to just treat it
as just another Unix derivative. People who literally port open-source
software to macOS can say what's most appropriate here better than the
Linux/*BSD community can.
Similarly, Android runs on the Linux kernel, but has its own filesystem
layout that's outside the scope of freedesktop.org.
> Thus, I have the following idea: if we set the default value for
> $XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective
> native equivalents for non-Linux platforms, it would make things easier
> to adopt on the application side.
You've described what GLib does, in its APIs that wrap the basedir spec,
and I think that makes a lot of sense. GLib's APIs separate the "user"
directory (the one you write to and the highest priority for reading) from
the "system" directories (lower-priority), but you could implement something
very similar in an API that unified them into a single list.
Pseudocode (taken from the documentation, not necessarily a 100% match for
the actual implementation):
def g_get_user_cache_dir():
if XDG_CACHE_HOME is set:
return $XDG_CACHE_HOME
else if not Windows:
return ~/.cache
else:
return CSIDL_INTERNET_CACHE
(typically C:\Users\me\Local Settings\Temporary Internet Files)
(this is not a perfect match, but it's good enough...)
def g_get_user_config_dir():
if XDG_CONFIG_HOME is set:
return $XDG_CONFIG_HOME
else if not Windows:
return ~/.local/share
else:
return CSIDL_LOCAL_APPDATA
(typically C:\Users\me\Local Settings\Application Data)
def g_get_system_config_dirs():
if XDG_CONFIG_DIRS is set:
split and return it
else if not Windows:
return /etc/xdg
else:
return CSIDL_COMMON_APPDATA
(typically C:\Users\All Users\Application Data)
def g_get_user_data_dir():
if XDG_DATA_HOME is set:
return $XDG_DATA_HOME
else if not Windows:
return ~/.local/share
else:
return CSIDL_LOCAL_APPDATA
(typically C:\Users\me\Local Settings\Application Data)
def g_get_system_data_dirs():
if XDG_DATA_DIRS is set:
split and return it
else if not Windows:
return /usr/local/share, /usr/share
else:
return CSIDL_COMMON_APPDATA, CSIDL_COMMON_DOCUMENTS,
calling DLL's ${prefix}/share, GLib's ${prefix}/share,
program's ${prefix}/share
Qt does something similar in QStandardPaths::standardLocations, although
the details are different on Windows. In particular, the Qt API
distinguishes between roaming and local directories, which doesn't matter
on freedesktop.org platform but does matter on Windows.
I think Qt's approach is probably necessary if you want "first-class
citizen" support for Windows - GLib's simpler API more closely resembles
the basedir spec, but it cannot capture the distinction between local
and roaming directories on Windows.
smcv
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
