gphoto / libgphoto2

The libgphoto2 camera access and control library.
GNU Lesser General Public License v2.1
1.05k stars 325 forks source link

Please support XDG base directory specification #994

Open shmerl opened 2 months ago

shmerl commented 2 months ago

Currently on Linux libgphoto creates $HOME/.gphoto directory when used. Please use XDG base directory specification to avoid cluttering $HOME.

shmerl commented 2 months ago

Looks like a dup of this bug, so I'll close this.

shmerl commented 2 months ago

Hm, on the other hand that's for the library, so may be it needs a separate one. So let's keep it open.

For me the problem occurs when using gwenview which relies on libgphoto2.

ndim commented 1 month ago

This is definitely an issue for the libgphoto2 library.

ndim commented 1 month ago

Trying to develop a way to achieve this.

The libgphoto2 code could, instead of just using ~/.gphoto

This would ensure migration to the new location.

What should happen if someone uses an older version of libgphoto2 which looks in ~/.gphoto/ after having used a version of libgphoto2 which moved ~/.gphoto/ to $XDG_CONFIG_HOME/gphoto/? It would then generate a new ~/.gphoto/ directory and generate a new ~/.gphoto/settings file with defaults.

To solve that, the new libgphoto2 could, after having moved ~/.gphoto/ to $XDG_CONFIG_HOME/gphoto/, create a symlink ~/.gphoto pointing $XDG_CONFIG_HOME/gphoto to let older libgphoto2 versions use the new directory. Then at some time in the future (say, in a year or two), libgphoto2 could change to remove the ~/.gphoto symlink (if it still points to $XDG_CONFIG_HOME/gphoto, of course).

This strategy should obviously apply on Linux, BSD, ...

Should it also apply on MacOS? Possibly.

And on Windows? Probably not. Right?

shmerl commented 1 month ago

Not exactly. If $XDG_CONFIG_HOME is defined - then use $XDG_CONFIG_HOME/gphoto (create it if it doesn't exist).

If it's not defined use $HOME/.config/gphoto (create it if it doesn't exist).

Plus before creating (if selected location doesn't exist) use that check for fallback you mentioned if you want to keep some backwards compatibility for a while.

I don't think you need to overcomplicate things with renaming and etc. Just support fallback for a while and then remove legacy path in the code completely (after a year or however long you decide).

It doesn't need to apply to macos and Windows, they don't follow XDG specification.