Store configuration according to XDG specification

[genodeftest]

In the old unix days applications stored all their configuration dirs and files in hidden directories under the users home dir. These worked well enough back then, since there weren't many applications storing stuff there. Nowadays however, there's typically about a hundred files and dirs in the users homedir. The freedesktop organization took it into their hands to change this, and wrote a specification how to handle such data which can be found at: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html I propose that LanguageTool follows the same guidelines, to remove the clutter from users homedirs by incorporating the basedir-spec as set by the freedesktop org, which would bring the config files into .config (the default for $XDG_CONFIG_HOME) .cache for caches etc.

There might even be a LibreOffice API to save the files in the libreoffice directory, which respects the XDG specification.

[danielnaber]

I'm not sure if this makes sense for a Java application that runs on all kinds of operating systems.

[ssokolow]

So LanguageTool will just store its settings in /home/username/AppData/LanguageTool or C:\Users\username\.languagetool\ then?

No matter what you do, there has to be at least some platform-specificity in storing configuration files if you don't want to annoy users, so it makes sense to use logic like this:

if Windows:
    Store roaming in `AppData` and non-roaming in `Local`
else if OSX:
    Store wherever Apple wants it stored
else:
    Store user data in `$XDG_DATA_HOME`, machine-specific (non-roaming) config in `$XDG_CONFIG_HOME`, and caches in `$XDG_CACHE_HOME`.

(Heck, worst case, use the XDG basedir spec everywhere, since Linux users can't mark non-dotfiles hidden and visit their homedir often, OSX will obey dotfile hiding, and Windows filesystems let you mark anything hidden while Windows users rarely visit their homedir itself.)

[genodeftest]

@ssokolow : That looks good to me.

[ssokolow]

In case it helps any implementers, the only major piece of the spec to keep in mind is the rules for fallbacks:

If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Beyond that, it's as simple as $XDG_DATA_HOME/LanguageTool/....

[pminos]

Maybe we should remove some GUI specific options/code (for example font settings, server settings, look and feel) from languagetool-gui-commons classes (mainly Configuration.java). We can use the new LocalStorage class for those options. This way the languagetool.cfg will hold only the options needed for LibreOffice.

We also have to decide if we should keep languagetool.cfg inside user.home. Are there any side effects if we move this file to another location?

What do you say?

[danielnaber]

Moving languagetool.cfg outside user.home would require some migration strategy so users don't lose their settings. I don't think it's worth it.

[pminos]

I can think one reason to keep the file in user home, if another third-party application would require the file to be there.

But if we don't care, the migration would require 5-10 lines of code and I could do it easily.

[pminos]

@danielnaber should we keep languagetool.cfg inside user.home? If this is the case then we should close this issue.

[danielnaber]

I suggest to keep it in user.home, yes.

[ssokolow]

Well, at least now I have a solid answer.

I'll add LibreOffice+LanguageTool to the list of profiles I'll need to make once I settle on an implementation approach for the sandboxing/containerization/bind-mount/LD_PRELOAD/whatever tool I plan to write to force inconsiderate games to stop using things like getpwuid to find $HOME so they can clutter it up with un-hidden save folders.

Still annoying though. It'll be a lot more awkward to maintain comfort with an application like LibreOffice which does also manipulate files I'm supposed to see in my file manager. (But, then, if I fix my "forced workaround" for LibreOffice, I'll have a ready-made solution for all future cases without having to get a patch accepted for every single one.)