-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support XDG base directory specification #193
Conversation
Well, I just found that on my system ~/.cache links to /tmp, so if this is a supported configuration, it's pretty much wrong to use watch_later with .cache. |
Hmm, the specification does say that We could avoid that and just dump the watch_later files in the config dir like it is done currently, but I wonder if that's the correct behavior on windows -- should the watch_later files roam, or are they specific to the current computer? |
Cache is stuff that can be re-fetched or recalculated from an original source, and is just kept around for speed; removing cache shouldn't affect the operation of a program except for making it slower. The watch later info is original and if deleted, it would not be automatically replaceable and would cause the program to behave differently (i.e. not resume), so I definitely wouldn't consider it cache. I guess it's not really config either, but I think it fits better there than in cache. It's really more like "application data". XDG would probably want it in ~/.local/share/mpv or something like that, but I'm not sure. |
So, why exactly do we bother with ~/.cache then? The code would be much simpler leaving as it is previously. Unless you insist that it's handled differently on windows (for roaming...something). |
@qmega I see; the spec is not clear on what exactly any of it it means, other than the runtime dir, which is clearly not what we use here. @wm4 I'll change it to not use the cache lookup, though should I keep the cache dir code up, in case we ever need it? Or should I remove the cache dir code too? On windows, I think there's no harm in the resume files roaming, but I guess it's unlikely they'll be useful outside of the originating computer. |
Maybe just use $XDG_DATA_HOME in place of $XDG_CACHE_HOME. Looking at the spec, I think that's where it should go. Cache is definitely not what this is. |
I just wanted to let you konw, that I would could use |
Only uses XDG_CONFIG_HOME and XDG_CACHE_HOME. Appropriate, equivalent(ish) behavior is implemented for Windows. Cygwin is treated as not-windows. The watch_later functionality now stores its files in the cache dir. Still supports the ~/.mpv path if it exists, but warns about the change to the new one. That codepath is toggleable by the SUPPORT_OLD_CONFIG internal define, in case it's ever wanted. Note that it is ignored if it's a symlink, to allow symlinking to the new path to support older versions. On Windows, the config files are now stored on %AppData%\mpv, unless there is an "mpv" dir in the same folder as the mpv.exe. Cache files always go on %LocalAppData%\mpv, but it's possible to make it put the files in the exe-local "mpv" dir by changing the ALWAYS_LOCAL_APPDATA define to 0.
Can we please just use the normal config home for watch_later? In fact, I'll just make it clear that I won't accept anything that is more complex than the absolute minimum needed to move the config dir to XDG's. I see no reason why watch_later should be moved to a separate directory. Even if someone has a use case for this (which I'm pretty sure nobody will), he could symlink the watch_later dir to somewhere else.
This is Wayland and Linux specific, and it's just a few lines of code. So no reason to litter the common code with that. Plus, I suspect Wayland will change this anyway, because creating temp files on a tmpfs doesn't sound like a good solution. |
I agree that XDG_CACHE_HOME isn't the best place for watch_later. It indeed sounds like something under XDG_DATA_HOME (e.g., this is where local databases get stored in WebKitGTK). |
I'd much prefer XDG_DATA_HOME since it'd make keeping my ~/.config in git easier. |
👍 for this, would love to see configuration read from |
So do I. |
It'd be nice to load Lua files from |
Empirically, Kovensky has no interest in finishing this, so this is a WONTFIX. |
Fixes issue #109.