Linux, Supporting the XDG Base Directory Specification.

[Earnestly]

Within the Linux Desktop universe we suffer from a great deal of ‘dotfile’ clutter in our home directories.

This dotfile stemmed from an old bug1 in UNIX which caused ls to ignore anything starting with . or .. to avoid printing those particular files.

Since then developers have used this to store all manner of files and directories under $HOME much to the chagrin of many users.

In an effort to combat this perennial problem the XDG Base Directory Specification2 was formed to help users select where configuration files and cache data should be stored and providing a consistent location for both configurations and cache data alike.

---

I would like to propose a feature request which would allow FontForge to comply with this specification. This could change in the following way:

$HOME/.FontForge → $XDG_CONFIG_HOME/FontForge #or …/fontforge

If we were to overthink the requirements one may consider:

$HOME/.FontForge → $XDG_CONFIG_HOME/FontForge

$HOME/.FontForge/autosave → $XDG_CACHE_HOME/FontForge/autosave
# or
$HOME/.FontForge/autosave → $XDG_DATA_HOME/FontForge/autosave

Personally I am not greatly concerned if just XDG_CONFIG_HOME is honoured and other considerations are dropped for the sake of simplicity.

Thank you for reading,
Hopefully, Earnest.

[holomorph]

There are a few functions having something to do with $HOME/.FontForge

(1) fontforge/autosave.c: char *getPfaEditDir(char *buffer)
(2) fontforge/startui.c: static void ensureDotFontForgeIsSetup()
(3) gutils/fsys.c: char *GFileGetHomeDir(void)
(4) gutils/fsys.c: char *getDotFontForgeDir(void) (unused function)

(2) basically does mkdir -p GFileGetHomeDir()/.FontForge/python whether python is enabled or not. It seems like everything uses (1) to know where to put stuff. Inserting the logic for controlling the fontforge 'configuration' directory into (1) and (2) is sufficient to honor XDG_CONFIG_HOME for instance.

Putting all the user directory logic into one function would probably be nice and clean:

enum { Cache, Config, Data };
char *getFontForgeUserDir(int dir);

[davelab6]

I'll be very happy to take a pull request to do this :)

[holomorph]

What kind of freedom do I have? I guess the general idea is replacing getPfaEditDir, which I've done. Doing so implies throwing away some consideration for __VMS and renaming of ~/.PfaEdit. I've really just kept MINGW32, which puts everything into %APPDATA%/fontforge or whichever on Windows.

I have getFontForgeUserDir in gutils/fsys.c and the declarations in inc/gfile.h. I think I can replace getPfaEditDir by including that header in fontforgevw.h, but it's hard to tell. If you can offer some guidance I'd appreciate it.