[Octave-bug-tracker] [bug #36477] use XDG dirs instead of HOME

[Andrew Janke]

Follow-up Comment #12, bug #36477 (project octave):

> On macOS, I think there is a separate standard hierarchy, and I can include
that as well here. I've seen some references to a standard location of
${HOME}/Library/Preferences. So that would make the startup file
${HOME}/Library/Preferences/octave/octaverc. 
>
> @apjanke Does that look right to you?

Yes, ~/Library is the default location for the hierarchy of config files and
persistent program state on macOS. Application state (like the Qt window
location and widget arrangement) would go in `~/Library/Application Support`.

However, I'd recommend sticking with the Unix-y `~/.config/octave` or
`~/.octaverc` for Octave on macOS.

The ~/Library hierarchy is mostly used by native Mac apps that are built using
Apple frameworks, and they use plists and other Mac-y mechanisms. Most
software I've seen come over from Linux keeps the `~/.config/myapp` or
`~/.myapp*` pattern, and it doesn't cause any problems.

I don't think that Octave has a Mac developer that could provide expertise in
using the `~/Library` hierarchy. I'm certainly not advanced enough: I don't
really know what to do there, or what formats are appropriate for use in it.
(I don't even know if using rc files instead of .plist files in
~/Library/Preferences is technically supported.) And the documentation I've
seen on this file hierarchy seems to really leverage Apple frameworks for
interaction with it, instead of defining the dir tree and file formats at a
low level.

(At this point I have to confess to using ~/Library/Application Support myself
in Octave.app - but that seemed to be the Rightest place for it in what is
trying to be more of a native Mac app. $XDG_DATA_HOME would have been just as
right, I think...)

And the source code would be simpler and easier to maintain just using the
`~/.config/octave` mechanism on both Unix platforms. Since macOS seems to be
the distant third-place platform for Octave power users and developers, I
don't think a split bodes well for the fate of platform-specific codebase,
even if it's not big.

Plus, ~/.octaverc is a convenience for multi-platform users: that way they can
sync their Octave preferences across machines by just syncing ~/.config or
~/.octaverc across machines. Switching to ~/Library would require a more
complicated configuration linking different local filesystem locations to a
shared backing file depending on the platform.

And all the "howto" articles or bug reports online that explain how to edit or
fix your Octave config or app state on Linux would still be applicable to Mac
users, too.

There are no advantages I'm aware of to using ~/Library unless you're also
using Apple's macOS app development frameworks as well.

So, I'd vote for not using ~/Library, and continuing to just treat Macs as a
Unix-y system here.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?36477>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/