XDG Base Directory Spec is not followed

MirandaStreeter commented 6 days ago

MAME version

0.266

System information

Any Linux distro

INI configuration details

No response

Emulated system/software

No response

Incorrect behaviour

Mame does not follow the freedesktop $XDG spec on linux environments. Instead, it uses its own ~/.mame directory.

Expected behaviour

For future installs default to the XDG spec for config/data/state/etc as defined here.

Steps to reproduce

No response

Additional details

While the ~/.mame directory technically works, and its location is configurable, defaulting to a dot folder in the home directory has fallen out of "best practice" in favor of compartmentalized directories managed by the OS, much like other operating systems. As in, Windows' %AppData% et al. For the more Windows aligned you can see a cross-OS comparison documented by the GO implementation here. You can also see a sample of what other software has adopted the standard here.

From a user's perspective:

Littering the homedir with hidden dot folders is messy and hard to navigate
Any locations for these hidden dot folders have to be set on a per-app basis, if they're not hardcoded
Backing up, say for example, the config for all applications is considerably more difficult

The previously linked XDG spec here should have all the relevant details. The categories are cache, configuration, data, state, and runtime files. Mame's .mame contents are largely config and data. As an example, if something like $XDG_CONFIG_HOME isn't set (most distros don't) the default is $HOME/.config.

There's arguably no pressing need to migrate users right away. Existing installations are fine as-is. The idea is to check if there's an existing $HOME.mame, and if it's not present then fall back to the new XDG defaults, with the idea you flip that around after 20 years or so. And for safety you can add an override variable. I believe that aligns with what Mozilla is planning.

angelosa commented 5 days ago

I don't have a strong opinion about this, I sense it falls under the opinated onboarding that mame -cc does, but ...

Littering the homedir with hidden dot folders is messy and hard to navigate

... this isn't a valid point, either ls -a or setting up your desktop env to show the hidden files/folders or create a folder bookmark looks all viable to me.

MirandaStreeter commented 5 days ago

either ls -a or setting up your desktop env to show the hidden files/folders or create a folder bookmark looks all viable to me.

I think you misunderstand. It's not that it's difficult to see dot folders. Because yes you can reveal them fairly trivially.

It's that the sheer abundance in a directory as central as home is often considered undesirable. A typical desktop user will end up with many dozens of them. I count 38 on my relatively fresh install of a couple months now, and my partner has ~160. For those who daily drive linux it's a disorganized mess in the most central of folders.

The annoyance is common enough that major DEs have features to permanently hide specified dotfiles in their file navigators - even when you enable the "show hidden files" toggle. Both Nautilus and Dolphin (Gnome and KDE) allow you to use a .hidden file to mask the ones you so wish. Ultimately this is a manual workaround for the desired solution of applications compartmentalizing things into .local and .config and such so that they're tucked away.

And outside just the GUI there's several popular tools like boxxy and xdg-ninja.

This isn't some fringe opinion either. We can defer to the very people who are responsible for architecting these conventions: https://web.archive.org/web/20180827160401/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

In fairness this isn't the most pressing need. People aren't about to abandon ship over a few dotfiles. I don't expect this to be a high priority. But this is the general direction linux directory management has been headed over the last ~20 years.

rb6502 commented 5 days ago

Checking my two physical and one virtual Fedora 40 systems (two are serial in-place upgrades, one was installed from scratch as F39 and then upgraded in-place), the two oldest systems define only XDG_DATA_DIRS, and the newest one also has XDG_CONFIGDIRS. None of the 3 define any of the XDG*_HOME variables, which is what would actually be useful.

So given that we'd have to fall back to just hardcoding ~/.local/{share/config/state} on a significant population of user machines anyway I think we can just add that to the default search path for mame.ini and people can choose to use it or not.

MirandaStreeter commented 4 days ago

None of the 3 define any of the XDG_*_HOME variables, which is what would actually be useful.

That is expected. As I'd mentioned previously:

As an example, if something like $XDG_CONFIG_HOME isn't set (most distros don't) the default is $HOME/.config

As in, only if it's unset then fall back to the default .config location, rather than hardcoding it. Part of the point is to have sensible defaults that are user-configurable. Having user definable behavior helps with backups, portable installations, and immutable setups.

If a user expects their config files to be under ~/.config but applications default to something else with at best a secondary search path then users have to manually copy things over on a per-app basis, somewhat defeating the point.

The ideal is to check for preexisting data in .mame and, if not present, supply everything in the directories defined by freedesktop.org.

mamedev / mame