I was playing around with .gschema.xml files while developing a gedit plugin. A plugin can be installed locally, but when trying to save settings using the gsettings facilities one seems to be forced to be root to install the .gschema.xml file.

I was therefore looking for a good way to work around this, but found a possible difference in the use of XDG_DATA_DIRS in gsettings versus how the XDG base directory specification sees the use of it (see https://developer.gnome.org/basedir-spec/). 

This is at least what I understand reading the specification and what I would like to start a discussion here.

The XDG base specification states: 

### START CITATION ###
Referencing this specification
------------------------------

Other specifications may reference this specification by specifying the location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that:

    Such file should be installed to $datadir/subdir/filename with $datadir defaulting to /usr/share.

    A user specific version of the data file may be created in $XDG_DATA_HOME/subdir/filename, taking into account the default value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set.

    Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead. 
### END CITATION ###

The last paragraph tells me, that whenever a specification talks about looking in a XDG_DATA_DIRS subdirectory, also XDG_BASE_HOME (defaulting to "$HOME/.local.share/" if unset) should be taken into account. 

Expected:
---------

When I put my .gschema.xml files in $HOME/.local/share/glib-2.0/schemas/ and compile them using 'glib-compile-schemas' I would expect 'gsettings list-schemas' to list these too.

Actual:
-------

gsettings does not list these, as this CLI output shows:

$ echo $XDG_DATA_HOME

$ echo $XDG_DATA_DIRS
/usr/share/xubuntu:/usr/share/xfce4:/usr/local/share/:/usr/share/
$ pwd
/home/dinkel/.local/share/glib-2.0/schemas
$ ls
org.gnome.gedit.plugins.whitespace-remover.gschema.xml
$ glib-compile-schemas .
$ ls
gschemas.compiled  org.gnome.gedit.plugins.whitespace-remover.gschema.xml
$ gsettings list-schemas | grep 'whitespace-remover'
$ export XDG_DATA_HOME=$HOME/.local/share/
$ echo $XDG_DATA_HOME
/home/dinkel/.local/share/
$ gsettings list-schemas | grep 'whitespace-remover'

Note:
-----

When adding $XDG_DATA_HOME as a new directory to the $XDG_DATA_DIRS directories everything seems to work perfectly well:

$ export XDG_DATA_DIRS=$XDG_DATA_HOME:$XDG_DATA_DIRS
$ echo $XDG_DATA_DIRS
/home/dinkel/.local/share/:/usr/share/xubuntu:/usr/share/xfce4:/usr/local/share/:/usr/share/
$ gsettings list-schemas | grep 'whitespace-remover'
org.gnome.gedit.plugins.whitespace-remover

It is my understanding that a fix towards first looking into $XDG_DATA_HOME (or '$HOME/.local/share/' if not set) would conform to the specification and eases plugin development not only for gedit but also for Gnome3 shell extensions (which according to google suffer too from the current limitation).