jak-project icon indicating copy to clipboard operation
jak-project copied to clipboard

config: Linux, store save data on $XDG_DATA_HOME

Open SuperSamus opened this issue 3 years ago • 4 comments

What feature is your idea related to?

According to the XDG standard, user-specific data files should be written in $XDG_DATA_HOME (defaults to $HOME/.local/share). Right now, jak-project stores save data to $XDG_CONFIG_HOME, which is right for the settings, but not for the save data.

Describe the solution you'd like.

Save data is stored to $XDG_DATA_HOME instead of $XDG_CONFIG_HOME.

Additional context

The changelog will have to clearly state that the user should move the files to transfer the progress from the old jak-project version to the new one. I don't think that maintaining backwards compatibility by also checking the presence of the save data in $XDG_CONFIG_HOME is necessary, since the project is still in a zero-point version, plus this will only affect Linux users, which is a small percentage and tends to read changelogs.

SuperSamus avatar Aug 09 '22 20:08 SuperSamus

This is something that can be changed but honestly I just see more support-burden pain from this.

  1. Linux files are fragmented into two locations compared to Windows
  2. Our frontend now can't just bring you to one location (a very common question is "where are my saves / settings") now it has to bring you to either or if you are on linux.
  3. Communicating the change in location.

Of course the flip-side is that this is the convention that supposedly linux users have come to expect.

Though I question how pervasive this knowledge actually is, considering we've had many linux users that aren't familiar with running executables on the command line, let alone being familiar with the XDG spec.

Will probably do this, follow the spec, and deal with the pain that it inevitably will cause...

xTVaser avatar Aug 09 '22 20:08 xTVaser

I agree that $XDG_DATA_HOME is the right spot, but I also agree with Vaser that this will be more trouble than it's worth at this point.

This project has a lot of linux users that would struggle to open ~/.config/OpenGOAL/, and it would be annoying for both us and them to have to move their save files, or implement some way to check for both.

I also see a lot of programs don't really respect this either. From my computer, all these applications store save-like data in config:

  • google chrome
  • discord
  • vscode
  • pcsx2
  • sublime text
  • virtualbox

So I don't feel too bad about leaving a ~500 kB save file in config.

water111 avatar Aug 09 '22 22:08 water111

To be fair, it would be just two commands.

mkdir -p $XDG_DATA_HOME/OpenGOAL/jak1 && mv $XDG_CONFIG_HOME/OpenGOAL/jak1/saves/ $XDG_DATA_HOME/OpenGOAL/jak1/

(Though, now that I think about it, the settings and saves folders would become redundant at this point. More commands to get rid of these too?) Still, alternatively if no save file is found in $XDG_DATA_HOME/OpenGOAL/saves/, then it could be searched in $XDG_CONFIG_HOME/OpenGOAL/jak1/saves/ instead (and if it's in neither, then $XDG_DATA_HOME it is!), but it would burden the code. I guess that this is a choice between "do it while it can still be done" or "it's too late already".

SuperSamus avatar Aug 09 '22 22:08 SuperSamus

The complete migration script would be (assuming that settings and saves would be removed for redundancy):

#!/bin/sh
config="${XDG_CONFIG_HOME:-${HOME}/.config}"/OpenGOAL/jak1
data="${XDG_DATA_HOME:-${HOME}/.local/share}"/OpenGOAL/jak1
mkdir -p $data
mv "${config}"/saves/* $data
mv "${config}"/settings/* $config
rmdir "${config}"/{saves,settings}

SuperSamus avatar Aug 10 '22 10:08 SuperSamus