Revert "path: switch back to using non-XDG config dir by default"

[LaserEyess]

This reverts commit 269f0e7.

This commit was a rash decision that does not bring any benefits to mpv. It did not reduce code complexity and it did not improve compatibility with other POSIX and/or UNIX-like OSes. On the contrary, the only thing this commit did was break a convention that existed for years in mpv. It is a step backwards for users who do not like dotfiles cluttering their $HOME and for attempts by distros and other downstream users to standardize their configuration files. The XDG specification may not be perfect but it is a standard used on linux and some other OSes.

Reverting this commit before the 0.33 release will mean that distros will not ship any release with this commit in it and $XDG_CONFIG_HOME will still be the default for new mpv users downstream.

[ghost]

In fact, the commit you want to revert switches back to the simpler convention, that has been the default in mpv for longer than the XDG one. Also, while compatible, it does prevent creating the impression that mpv supports XDG properly. It does not. Things like support for XDG_CONFIG_DIRS, XDG_CACHE_HOME, etc. are missing.

Thus a clear "reject" from me.

Not sure why you have to dig this whole issue out again.

[ghost]

nope

[LaserEyess]

XDG_CONFIG_DIRS and XDG_CACHE_HOME are not relevant here. If you're saying mpv should use those and that is your requirement for merging this then I'll implement them. I think XDG_CACHE_DIR would be great for watch_later actually.

[Dudemanguy]

I don't care about supporting every little xdg thing (some are good; some are bad), but I agree that ~/.config/mpv is a better default than ~/.mpv.

[orbea]

I think it would be nice to fully support the XDG directory spec where applicable as documented on this one short page, but at least XDG_CONFIG_HOME would be better than nothing.

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[emanuelserpa]

While I think that the full XDG directory spec would not be necessary, XDG_CONFIG_HOME is a well established spec and you guys should expect that distro packagers won't like this and will likely be patched downstream.

[LaserEyess]

@orbea out of all of those, I don't think much beyond XDG_CONFIG_HOME makes sense. Perhaps XDG_CACHE_DIR for the shader cache/watch_later dir might make sense for cached data. Perhaps XDG_RUNTIME_DIR might make sense for the default location of an ipc socket. However, at least for this PR that's out of scope. This PR is about reverting the behavior to make XDG_CONFIG_HOME the default location for mpv's configuration.

[emanuelserpa]

And I was seeing some scripts that still have in their documentation to copy the .lua to ~/.config/mpv and many other things.

This change to not use XDG_CONFIG_HOME will turn this thing a mess to new users. I really think that not using it will be a step behind.

[ghost]

And I was seeing some scripts that still have in their documentation to copy the .lua to ~/.config/mpv and many other things.

These were never correct. Systems which used a different XDG_CONFIG_HOME, and installations which used the "compatibility" config location (now the default) didn't use that path.

In fact, after a few years it will be less confusing because XDG_CONFIG_HOME no longer matters.

[emanuelserpa]

But systems with the configs in ~/.config/mpv probably are the majority now, they where correct when they were written.

All major applications are already on XDG_CONFIG_HOME(with some exceptions like Firefox, vim and Wine) -- neovim is already more popular than mainline vim, like mpv is more popular than mplayer, and uses XDG_CONFIG_HOME. Even proprietary apps like Steam stopped using ~/.Steam.

I don't like GNOME and many things they push in the Freedestop's specs, but abandoning XDG_CONFIG_HOME is a step back.

[v-fox]

In fact, after a few years it will be less confusing because XDG_CONFIG_HOME no longer matters.

@wm4
Say what you want about XDG and its envvars BUT I'm pretty sure that every normal user and every distro maintainer was glad when ~/ ceased to be a giant dumping ground for myriad of not-so-hidden-and-often-needed-to-be-accessed directories and files.
That's probably the best change that's happened in GNU/Linux for past 15 years. Configs need to be in the ~/.config and any additional functionality needs to be in ~/.local in general.

As @emanuele6 pointed out, only few apps are continuing to be eye-sores. Which is why it's universally baffling that you're so adamant about joining their ranks.

[emanuele6]

I think you mentioned the wrong person, @v-fox.

ping @emanuelserpa

[mikroskeem]

I'm pretty sure it's time for mpv2 (or whatever fork name) now 😄

[LaserEyess]

No it's not time for a fork. Please do not comment on this PR if you don't have anything constructive to say on the argument of the merits of restoring $XDG_CONFIG_HOME as the default config location. All you do by making stupid comments is just reaffirm wm4's assumption that only shitty, ungrateful users and GNOME care about this change.

If you want to shitpost go to 269f0e7's comment section.

[ghost]

was glad when ~/ ceased to be a giant dumping ground for myriad of not-so-hidden-and-often-needed-to-be-accessed directories and files.

~/.config is still a dumping ground for myriad of not-so-hidden-and-often-needed-to-be-accessed directories and files. You achieved nothing.

~/.cache (and also ~/.local) is a good convention, and is often pointed out as decisive advantage of XDG. But you can have that without all the other XDG rules, especially without .config.

Also, you can still make mpv to use .config, where's the problem? People who prefer the old convention have it harder.

[orbea]

@wm4 You're blatantly wrong in a few obvious ways.

• mpv has already spent so much time changing the default that undermining that now is not only insulting, its highly disruptive.
• ~/.config/ is far less of a dumping ground than ~/, suggesting otherwise is just wrong.
• The XDG directory spec is generally widely adopted and a straight forward standard. Using non-standard variables doesn't make mpv better, it just makes it more a pain in the ass for most people to configure and clutters their environment with redundant variables.

[ghost]

mpv has already spent so much time changing the default that undermining that now is not only insulting, its highly disruptive.

No, it's not disruptive in any sense of the word.

~/.config/ is far less of a dumping ground than ~/, suggesting otherwise is just wrong.

Maybe that's true, but not if you consider ~/.config/* and ~/.?*
Then they're supposed to be the same, save for some special entries like ~/.cache/.

The XDG directory spec is generally widely adopted and a straight forward standard. Using non-standard variables doesn't make mpv better, it just makes it more a pain in the ass for most people to configure and clutters their environment with redundant variables.

No idea what you're even talking about.

[orbea]

No, it's not disruptive in any sense of the word.

It clearly is, look at the response you are getting. You're acting like the xscreensaver dev when he told me that he refuses to support the XSS because its "bad". (I didn't get a specific reason)

Maybe that's true, but not if you consider ~/.config/* and ~/.?*
Then they're supposed to be the same, save for some special entries like ~/.cache/.

I have 198 hidden files or directories in ~, its an utter mess. On the other hand ~/.config has only 90 files or directories where none of them are hidden and are for the most part actually configs, its far less of a mess.

No idea what you're even talking about.

What part of ignoring standards being bad is hard to understand?

[ghost]

I have 198 hidden files or directories in ~, its an utter mess.

Still wondering what you think you have gained with XDG.

What part of ignoring standards being bad is hard to understand?

It's not a standard, just some stuff some people made up.

[emanuele6]

You don't have to use XDG to put your mpv configuration in ~/.config/mpv: mpv already looks for configuration files in ~/.config/mpv by default if it doesn't find ~/.mpv.

And even if it didn't look in ~/.config/mpv you could just set the environment variable MPV_HOME to use that directory: MPV_HOME=/home/<user>/.config/mpv (or you can use use ~/.config/mpv or $HOME/.config/mpv if you are setting from a shell).

If you really want to use $XDG_CONFIG_HOME/mpv, you can just set MPV_HOME to that (shell syntax): MPV_HOME=$XDG_CONFIG_HOME/mpv.

You don't need XDG support built-in to put your configuration files in ~/.config/mpv (mpv already looks there by default) or in XDG_CONFIG_HOME (whatever it is, you can just change the value of MPV_HOME).

Also, mpv isn't going to create a ~/.mpv directory if ~/.config/mpv exists and MPV_HOME isn't set.

What's the problem? I don't get what you think it's the problem: you seem to act as if ~/.config = XDG_CONFIG_HOME.

You don't need to have XDG support to use ~/.config.

If you want to debate that ~/.config/mpv is a better default and that ~/.mpv should be the fallback, this discussion doesn't need to be related to XDG support.

[LaserEyess]

The problem is new users knowing nothing about this, getting a ~/.mpv and distros having to once again deal with another user program not following conventions. There was no need to change the default to not use XDG_CONFIG_HOME, it was a decision made by wm4 because of a single discussion on IRC and the perceived "encroachment" by GNOME (who has nothing to do with this) on the linux desktop. Once again in terms of technical complexity there is no reason not to convert this commit, no code is made more complex and XDG_CONFIG_HOME still has to be supported.

You don't need XDG support built-in to put your configuration files in ~/.config/mpv (mpv already looks there by default) or in XDG_CONFIG_HOME (whatever it is, you can just change the value of MPV_HOME).

What's the problem? I don't get what you think it's the problem: you seem to act as if ~/.config = XDG_CONFIG_HOME.

You don't need to have XDG support to use ~/.config.

If you want to debate that ~/.config/mpv is a better default and that ~/.mpv should be the fallback, this discussion doesn't need to be related to XDG support.

All of these statements are completely missing the point. Let me put the main points in a list:

• There is already XDG_CONFIG_HOME support for mpv
• There is no change in code complexity.
• There is no requirement to support any other XDG basedir specification directory
• It has been the default for a long time and all distros that package mpv use XDG_CONFIG_HOME as the default
• It is a standard convention on linux regardless of whether you like it or not

Any debate on the technical feasibility of "XDG support" is out of scope.

[emanuele6]

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

I wouldn't say that XDG_CONFIG_HOME is supported if it isn't used by default from how I interpret the spec. As I said, setting MPV_HOME to $XDG_CONFIG_HOME/mpvwill force mpv to use XDG_CONFIG_HOME as specified by freedesktop.org.

EDIT: $XDG_CONFIG_HOME/mpv → ${XDG_CONFIG_HOME:-$HOME/.config}/mpv

[LaserEyess]

You're right it's not supported unless it is by default, and this PR reverts 269f0e7 which removed it as the default. This PR restores it as the default and restores the previous behavior mpv had as well as the default for all downstream linux users. If you look at the code mpv properly checks XDG_CONFIG_HOME if it exists and then falls back to $HOME/.config if it does not exist.

mpv/osdep/path-unix.c

Lines 33 to 41 in b5d5678

	char *home = getenv("HOME");
	char *xdg_dir = getenv("XDG_CONFIG_HOME");
	if (xdg_dir && xdg_dir[0]) {
	snprintf(mpv_home, sizeof(mpv_home), "%s/mpv", xdg_dir);
	} else if (home && home[0]) {
	snprintf(mpv_home, sizeof(mpv_home), "%s/.config/mpv", home);
	}

[ghost]

It is a standard convention on linux regardless of whether you like it or not

Going by the numbers of @orbea (and I've counted my own files too), the "old" convention (which .config ironically follows by using the . prefix) is still more popular. After 20 years of annoying project maintainers with switching to XDG.

Edit: and of course, the "old" convention is still a living standard.

[LaserEyess]

The fact that .config is a dot file does not take away from the fact that it is one dotfile rather than hundreds.

[v-fox]

~/.config is still a dumping ground for myriad of not-so-hidden-and-often-needed-to-be-accessed directories and files. You achieved nothing.

Only if by "myriad" you mean Firefox, Wine, Gimp and, now, mpv.
I achieved order which you're trying to disrupt.

~/.cache (and also ~/.local) is a good convention, and is often pointed out as decisive advantage of XDG. But you can have that without all the other XDG rules, especially without .config.

Or you can have all of those for everything if outliers stop their stubborn clinging to things that no one wants or benefits from.

Also, you can still make mpv to use .config, where's the problem? People who prefer the old convention have it harder.

And I can kludge-up something similar for Firefox and Wine. But I prefer to not do anything and just have application not do stupid counter-productive stuff that I have to fix right after installation.

What's the problem? I don't get what you think it's the problem: you seem to act as if ~/.config = XDG_CONFIG_HOME.

The problem is doing work of an application for it. Now you just shifted the problem into workaround shell-scripts.

No, it's not disruptive in any sense of the word.

It clearly is, look at the response you are getting. You're acting like the xscreensaver dev when he told me that he refuses to support the XSS because its "bad". (I didn't get a specific reason)

I still don't get that: a screensaver service & pack that can't actually trigger properly on idle because it does not track idle-time. That's the reason I had to remove xscreensaver from all my machines and forget about it. There is still problem with emulators not stopping X's blanking/poweroff for some reason but at least mpv is not being interrupted by screensaver anymore.

I have 198 hidden files or directories in ~, its an utter mess.

Still wondering what you think you have gained with XDG.

Well, luckily, I only have some outliers, old remains and backups, something I could clean-up further.
You know what would help ? You NOT adding to that.

What part of ignoring standards being bad is hard to understand?

It's not a standard, just some stuff some people made up.

Just like RFCs and IEEE 802.*. Stuff that works great when everyone follow it.

[ghost]

I'm not really sure if everyone understood this, but: if ~/.config/mpv exists, that is used. You're not forced to use ~/.mpv/, and you don't need any workarounds.

[emanuele6]

What's the problem? I don't get what you think it's the problem: you seem to act as if ~/.config = XDG_CONFIG_HOME.

The problem is doing work of an application for it. Now you just shifted the problem into workaround shell-scripts.

It's not a workaround:

• if you want to use a configuration directory that is neither ~/.mpv nor ~/.config/mpv, you can set MPV_HOME to use it without forcing the XDG convention on all the users;
• you only need it if you set XDG_CONFIG_HOME to a path different from ~/.config.

You can't call this a workaround:

If you don't set XDG_CONFIG_HOME, you can still use ~/.config.

If you want to use a directory different from these two (e.g. one in XDG_CONFIG_HOME), you should set MPV_HOME.

[LaserEyess]

I'm not really sure if everyone understood this, but: if ~/.config/mpv exists, that is used. You're not forced to use ~/.mpv/, and you don't need any workarounds.

I understand this just fine, this discussion is about what the default should be. I am arguing that XDG_CONFIG_HOME is a better default than $HOME/mpv. It is a better default because it follows the modern convention of the XDG basedir specification, where users and modern users expect their config files to be in $XDG_CONFIG_HOME. This is the default behavior on a lot of distros and a lot of heavily used software. It was even the default on mpv.

You can't call this a workaround:

If you don't set XDG_CONFIG_HOME, you can still use ~/.config.

If you want to use a directory different from these two (e.g. one in XDG_CONFIG_HOME), you should set MPV_HOME.

This has, again, never been part of the argument. Of course you can still use XDG_CONFIG_HOME and set MPV_HOME. In fact my configuration file is still in $XDG_CONFIG_HOME/mpv. However for new users, and on new installs, it uses ~/.mpv by default and leaves a dotfile in the user's ~. This is a step backwards in getting more programs to follow the XDG basedir specification and using the self-fulfilling logic of "Well not every program uses this convention so it's not a convention and therefore I won't use it as the default location" is not a very strong argument. In fact it reminds me of this comment by GNOME developers about not supporting a feature because GNOME doesn't support it so therefore it's not popular.

[orbea]

Honestly it doesn't even need to be MPV_HOME vs XDG_CONFIG_HOME, its possible to support both.

I would suggest checking config directories in this order.

1. $MPV_HOME/mpv (Defaults to unset)
2. $XDG_CONFIG_HOME/mpv (Defaults to ~/.config/mpv)
3. $HOME/mpv
4. $XDG_CONFIG_DIRS/mpv (Defaults to /etc/xdg/mpv, can be a colon separated list of directories similar to $PATH)
5. /etc/mpv

Pick the fist one that is found in this list, that should make just about everyone happy. This issue is making a mountain out of a molehill.

[Dudemanguy]

Number 4 on that list is unnecessary and should be removed (definitely pointless complication at that point) but otherwise I like the suggestion.

[LaserEyess]

Definitely not 4, that's not what this PR is about. Currently the way config parsing is done, by your list, is 1, 3, 2, 5. I'm really just advocating that it be switched back to 1, 2, 3, 5.

[orbea]

I agree that XDG_CONFIG_DIRS may be overkill and I won't miss it if its skipped, but I felt it was worth mentioning for that extra level of completeness. I've supported it in posix shell before and I doubt it would be all that complicated to do so in c99.

[soc]

Only if by "myriad" you mean Firefox, Wine, Gimp and, now, mpv.

Gimp migrated to XDG in 2015. :-)

You probably just have to remove/move the folder.

[v-fox]

Only if by "myriad" you mean Firefox, Wine, Gimp and, now, mpv.

Gimp migrated to XDG in 2015. :-)
You probably just have to remove/move the folder.

@soc Yep. As I've said, I haven't bothered to clean all of old poop yet. And this doesn't make it easier.
I see now that this folder wasn't accessed since 2016 and it now creates per-version configs in ~/.config/GIMP/. But I wouldn't call that "migrated to XDG" either because there is a bunch of non-config crap that belongs in ~/.local instead of ~/.config. But at least it doesn't dump cache there.

Firefox and Wine are still like that with their profiles/prefixes and developers that think they are too good for a sub-directory. I'm surprised that KDE got in line with it though, even if it seems like that was the only good thing since KDE3.

[soc]

@v-fox I'm down to a dozen folders, and because my $HOME is read-only new, misbehaving applications can't add new ones.

[emanuelserpa]

I'm thinking about doing the same @soc.

(read-only $HOME)

[soc]

@emanuelserpa Cool! Here is an article I wrote on Defending $HOME, maybe it's useful to you.

[ghost]

I don't understand this obsession with moving the mess from ~/ to ~/.config, all while policing random projects that didn't give in yet and deriding them if they don't agree to adopt XDG. Making HOME itself read-only is the ultimate tip of the iceberg, because obviously that leaves you enable to do anything with HOME.

I've had enough, bugger off.