Difference between revisions of "Talk:XDG Base Directory"

From ArchWiki
Jump to navigation Jump to search
(→‎libice: new section)
m (add signature)
 
(30 intermediate revisions by 8 users not shown)
Line 2: Line 2:
 
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)
 
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)
 
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)
 
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)
 +
 +
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)].  Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)
  
 
== Abuse of XDG_CONFIG_HOME ==
 
== Abuse of XDG_CONFIG_HOME ==
Line 12: Line 14:
 
::This is why adding {{ic|*}} to {{ic|GIT_DIR/info/exclude}} is so great.  I have no idea why people who are familiar with git don't do this by default.  This allows you to only track files you explicitly want to track with impunity.  But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control.  Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)
 
::This is why adding {{ic|*}} to {{ic|GIT_DIR/info/exclude}} is so great.  I have no idea why people who are familiar with git don't do this by default.  This allows you to only track files you explicitly want to track with impunity.  But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control.  Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)
  
== Expansion ==
+
== Should command-line history be data or cache? ==
  
{{ic|XDG_RUNTIME_DIR}} is set by pam_systemd, so for the majority of Arch installations it is already set - "some systems" is ambiguous. It might be more useful to mention {{ic|XDG_RUNTIME_DIR}} in [[init]] instead, together with {{ic|XDG_VTNR}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:48, 26 December 2015 (UTC)
+
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)
  
:Thanks, for the moment I've made [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory_support&type=revision&diff=413542&oldid=413478 this] edit: users on non-systemd machines will be able to adapt the information.
+
: Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in {{ic|XDG_DATA_HOME}} on the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in {{ic|XDG_DATA_HOME}}. [[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)
:If you have a good idea for mentioning those vars in [[init]], it can be interesting indeed.
 
:—[[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:10, 27 December 2015 (UTC)
 
 
 
::While certainly useful and relevant for [[init]], the article itself is short in the section. But [[Init#Dbus]] links out to [[Systemd/User#D-Bus]], which has a subsection [[Systemd/User#Environment variables]]. How about adding it there instead? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:27, 4 January 2016 (UTC)
 
 
 
:::If we can verify that neither variables are set in the user instance, then +1 for adding them to that section. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:16, 16 January 2016 (UTC)
 
 
 
The wiki does not indicate what {{ic|XDG_RUNTIME_DIR}} is set to (/run/user/$UID) This is the only XDG directory that isn't listed in the wiki and that information would have helped me. My edit was rejected as being redundant with the note. I'd suggest then that either the path be added to the note, or the note moved to the XDG_RUNTIME_DIR section and include the path there.
 
{{unsigned|05:28, 12 December 2016‎|Skimj}}
 
 
 
:The [https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html standard] does not specify any default path for {{ic|XDG_RUNTIME_DIR}} and we should not mix Arch-defaults with the standard paths. There is a link to [https://www.freedesktop.org/software/systemd/man/pam_systemd.html pam_systemd] which manages the variable.  -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:03, 12 December 2016 (UTC)
 
::I only disagree that providing a key peice of information about how a software program operates is outside the scope of the wiki. Note also that the current pam_systemd documentation is slightly wrong: $USER vs. $UID.
 
 
 
== Relevance of Arch-specific content on the ArchWiki ==
 
 
 
[[User:Earnest]] [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory_support&type=revision&diff=414374&oldid=413683 removed] some content by judging it as "irrelevant", despite being clearly related to Arch Linux. The goal of that section can't simply be to mirror the freedesktop.org specification, otherwise a simple link to it will be fine. I have [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory_support&diff=414375&oldid=414374 undone] the removal. Instead of starting an edit war, let's settle the issue here. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:11, 4 January 2016 (UTC)
 
 
 
:The article relies that those variables are set somewhere, and the bug report provides some historical background. That said, what Arch does is not part of the specification; so those lines should either be a Note (as we have now), or moved to a more appropriate section (or article?) and part of the regular text.
 
:In either case, it's preferable to have the text in one place, i.e. merge the two notes on Arch and {{ic|XDG_RUNTIME_DIR}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:14, 16 January 2016 (UTC)
 
 
 
::Since this is our only article that discusses the support for the specification (and it wouldn't make sense to have another), I think it's only natural that, even before talking about the various applications, we say how Arch itself supports it.
 
::If it was me, I'd take a different approach, and restructure the "The XDG Base Directory specification" section so that, instead of duplicating the upstream specification (which is as easy to read), its primary goal is indeed to introduce what variables have to be defined by end users in an Arch system, and which ones are set by default, still accompanying them with short descriptions of their purpose, so that using Notes isn't even necessary anymore. The section could be renamed to e.g. "Define the variables".
 
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:33, 17 January 2016 (UTC)
 
 
 
:::If you have a different approach in mind, could you make a draft here or on your user page?
 
:::About the variables, more expansive descriptions may be better suited for other articles, such as [[systemd/User]], as suggested in [[#Expansion]]. For example, compare [https://github.com/systemd/systemd/issues/232] for the importance of {{ic|XDG_RUNTIME_DIR}} to [[systemd/User]]. We could then link from here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 00:51, 29 January 2016 (UTC)
 
 
 
::::I didn't have anything complicated in mind, just rewriting the section intro from a different perspective, see [[User:Kynikos/XDG Base Directory support]] for an example. Note that [[Systemd/User#XDG_RUNTIME_DIR|XDG_RUNTIME_DIR]] is actually a link to [[Systemd/User#XDG_RUNTIME_DIR]] where I too think we should move the specific info. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:16, 30 January 2016 (UTC)
 
 
 
== <s>Sample the explicit XDG Base Directory environment variables setup</s> ==
 
  
:''[Moved from [[Talk:General recommendations]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 22 September 2016 (UTC)]''
+
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==
  
*Someone, more experienced in proper usage of XDG Base Directory environment variables, - can contribute configuration from his setup (that complies both Arch architecture an [https://standards.freedesktop.org/basedir-spec/latest/ar01s03.html XDG Base Directory Specification]). - [[User:PiroXiline|PiroXiline]] ([[User talk:PiroXiline|talk]]) 14:08, 20 September 2016 (UTC)
+
Using nvidia 390.25 and just noticed that it now stores its cache in $XDG_CACHE_HOME/.nv rather than ~/.nv and edited the page accordingly. I don't know if CUDA was also changed and don't know how to check. If someone else knows, please tell me or try it yourself and update the page if needed. I already checked nvidia-settings, it is not yet changed.
  
::This page provides a general overview, not specific procedures. In this case, those are already outlined in [[XDG Base Directory support]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:35, 21 September 2016 (UTC)
+
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)
  
:::I wrote here, because raising a post-install process addition is to start a discussion in 'General recommendations'. I could not start it in [[XDG Base Directory support]], and :::I wrote here, because raising a post-install process addition is to start a discussion in 'General recommendations'. I could not start it in [[XDG Base Directory support]], and start to explain the major point to add reference info from 'General recommendations' there. - [[User:PiroXiline|PiroXiline]] ([[User talk:PiroXiline|talk]]) 14:19, 22 September 2016 (UTC)
+
== <s>Suggestions for GnuPG</s> ==
  
:::Here is proposition of sample from my setup:
+
Current suggestion for [[GnuPG]] is
  
----
+
{{bc|1=$ export GNUPGHOME="$XDG_CONFIG_HOME"/gnupg<br>
==== Explicitly set XDG Base Directory environment variables ====
+
$ gpg2 --homedir "$XDG_CONFIG_HOME"/gnupg}}
  
By default in Arch ''XDG Base Directory environment variables'' are empty, relaying on [https://standards.freedesktop.org/basedir-spec/latest/ar01s03.html XDG Base Directory Specification defaults].
+
However, GnuPG places more than configuration files in {{ic|$GNUPGHOME}}. For example, in my machine I have following files
  
If these variables are empty, some programs doesn't comply to specification, and place their data in {{ic|$HOME/.app-folder}}. In {{ic|$HOME/.app-folder}} application starts to store all it's information (configuration files, data, and cache simultaneously). While ''XDG Base Directory'' usage requires separation of configuration files, data, and cache.
+
* {{ic|pubring.kbx}}
 +
* {{ic|trustdb.gpg}}
  
Changing the environment variables after these programs placed their data in {{ic|$HOME/.app-folder}}, creates a problem of separation and linking all applications to configuration files, data and caches. Otherwise default application behavior is to populate new directories with default configuration, data and caches.
+
Both are binary files. According to the name they are the public key ring and some database. I don't think they belong to {{ic|$XDG_CONFIG_HOME}}. Maybe we should specify their path manually, to re-direct them to somewhere in {{ic|$XDG_DATA_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 21:13, 14 November 2018 (UTC)
  
So a good workaround to that issue is set ''XDG Base Directory environment variables'' after [[Installation guide|Arch Linux basic installation]] during [[General_recommendations|post-install process]]. While system is in clear state.
+
: I did the modification since no objection. --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 02:32, 31 May 2019 (UTC)
  
To explicitly set ''XDG Base Directory environment variables'' to proper defaults:
+
== Add description of support categories ==
  
{{hc|~/.pam_environment|
+
Hi, do you think we could add a description of what each categories (Supported, Partial, Hardcoded) means? For example, I don't know where to put things like the following:
2=XDG_CONFIG_HOME=/home/''user''/.config
+
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables
XDG_DATA_HOME=/home/''user''/.local/share
+
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''
XDG_CACHE_HOME=/home/''user''/.cache
+
* app where we can use alternative methods (environment variable, option, ...) for specific files
XDG_DATA_DIRS=/usr/local/share/:/usr/share/
+
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])
XDG_CONFIG_DIRS=/etc/xdg
 
}}
 
  
{{Note|[[Environment_variables#Defining_variables|Environment file]] {{ic|~/.pam_environment}} does not provide support for globing or variable expansion of shells, so '{{ic|$HOME}}' or '{{ic|~}}' taken as literal relative directory names.}}
+
Maybe we could make those categories evolve, either by refactoring the categories (creating new ones), and/or putting the categories directly in the table (still allowing seeing programs per category)?
{{Note|If no path specified in ~/.pam_environment is not absolute path, than path relative to ''user'' {{ic|$HOME}} is implied.
 
So it also can be:
 
  
{{hc|~/.pam_environment|
+
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)
2=XDG_CONFIG_HOME=.config
 
XDG_DATA_HOME=.local/share
 
XDG_CACHE_HOME=.cache
 
XDG_DATA_DIRS=/usr/local/share/:/usr/share/
 
XDG_CONFIG_DIRS=/etc/xdg
 
}}}}
 
  
{{ic|XDG_''*''_HOME}} variables has priority over {{ic|XDG_''*_DIRS}}.
+
== Should Organizations/DEs be mentioned? ==
 
 
----
 
 
 
::Many things not obvious in [[Environment_variables#Defining_variables]] and specs, that is why I checked it by try and error and made a notes to users. Maybe that notes need to be merged in Environment_variables#Defining_variables, I rely on your opinion.
 
::I, for myself, also added to {{ic|XDG_DATA_DIRS}} and {{ic|XDG_DATA_DIRS}} some additional cross-reference paths, for a purpose cleaning-up and some live migration. So apps look in more places to find their configs/data/caches.
 
:: So also can be added Tip:
 
:: {{Tip|On manual migration, cross-reference paths can be added to end of {{ic|XDG_*_DIRS}}, if needed. So application, after {{ic|XDG_''*''_HOME}}, going to look in {{ic|XDG_''*''_HOME}} with more places to find configuration, data and cache.}} -- [[User:PiroXiline|PiroXiline]] ([[User talk:PiroXiline|talk]]) 14:38, 22 September 2016 (UTC)
 
 
 
:::The first part gives the impression that setting {{ic|XDG_*}} variables is somehow going to make applications which do not respect the specification comply, which is obviously false.
 
 
 
:::The second part duplicates [[Environment variables]]. If something is not clear in that article, mention it on the talk page: [[Talk:Environment variables]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:47, 22 September 2016 (UTC)
 
 
 
== Arch package page, or project page? ==
 
 
 
Currently in the ''Application'' column of the tables, there are three types of links: wiki links like [[fish]], package links like {{Pkg|ncurses}} (including AUR like {{AUR|sublime-text-dev}}), and project links like [https://github.com/Antimicro/antimicro/ antimicro]. Is there any consensus about the preference of these three types? I suggest wiki links over package over project links, because:
 
 
 
# Wiki pages have more information, and typically contains both package links and project links.
 
# Package pages contains project links, along with some information useful to Arch users.
 
 
 
Thoughts? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:28, 22 April 2017 (UTC)
 
 
 
:To be honest I'm not sure why this page even contains package links; we have [[List of applications]] and dedicated articles where we already keep those links up-to-date. Using wiki links instead does sound like a better idea. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:47, 22 April 2017 (UTC)
 
 
 
:: So you prefer project links over package links? Or no link at all, if the application does not have a Wiki link? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 06:22, 23 April 2017 (UTC)
 
 
 
== Should command-line history be data or cache? ==
 
 
 
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)
 
 
 
: Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in {{ic|XDG_DATA_HOME}} on the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)
 
  
== libice ==
+
Kind of obvious that the major DEs follow the spec since Freedesktop.org is mainly run by those groups, but I think that that's not obvious from this article. I think it's important to mention how KDE, GNOME, Qt, GTK, Debian, Ubuntu, Red Hat, etc. are following the spec. Since they're not single applications they don't really fit in any of the main sections, but I think they definitely deserve the mention.
  
I didn't bother to check out who added the libice bit, but it can be quite dangerous to set that with e.g. gdm, as gdm wants to have a look at the user's ICEauthority for handing off the login session to the user. If one stores it in XDG_RUNTIME_DIR, gdm is not very forthcoming with the debug messages, and if you don't start rolling back your etckeeper, you'll spend a long time debugging what happened.
+
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)

Latest revision as of 21:35, 9 September 2019

emacs

Has anyone looked at XDG Directories for emacs? Ben Creasy (talk) 02:40, 15 July 2015 (UTC)

It seems that still needs an ~/.emacs, so I'm unsure it's a great improvement over a single ~/.emacs.d. That said, you could try to start emacs with the --load or --directory argument. -- Alad (talk) 09:15, 1 September 2015 (UTC)

Emacs should be XDG-aware in the first 27.* release (see this commit). Not sure if this warrants updating the table yet. Odnir (talk) 22:00, 28 August 2019 (UTC)

Abuse of XDG_CONFIG_HOME

I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to .gitignore, because they all abuse the $XDG_CONFIG_HOME path for the purpose of persistent cache, which is $XDG_CACHE_HOME. A typical config file of a Qt programs looks like this, notice especially the recentFileList, geometry and windowState keys -- IMHO this is exactly the stuff that belongs to $XDG_CACHE_HOME or $XDG_DATA_HOME. The Qt programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there extension-errors.log, syncthing even the entire database. What shall we do about this? There are not many graphical programs in the tables on this page, but inkscape is listed under "Supported", which is not entirely true... -- Lahwaacz (talk) 22:12, 21 August 2015 (UTC)

The article uses "workarounds [that] will be limited to anything not involving patching the source, executing code stored in environment variables or compile-time options." as an arbiter for the "Partial" category, and anything more complicated than that for "Hardcoded". I.e., categorization is based on what's needed to moving dotfiles from $HOME to some, hopefully correct, XDG directory or directories.
One way to supplement this would be the Notes column in the Supported category (which is now mostly empty anyway), to expand on programs which don't follow the intent of the XDG directories or which just lazily stack things together. -- Alad (talk) 09:08, 1 September 2015 (UTC)
This is why adding * to GIT_DIR/info/exclude is so great. I have no idea why people who are familiar with git don't do this by default. This allows you to only track files you explicitly want to track with impunity. But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control. Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... Earnest (talk) 15:31, 12 September 2015 (UTC)

Should command-line history be data or cache?

Should they be placed in XDG_DATA_HOME, or XDG_CACHE_HOME? --Franklin Yu (talk) 20:07, 16 May 2017 (UTC)

Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in XDG_DATA_HOME on the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in XDG_DATA_HOME. —Ayekat (talk) 22:30, 16 May 2017 (UTC)

nvidia uses XDG_CACHE_HOME, how to test CUDA?

Using nvidia 390.25 and just noticed that it now stores its cache in $XDG_CACHE_HOME/.nv rather than ~/.nv and edited the page accordingly. I don't know if CUDA was also changed and don't know how to check. If someone else knows, please tell me or try it yourself and update the page if needed. I already checked nvidia-settings, it is not yet changed.

Cyant (talk) 11:55, 25 February 2018 (UTC)

Suggestions for GnuPG

Current suggestion for GnuPG is

$ export GNUPGHOME="$XDG_CONFIG_HOME"/gnupg
$ gpg2 --homedir "$XDG_CONFIG_HOME"/gnupg

However, GnuPG places more than configuration files in $GNUPGHOME. For example, in my machine I have following files

  • pubring.kbx
  • trustdb.gpg

Both are binary files. According to the name they are the public key ring and some database. I don't think they belong to $XDG_CONFIG_HOME. Maybe we should specify their path manually, to re-direct them to somewhere in $XDG_DATA_HOME? --Franklin Yu (talk) 21:13, 14 November 2018 (UTC)

I did the modification since no objection. --Franklin Yu (talk) 02:32, 31 May 2019 (UTC)

Add description of support categories

Hi, do you think we could add a description of what each categories (Supported, Partial, Hardcoded) means? For example, I don't know where to put things like the following:

  • app that use a hardcoded ~/.config, not using the XDG variables
  • app that use the XDG_CONFIG_HOME for everything
  • app where we can use alternative methods (environment variable, option, ...) for specific files
  • app where we can use alternative methods, freeing $HOME, but not using the correct path for each file (config vs cache vs data) (for example, GnuPG)

Maybe we could make those categories evolve, either by refactoring the categories (creating new ones), and/or putting the categories directly in the table (still allowing seeing programs per category)?

Apollo22 (talk) 13:58, 14 March 2019 (UTC)

Should Organizations/DEs be mentioned?

Kind of obvious that the major DEs follow the spec since Freedesktop.org is mainly run by those groups, but I think that that's not obvious from this article. I think it's important to mention how KDE, GNOME, Qt, GTK, Debian, Ubuntu, Red Hat, etc. are following the spec. Since they're not single applications they don't really fit in any of the main sections, but I think they definitely deserve the mention.

Hobyamnlyzfsr (talk) 21:35, 9 September 2019 (UTC)