Adherence to XDG Base Specification

[Daeraxa]

Started from this Discord conversation

So I'm almost certain this question will come up eventually so thought it best to pre-empt it seeing as it has frequently come up on the Joplin project.

Basically it seems that Pulsar (by way of Atom) has its Config folder set to ~/.atom on Linux (and macOS).
This by itself isn't really an issue as such but there is mounting pressure for projects to correctly adhere to the XDG Base Directory Specification rather than forcing configuration files and application data to write to a specific location chosen by the developers.

Pulsar/Atom can already be made to adhere to it by exporting ATOM_HOME: export ATOM_HOME="$XDG_CONFIG_HOME"/atom (and the same for apm).

There are a few benefits to supporting the XDG spec:

1. People won't comment all the time and raise issues asking for it
2. It gives people more control over their home directories
3. It better supports some native features in the Appimage format
4. It better supports the sandboxing inherent to the Snap and Flatpak formats (see the Flathub script for modifications done to make it work correctly for Flatpak)

We are at a point, being at the very start of the project really, where we could look at implementing this with as little impact on users as possible.

There are potentially a few things we would need to look out for, such as any quirks or clashes with the portable mode.

One thing of note is that Electron by default already does seem to support $XDG_CONFIG_HOME as this is where it will write the Atom electron cache (~/.config/Atom) and it does change location depending on the location of your $XDG_CONFIG_HOME.

The other question is, what is actually the correct place. You will note that both the Arch wiki page on the topic recommends setting ATOM_HOME to $XDG_DATA_HOME rather than $XDG_CONFIG_HOME as does the Flatpak script above.
So either we would need consensus as to which is correct or we look at splitting the current .pulsar directory between them to support both data (packages in particular) and config files in different places.

Another alternative is that we put the ~/.pulsar inside the existing $XDG_CONFIG_HOME/Pulsar Electron cache folder - which is exactly what VSCode seems to do. Then we only have one folder to worry about and not two.

There are a few more resources if you want to have a look at other info or conversations on the topic.

• XDG Base Directory Specification
• DistroTube video on the topic
• Arch wiki page on the topic
• My own post to the Joplin forums on this exact same topic

[confused-Techie]

While, admittedly, I don't have much skin in this game. Of course I'd vote we use this standard in some way, since like you said allowing users better control over their systems should be a priority. But otherwise it likely will be much simpler to use a single directory. Because then we just worry about setting ATOM_HOME instead of having to create ATOM_CONFIG_HOME and ATOM_DATA_HOME and finding every single relevant place in the code to change it.

And personally I'd vote that to me, the config directory makes since. Since really no matter what that folder will contain a config. It won't always contain packages, unless the user installs them. So to me that seems like the right choice

[daleeidd]

I think it is important to also part out anything that is considered cache into XDG_CACHE_HOME so the OS can clear it if needed and it will be excluded from backups. Also, some people version control XDG_CONFIG_HOME so parting out Pulsar between XDG_CONFIG_HOME and XDG_DATA_HOME is also valuable but not as important.

[Daeraxa]

I wonder if we could/should at look at implementing https://github.com/folder/xdg. It deals with all major OS paths, not just XDG on Linux.

[confused-Techie]

This looks really cool! I'd honestly be very on board with utilizing something like this, the only potential issue is taking a quick look at it, seems that it will list paths with directories and such that do not yet exist. Meaning we will have to handle that reality elsewhere in the code. But generally, this looks like it could be extremely useful.

A note I'd like to make though, is ideally we also allow these locations to be totally configurable. Plus we will still have to maintain some logic here, an easy example is the Pulsar exe looking nearby for a config folder when running in portable mode, but this seems like a great way to simplify our lives with using the right locations, while not having to do this research ourselves

[Daeraxa]

I found it via https://dotfiles-matter.click/ (to give credit). There are definitely a few things we would have to work out above my simplistic PoC PR which pretty much just changes the initial location of ATOM_HOME. Also no idea if the Windows stuff looks like it makes any sense or not, I still haven't fully got my head around what is correct or not in Windows land.