XDG Base Directory Spec is not followed

[MirandaStreeter]

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]

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]

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]

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_CONFIG_DIRS. 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]

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.

[chungy]

My two cents: the XDG directory specs are false starts toward a goal nobody ever really implemented. The purpose of XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_CACHE_HOME, etc was to assist in NFS mounts for workgroup environments. You'd hypothetically keep small configuration files in XDG_CONFIG_HOME that roam with you across multiple computers and logging into them. XDG_DATA_HOME was used for larger files that can either be kept locally or on a larger NAS; XDG_CACHE_HOME for files that are absolutely unnecessary to be on a network share at all, even could be tmpfs for local stations.

The purpose was never about making home directories "less messy" (you can simply stop using ls -A or showing hidden files if you care about tidiness), tons of software never moved toward it (especially as these specs are explicitly for desktop GUI applications), and ones that do often do it wrong, not obeying the purpose of the defined directories. If MAME, for instance, moved everything to XDG_CONFIG_HOME (defaults to $HOME/.config), you really shouldn't store snapdir content there, or rompath content, probably not even nvram or inp. Doing it "properly" would put those things in $XDG_DATA_HOME/mame (defaults to $HOME/.local/share/mame) and just confuse users by having files split across multiple locations.

Given that it would cause confusion and MAME is probably not appropriate for a workspace environment anyway, I honestly don't see value in even attempting this. Sticking to $HOME/.mame is simple and easy.

[stevenxxiu]

It's good that Mame has enough config options to do this yourself. Setting -inipath and adjusting your mame.ini is enough. I first made this wrapper (for Arch Linux):

#!/usr/bin/sh
/usr/lib/mame/mame -inipath "${XDG_CONFIG_HOME}/mame/ini" "$@"

Add a ~/.local/share/applications/mame.desktop to use this wrapper:

[Desktop Entry]
Type=Application
Name=MAME™ Arcade Emulator
GenericName=Arcade Emulator
Comment=Play vintage arcade games using the MAME™ emulator
Icon=mame
Exec=sh -c ~/.local/bin/mame
Terminal=false
Categories=Game;Emulator;
Keywords=Game;Emulator;Arcade;

Now an example ~/.config/mame/ini/mame.ini I made to follow XDG:

# ...

#
# CORE SEARCH PATH OPTIONS
#
homepath                  $XDG_DATA_HOME/mame/lua
rompath                   $XDG_DATA_HOME/mame/rom
hashpath                  /usr/lib/mame/hash
samplepath                $XDG_DATA_HOME/mame/samples
artpath                   /usr/lib/mame/artwork
ctrlrpath                 /usr/lib/mame/ctrlr
inipath                   $XDG_CONFIG_HOME/mame/ini
fontpath                  /usr/lib/mame/font
cheatpath                 /usr/lib/mame/cheat
crosshairpath             $XDG_DATA_HOME/mame/crsshair
pluginspath               /usr/lib/mame/plugins
languagepath              /usr/lib/mame/language
swpath                    $XDG_DATA_HOME/mame/software

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory             $XDG_CONFIG_HOME/mame/cfg
nvram_directory           $XDG_DATA_HOME/mame/nvram
input_directory           $XDG_DATA_HOME/mame/inp
state_directory           $XDG_DATA_HOME/mame/sta
snapshot_directory        $XDG_DATA_HOME/mame/snap
diff_directory            $XDG_DATA_HOME/mame/diff
comment_directory         $XDG_DATA_HOME/mame/comments

# ...

I didn't find any examples online of people getting Mame to follow XDG, so I defined the directories I thought were appropriate above. Adjust to your liking.