#130 Storing the configuration under $XDG_CONFIG_HOME

[Alberto Garcia]

I'm opening this as a feature request because it will likely result in a patch sooner or later, but for now this is only for discussion.

I'm preparing the Flatpak release of Fuse and while the idea is that everything will be built exactly as it comes from the official source tarball, there's one important aspect that needs changes, and perhaps a short discussion.

Flatpak apps can't store their configuration directly in $HOME, but they must use $XDG_CONFIG_HOME instead. $XDG_CONFIG_HOME defaults to $HOME/.config/ and it's already being used by most modern apps (Chromium, LibreOffice, ...).

In the Flatpak case $XDG_CONFIG_HOME is a private directory different for every app and it's located under $HOME/.var/app/ID/. Here ID is the app identifier following a reverse-DNS scheme (in the case of Fuse I was thinking of using net.sf.fuse_emulator). But I digress.

The important thing is that Fuse is going to try to use $HOME/.fuserc, and I need to change that. I don't propose that we change this in general, but only for the Flatpak build. Does that make sense, or does anyone think that we should take the opportunity to move Fuse's config file to $XDG_CONFIG_HOME ?

Doing that would require a couple of changes. Apps typically create their own directory under $XDG_CONFIG_HOME and then store their things there, even when it's just one file. And for everything to work without the user's intervention, Fuse would have to take care of moving the old file from $HOME/.fuserc to $XDG_CONFIG_HOME/fuse-emulator/fuserc or however we decide to name it.

The simplest solution is to leave everything as it is now and for the Flatpak case use $XDG_CONFIG_HOME/fuserc directly.

I don't need to change this in the upstream repository, I can simply patch the Flatpak build to use $XDG_CONFIG_HOME/fuserc instead (at least for the time being) and then we can decide the best way to implement this upstream (if we want to do that at all).

How does that sound?

[Sergio Baldoví]

I like the idea that apps group config files in $HOME/.config/ and leave $HOME less cluttered. It's quite extended on Linux, not sure on BSD and MacOS.

[Alberto Garcia]

Me too, and that's what I would do if I would be starting a new project. But is it worth moving the configuration to $HOME/.config/fuse-emulator/ for just one config file? I don't think so...

[Sergio Baldoví]

I see. If there is no real advantage doesn't worth the effort.

Maybe this could change in a future. Some UIs could save UI specific settings, like visible panes in the debugger, dialog visibility status, custom icons/actions in a toolbar, most recent used files, selected language, etc.

It was also discussed an option to save the machine status on exit and resume on startup (with an snapshot).

If we ever need more config files, I'd like to support $XDG_CONFIG_HOME.

[Fredrick Meunier]

Native macOS stuff all uses it's own configuration system that puts preferences in $HOME/Library/Preferences/ and UNIX stuff just follows other *IX defaults - I have one entry in $HOME/.config/

Happy for the Flatpak config to remain separate for now (and that may prevent Flatpak new Fuse fighting over prefrences with an older package-native version).

[Alberto Garcia]

Happy for the Flatpak config to remain separate for now (and that may prevent Flatpak new Fuse fighting over prefrences with an older package-native version).

Just to clarify: a Flatpak app never touches files from any non-Flatpak version of the same app. In fact the user's home directory is not even visible (by default) from inside the sandbox except for ~/.var/app/net.sf.fuse_emulator/, which is persistent and private for the app.

In other words: it's perfectly possible to have a Flatpak app and your distro's package of the same app in parallel and with different configuration settings.

In practice we probably want to give Fuse access to the user's home directory because Fuse needs to load and write snapshots, etc., but that doesn't change what I said above: ~/.fuserc is never going to be touched.

I'm attaching what would be the simplest patch for the Flatpak build. Later we can discuss if we want to implement this in Fuse, and how, or if we want to keep it forever as a Flatpak-specific patch.

[Fredrick Meunier]

Right - gotcha!

[Alberto Garcia]

This would be a simple implementation of $XDG_CONFIG_HOME support.

To be honest I'm not sure that this deserves its own official option for ./configure rather that simply patching the source code for the Flatpak build (or, maybe better, allowing the user to pass e.g -DCONFIG_FILE_NAME when buildling).

The first two patches probably make sense in any case.

[Fredrick Meunier]

I'm fine with these patches though I think that its nicer if the #ifdef blocks are used to define different function definitions (we don't use much of this to date) - e.g. config_get_next_path() could be, with get_relative_directory() having two full implementations switched by the #ifdef:

       strncpy( buffer, fuse_progname, PATH_MAX );
       buffer[ PATH_MAX - 1 ] = '\0';
     } else {
+      get_relative_directory( buffer );

[Alberto Garcia]

Ok, I can change that if you want.

For the third patch (config file location) I was thinking that perhaps a better alternative would be to have an environment variable like FUSE_CONFIG_FILE or something like that. If it's set then Fuse uses that as a config file, if not then it defaults to ~/.fuserc (or whatever the default is for the system).

This would allow users to change the config file without having to rebuild Fuse, or to even have different config files with e.g. different settings for different games. Perhaps that could be an interesting use case for front-ends (although admittedly that's already doable using command-line options).

Another alternative is to have a --config command-line option (I think I would prefer this over the environment variable), but perhaps that doesn't work too well with the way settings.dat is used to parse the command line.

[Fredrick Meunier]

Applied patch 2 in [0cac7c].

[Alberto Garcia]

Applied patch 2 in [0cac7c].

The subject line got splitted in two :-?

Anyway, here's the first patch with the changes that you proposed.

[Fredrick Meunier]

Thanks, I shorten the titles to 50 chars to try and comply with git recommendations (e.g. stackoverflow, though maybe its worth a dicussion to see what people prefer?

[Alberto Garcia]

Wow, 50 looks quite short to me.

But it's ok, I'll keep it in mind for next time. I was just wondering if it was a mistake or not.

[Sergio Baldoví]

I take the 50 chars limit as a guideline to follow if I can summarise the log (without trying too hard). With the message "Rename compat_get_home_path() to compat_get_config_path()" I would likely exceed the limit as it has only 4 words/tokens.

I always follow the 72 chars limit on next lines as I use git on a terminal with 80 chars width.

[Sergio Baldoví]

Anyway, here's the first patch with the changes that you proposed.

Looks good to me and fix the build on Linux.

[Fredrick Meunier]

Thanks for the tip!

[Fredrick Meunier]

Thanks, I had a think and felt like it was a shame not to use the compat infrastrucure for the switch, what do you think about the version in the feature-requests-130-compat-linux branch?

[Fredrick Meunier]

Merged to master in [e4cbf5].

[Alberto Garcia]

The Linux-specific bit from compat_get_next_path() was just 3 lines of code, I don't know if that deserves its own COMPAT_LINUX option with separate files for the Unix and Linux implementations. It feels like keeping unnecessary complexity in the build system for such a trivial functionality, but it's a matter of preference I suppose :-)

Anyway, it's not a big deal, and I'm fine with your change. Thanks!

[Fredrick Meunier]

I agree this was a very marginal decision :)

[Sergio Baldoví]

In my Linux distro XDG_CONFIG_HOME isn't defined. USE_XDG_CONFIG_HOME fallback to ".", but shouldn't fallback to $HOME/.config by default?

In fact, I think I could change (as user) the XDG_CONFIG_HOME variable to set an alternative path:

XDG_CONFIG_HOME=/path/to/config eval './fuse'

[Alberto Garcia]

You're right, it should fall back to ~/.config

However as I wrote in another comment I'm thinking that perhaps it would be better to have a way to specify a different configuration file (via an environment variable or a command-line option).