GNOME Bugzilla – Bug 690282
Load per-user plugins from $XDG_DATA_DIRS
Last modified: 2019-02-22 03:17:13 UTC
Currently user-level plugins can only be installed by creating / modifying ~/.config/eog/plugins. It would be cleaner and more extensible to be able to provide plugins by adding entries to $XDG_DATA_DIRS, so that eog would look for plugins in: - the system location - ~/.config/eog/plugins - $PREFIX/eog/plugins for PREFIX in $XDG_DATA_DIRS (a colon-separated path list) Gnome Shell (and potentially others, gnome-shell is the only other gnome software I've written plugins for) supports this exact mechanism, so it's not without precedent.
Yeah, actually ~/.config sounds really wrong for user-plugins. Does gnome-shell really support that prefix? The prefix I'd rather use (and preferably as the only one for user-plugins) would be XDG_DATA_HOME which would be something like ~/.local/share(/eog/plugins/*) which would match where my local gnome-shell and gedit extensions are placed.
Ahh yes, sorry I wasn't very clear - I just meant that gnome-shell supports loading from $XDG_DATA_DIRS, rather than claiming it matches all of the three locations I listed. You're right, gnome-shell uses $XDG_DATA_HOME and $XDG_DATA_DIRS (and does not use ~/.config), and I agree that eog should do the same.
commit 3ee8acc593524eec5ca8a6e5e782f7ee44cbd138 Author: Felix Riemann <friemann@gnome.org> Date: Wed Dec 19 19:55:09 2012 +0100 Don't use XDG_CONFIG_DIR for per-user plugins Load them from XDG_USER_DATA_DIR instead to be in line with other applications using plugins like gnome-shell and gedit. https://bugzilla.gnome.org/show_bug.cgi?id=690282 --- This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
The commit above changes the per-user path (which is good), but doesn't actually address the initial request to load plugins from [$PREFIX/eog/plugins for PREFIX in $XDG_DATA_DIRS]. Is it possible to add this as well? If it's useful, the gnome-shell code to traverse these directories is here (in JS, but using gobject): http://git.gnome.org/browse/gnome-shell/tree/js/misc/fileUtils.js?id=a786a7dc558b904d942d76e5c525034626e271e6#n56
Oh, okay general misunderstanding here (I also botched up the commit message). So now we look for user-level plugins in $XDG_DATA_HOME and fallback to the system-level plugins which are in a hardcoded path (which in most cases happens to be the default $XDG_DATA_DIRS prefix). Actually I am not a fan of putting user-level plugins in a XDG_DATA_DIRS prefix which is already system-level. Also this could end us to many many many prefixes which need to be searched for plugins. I doubt this won't affect the application startup speed besides adding another level of complexity to plugin loading.
What's your use case for this?
Ahh, I may have caused additional confusion by calling them "user" plugins. You mentioned that system plugins are searched on a hard-coded path, which usually happens to correspond to $XDG_DATA_DIRS. If that was changed to actually *use* $XDG_DATA_DIRS I would be happy - i.e. I don't mind whether they're considered user or system plugins, as long as they can be made active by the user modifying their own environment variables, and without requiring root access. My specific use case is packaging plugins via a ZeroInstall feed (http://0install.net). This implies the following restrictions: - runnable by a user (no root) - no hard coded paths (multiple versions of any library / application coexist by default, and the required version is activated by altering environment variables when launching software). In general, the use case is allowing plugins to be made available to the current user without requiring root access or fighting over ownership of a single directory. I could hack around it by writing a script that "runs" my plugin by adding symlinks to ~/.config/eog/plugins and later remove the stuff it added, but: - this is hacky, and likely to leave cruft around when things crash - it requires a chain of wrapper scripts be run before and after launching eog (one for each plugin) It seems to me that $XDG_DATA_DIRS (and the associated xdg support in gnome / gobject) exists exactly to allow the layering of multiple sources of plugins (and other things), so I'm hoping eog can make use of that.
commit b13d8592c0cca05ccb9a6d1038e834fbb97c8b73 Author: Felix Riemann <> Date: Mon Jan 14 19:32:22 2013 +0100 Add XDG_DATA_DIRS to plugin search path Also add some debug output to ease debugging possible problems later. https://bugzilla.gnome.org/show_bug.cgi?id=690282 --- This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.