<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Regards,<o:p></o:p> <o:p> </o:p> John Bollinger<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: xdg <xdg-bounces@lists.freedesktop.org> 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<o:p></o:p> </div> </div> <o:p> </o:p> Caution: External Sender. Do not open unless you know the content is safe.<o:p></o:p> <o:p> </o:p> <div> <div> 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:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> From: Chanslor Rosenthal <<a href="mailto:chanslor@icloud.com">chanslor@icloud.com</a>> Date: April 27, 2021 at 11:03:23 AM PDT To: <a href="mailto:elektra@markus-raab.org">elektra@markus-raab.org</a> Subject: Re: RCF: Basedir specification for non-Linux<o:p></o:p> </div> </blockquote> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> 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.<o:p></o:p> </div> </blockquote> </div> </div> <hr> Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer </body> </html>