Making GTK applications in alternate locations, settings edition
Suppose, not entirely hypothetically, that you build your own copy
of some moderately complicated GTK application
and install it a non-standard location with the equivalent of
'configure --prefix /some/where
'. In theory you can then just run
the application as /some/where/bin/prog
and everything will be
great. As I found out today, in practice you may have a subtle
problem (or if you're unlucky, a not so subtle one).
GTK applications use a system for handling their settings and preferences called 'GSettings', which uses XML schema files to define all of this stuff for a particular application. By default, an application only looks for its settings schema in the system directories, even if it knows full well that its settings schema file was actually installed elsewhere. If you don't have any version of your application installed as part of the system, your own version will probably fail because it can't find its schema at all. If you do have some system version of your application installed, your own version is probably actually using the settings file from that version.
To fix this, you need to set the $XDG_DATA_DIRS
environment
variable so it includes the right directory for your application.
If you configured with a prefix of /some/where
, your schema
files get put into /some/where/share/glib-2.0/schemas
and
$XDG_DATA_DIRS
must include /some/where/share
. According
to the XDG Base Directory Specification,
the default value for it is /usr/local/share/:/usr/share
(and this
agrees with what I see in testing). So you want a cover script that
does this:
export XDG_DATA_DIRS=/some/where/share:/usr/local/share:/usr/share exec /some/where/bin/prog "$@"
(This behavior is documented in the glib-compile-schemas
manpage.)
There may be other things that GTK applications only look for in system areas, but if so I haven't tripped across them yet for the couple of GTK based applications I compile myself.
(Before you're tempted to throw stones at GTK for not fully supporting installing and running applications from other prefixes, note that KDE is worse for this as far as I know. I had to resort to building and installing RPMs for my locally compiled KDE application. Maybe there's a magic environment variable for it too that I just didn't stumble over.)
|
|