feature: Move cache to its own directory to follow XDG standards.

[flipper]

Cache should not be in the same directory as the configuration. It mostly only applies to linux.

See here for what each folder maps to https://xdg-net.github.io/Xdg.Directories/docs/defaults.html

[love-linger]

This app supports Portable Mode for Windows packages and Linux AppImages. Therefore, we need to store all files generated by SourceGit in a single directory.

[love-linger]

Moreover, I believe that doing so will bring another benefit: when we want to delete SourceGit, we can be certain that all files generated by SourceGit can be easily deleted without any residues.

[flipper]

This app supports Portable Mode for Windows packages and Linux AppImages. Therefore, we need to store all files generated by SourceGit in a single directory.

Portable mode should still be supported is there anything I missed?

[flipper]

Moreover, I believe that doing so will bring another benefit: when we want to delete SourceGit, we can be certain that all files generated by SourceGit can be easily deleted without any residues.

Correct. When running on Mac or Windows everything is in a single directory.

But on Linux it is two folders. The cache does not belong next to configuration files.

[love-linger]

I've pushed a commit that moves data from $XDG_CONFIG_HOME/SourceGit or ~/.sourcegit to $XDG_DATA_HOME/SourceGit on Linux

[flipper]

I've pushed a commit that moves data from $XDG_CONFIG_HOME/SourceGit or ~/.sourcegit to $XDG_DATA_HOME/SourceGit on Linux

What else does source git store? It should be in .config if it's only configuration

[love-linger]

The files generated by SourceGit do not strictly distinguish between configuration files, cache data, solidified data, runtime process-related files, etc. All files generated by it are uniformly regarded as program data.

[flipper]

The files generated by SourceGit do not strictly distinguish between configuration files, cache data, solidified data, runtime process-related files, etc. All files generated by it are uniformly regarded as program data.

On Windows? Correct

But on Linux config files are in .config/appname
And cache files are in .cache/appname

[flipper]

I saw your commits you did that was basically what this PR is doing. But you are hardcoding the values of XDG dirs. They are env vars. Not static values.

[love-linger]

But on Linux config files are in .config/appname

In my opinion, the TRUE configuration files (those that need to be placed in the /etc/ or $XDG_CONFIG_HOME directories) are all files that require manual management (direct modification) by users. They are mostly applicable to system basic components and services. For GUI programs, even configuration settings should try to avoid direct editing by users (as they may fail to load due to format issues, etc.), and instead provide an interface for modification.

Many modern softwares directly use ~/.{app_name} to store all its generated files, including configurations and process-related data. For example: even git stores its global configuration directly in ~/.gitconfig.

I saw your commits you did that was basically what this PR is doing

Actually, they are not the same.

• Only changes related to the Linux platform are involved; other platforms remain consistent with previous behaviors.
• It does not distinguish between Config, Cache, and Process-related directories. P.S. this PR has a serious issue: when portable mode is detected, both CacheDir and RuntimeDir are empty values.
• Ensure that users of older versions can upgrade without noticing and retain their previous data.

But you are hardcoding the values of XDG dirs. They are env vars. Not static values.

Yes, this is intentional. I hope this path is preferably fixed and easy for users to find.

[flipper]

But on Linux config files are in .config/appname

In my opinion, the TRUE configuration files (those that need to be placed in the /etc/ or $XDG_CONFIG_HOME directories) are all files that require manual management (direct modification) by users. They are mostly applicable to system basic components and services. For GUI programs, even configuration settings should try to avoid direct editing by users (as they may fail to load due to format issues, etc.), and instead provide an interface for modification.

Ideally they should be edited by the GUI but it has nothing to do where the files are actually stored. It just following a standard pattern.

Many modern softwares directly use ~/.{app_name} to store all its generated files, including configurations and process-related data. For example: even git stores its global configuration directly in ~/.gitconfig.

No. Modern software does not put itself in ~/.app_name. Even git uses ~/.config/git/config
Process-related data has always been in /run/user/1000/(whatever)

I saw your commits you did that was basically what this PR is doing

Actually, they are not the same.

* Only changes related to the Linux platform are involved; other platforms remain consistent with previous behaviors.

* It does not distinguish between `Config`, `Cache`, and `Process-related` directories. P.S. this PR has a serious issue: when portable mode is detected, both `CacheDir` and `RuntimeDir` are empty values.

* Ensure that users of older versions can upgrade without noticing and retain their previous data.

But you are hardcoding the values of XDG dirs. They are env vars. Not static values.

Yes, this is intentional. I hope this path is preferably fixed and easy for users to find.

There is no point of hardcoding the paths when there is ENV vars to use. If an advanced user has their XDG_CONFIG_HOME set to /tmp. The app should follow it.

Portable mode is for Windows only. CacheDir is set to application data and same with runtime dir. See the table here:
https://xdg-net.github.io/Xdg.Directories/docs/defaults.html

[love-linger]

Just run ls -a under your home dir. For example, here's mine:

.ssh/
.vscode/
.gnupg/
.dotnet/
.gitconfig

[love-linger]

There is no point of hardcoding the paths when there is ENV vars to use. If an advanced user has their XDG_CONFIG_HOME set to /tmp. The app should follow it.

Now, SourceGit clearly stores its data into ~/.sourcegit dir (it has nothing to do with XDG_XXX_HOME envs). All the files under this folder is datas (that means you can use SourceGit without any configuration file). Event preference.json is just a file that stores current state of SourceGit, it's not a configuration file, remember.

[flipper]

Just run ls -a under your home dir. For example, here's mine:

.ssh/
.vscode/
.gnupg/
.dotnet/
.gitconfig

And? Applications are adapting the XDG standard. If you google how to edit your gitconfig everyone says edit ~/.gitconfig. But git actually supports reading from ~/.config/git/config.
I do not see the reason to follow old patterns.

You can read more about the standard here: https://wiki.archlinux.org/title/XDG_Base_Directory

[flipper]

There is no point of hardcoding the paths when there is ENV vars to use. If an advanced user has their XDG_CONFIG_HOME set to /tmp. The app should follow it.

Now, SourceGit clearly stores its data into ~/.sourcegit dir (it has nothing to do with XDG_XXX_HOME envs). All the files under this folder is datas (that means you can use SourceGit without any configuration file). Event preference.json is just a file that stores current state of SourceGit, it's not a configuration file, remember.

Okay. If you think it is more of a data file. Then that file should be in $XDG_DATA_HOME/SourceGit. But do not assume .local/share in the code. It is a env var for a reason.

Avatars is not a data file. It is a cache. So it should be in $XDG_CACHE_HOME/SourceGit/avatars/