-
Notifications
You must be signed in to change notification settings - Fork 72
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
STL stores non-config data in ~/.config #486
Comments
Nice and useful idea. I don't have much time, but try to help with the implementation when I find the time |
I like this idea, but want to mention we should keep existing installations in mind. For things like MO2 which should go in Perhaps STL could check on startup to see if it's using the "old-style" file system (basically check what is present in Just my thoughts on how to make this kind of transition as simple as possible for an end user 🙂 |
yeah, those migrations definitely need a (temporary) clean up function. |
hm, so no further discussion at all? 🤔 |
Sorry I've been busy with work and other projects. Not sure if/when I'll have chance to work on this, but happy to if no one beats me to it 👍 |
thanks for the reply.
hehe, same :) |
Nothing which will or should happen completely at once, so I suggest we collect a proper list of files/dirs with the current and possibly the best position first, and then migrate one after another carefully.
Please add missing ones and/or correct me if you disagree with one or another. Depending on the source, we need to be especially careful when symlinks are involved, which need to be migrated as well. |
hmm not so sure about same thing with also noticed that downloads from some tools are being suggested for that is fine as some downloads you don't really need anymore. However it may just be easier to move the whole maybe if anything some none essintial stuff can latter be moved to such as :
and instead of being I think that makes more sense as As for logs, I think they should be moved to i didn't see you mention |
so it would look something like this
I moved so basicly
EDIT: didn't relize meta has config files for if you want to do a custom steamfirsttimerun script so that should stay in |
thanks for your suggestions. |
Not sure I agree with that. Temporary stuff should go in i.e. we can assume the files will be there for a while, but we shouldn't rely on it. Anything that STL can automatically replace probably belongs in Anything that can't be generated automatically is probably either data (
Agreed, backups are "essential" data so shouldn't go in cache.
Sure, As a stretch goal, it'd be nice if these options supported XDG env vars even when unset in the global environment. That way the user could reliably use variables in the config or they could be used in default values. |
Sure, as in ea0ec14 Apparently I want to avoid spending much time into this feature. Of course it is nice to have for a few people, but the migration is much more complicated than just switching some paths. |
I'm going to make a new release shortly and won't work very much on steamtinkerlaunch starting from then for various reasons. |
I don't know if anyone is actively working on this but just a heads up if anyone ever does take a stab at this, ProtonUp-Qt's STL uninstaller will need to be updated. I don't think it's worth submitting anything to ProtonUp-Qt yet but in future, when all of the folders for the new directory structure are ironed out, the ProtonUp-Qt uninstallation logic will need updated to remove the folders. So just as a note for the future if this ever does come to fruition, to keep this in mind before merging 😃 |
Thanks for the heads-up! (I do not work on it and likely won't) |
This would be a behemoth of a task to be honest and while I am very much in favour of following the XDG spec, as it currently stands I am not super interested in doing it myself. However if anyone wants to pick this up and work on it I would be more than happy to review and help out where possible with some knowledge. Some of the work was already started in ea0ec14 a while ago but I'm not sure how comprehensive it really is. Also, various parts of the wiki would need updated off the back of this change. ProtonUp-Qt support and possibly Steam Deck (and maybe even Flatpak) support would need to be at least reviewed off the back of this. On top of this, there would probably need to be a migration path, which would be very delicate and need heavy testing. Even though I don't want to do this myself, anyone passionate, willing and knowledgeable on what changes to make to best follow the XDG spec are very welcome to come forward and work on it. A fair warning, review on it could be lengthy and testing even moreso, but having this implemented would be a great change in my opinion. At the time of writing though, I have other things I would like to work on :-) |
Currently, STL stores everything in
XDG_CONFIG_HOME
(usually~/.config
), however the XDG spec recommends that directory only be used for configuration files.Cache files, that can be replaced at any time (e.g. the
downloads
directory) would be better off inXDG_CACHE_HOME
(~/.cache
).Persistent data, that isn't config files, would be better off in
XDG_DATA_HOME
(~/.local/share
). The various WINEPREFIX/compatdatas (e.g. for mo2/vortex) are probably a good example of non-config data.This might seem pretty, but applications storing stuff in the correct places can often make administering a system a lot simpler.
Similar to when stl's config directory changed from
~/.config/stl
to~/.config/steamtinkerlaunch
, this would be a "breaking" change, so would benefit from a major version bump and clear release notes, although most users should be completely unaffected.Storing stuff in
XDG_CACHE_HOME
may also highlight any existing bugs where wiping stl's cache breaks stuff. In principle, every time STL uses a file stored inXDG_CACHE_HOME
, it should first check if the file exists and if not, re-download (or re-generate) it.The text was updated successfully, but these errors were encountered: