[PATCH] Add XDG_STATE_HOME

Simon McVittie smcv at collabora.com
Thu Jan 2 13:26:29 UTC 2020


On Sun, 22 Dec 2019 at 09:55:56 +0100, David Faure wrote:
> On mercredi 13 novembre 2019 09:45:23 CET Jonas DOREL wrote:
> >   - the benefit from having XDG_CONFIG_HOME split from XDG_DATA_HOME is
> > that you can use a VCS with it.
> 
> This is exactly one of the reasons in favour of XDG_STATE_HOME, indirectly:
> right now, there are many files in XDG_DATA_HOME that you would also want in 
> your CVS

Another heuristic that I've seen suggested for the decision about which
XDG directory to use, which is not identical to (and perhaps conflicts
with) this one, is: what should "reset to default settings" do?

If XDG_CONFIG_HOME was purely "settings" (for some value of "settings"),
and all "hidden user data" was in XDG_DATA_HOME, then deleting
XDG_CONFIG_HOME but leaving XDG_DATA_HOME intact would be an operation that
could make sense - that would reset preferences/settings/configuration to
default values, without discarding "hidden user data".

By "hidden user data" I mean non-document-oriented data that is normally
managed "implicitly" within an application, with no choice about its
storage location, and perhaps with a database-style UI, rather than via
File->Open and File->Save As. For example, your emails, calendar entries,
etc. in a PIM application like Evolution are usually treated as "part of
the app" rather than as user-visible files (although you can export and
import to/from files). Saved game states in a game are another common
example of this class of data, and most phone apps seem to use this model.

> Should ~/.local/share/applications/*.desktop move to ~/.config?

The Desktop Entry specification says they don't/won't, by referencing the
Base Directory specification.

    smcv


More information about the xdg mailing list