Add ability to move ~/.processing directory

[processing-bot]

Created by: Addisonbean

Description

Processing uses ~/.processing for it's data with no way to change that. It would be nice to be able to control the location of that directory so it can follow XDG directory specifications and keep users home directories clean.

Expected Behavior

Processing should provide an environment variable to control where the processing data directory is found, and fall back to ~/.processing if not specified.

Current Behavior

There is no clearly documented way to move ~/.processing to another location (there may be a way, however I was not able to find it via processing-java --help or the online documentation).

Steps to Reproduce

N/A

Your Environment

• Processing version: 3.5.4
• Operating System and OS version: Arch Linux (Linux kernel 5.9.3)
• Other information: $XDG_CONFIG_HOME and $XDG_DATA_HOME are set and were not used by processing when deciding where to create this directory

Possible Causes / Solutions

Add an environment variable that can provide an alternate location for ~/.processing, and fall back to the old location if not specified.

An even better solution would be to default to ~/.config/processing unless $XDG_CONFIG_HOME is set or if ~/.processing already exists.

[processing-bot]

Created by: benfry

Thanks for the report… I see the .config location in use on a couple Linux machines here so that makes sense; is there any documentation on how widespread this is/which systems are likely to expect things there? Is it an XDG thing? Limited to GUI apps? Just looking for any sort of spec/references I can use to make the right call here (and revise my 90s UNIX thinking…)

[processing-bot]

Created by: Addisonbean

Yes, ~/.config is part of the XDG Base Directory Specification.

Here's an incomplete list of common applications that use XDG directories by default (including ~/.config): https://wiki.archlinux.org/title/XDG_Base_Directory#Support

XDG isn't limited to any particular kind of program. Notable tools from that list which use XDG directories to determine config locations include git, neovim, tmux, Android Studio, Blender, emacs, LibreOffice, wireshark, pulseaudio, htop, and more. The link on the Arch Wiki above has links to bug reports on many of these projects, which shows many users view lack of XDG support as a bug.

I know using XDG directories for config and related files is expected by many Linux users across many distros, but I don't know about the "standard" on macOS. I know many of those apps I listed use ~/.config for config, while others use ~ or even ~/Library/Application Support. ~/Library/Application Support and ~/.config seem like the two most appropriate options on macOS to me.

[processing-bot]

Created by: benfry

Perfect, thanks; that's the information I was looking for.

(Moving this over to the 4.x repository so I can work on it there.)

[processing-bot]

Created by: benfry

And back to your original request, would we be covered by using ~/.config/processing by default instead of ~/.processing? It seems like that's the direction we should be going here (and is a lot more straightforward than reading an environment variable for the location, and then needing to document that somewhere, testing it on various devices, etc).

[processing-bot]

Created by: Addisonbean

Personally, yes that would make me happy. However I imagine someone at some point will want it elsewhere, plus I like the flexibility offered by being able to move it anywhere so I think it's a good idea anyway. It seems weird to me to not have a way to change the location of the config, but it's not something I see myself using so I don't really care.

[processing-bot]

Created by: benfry

Ok, this is now implemented for 4.0 beta 1. Instead of the home directory, it'll use $XDG_CONFIG_HOME if it's available, or ~/.config if not.

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.