Re: gtk3: FileChooser schema not found

[Emmanuele Bassi <ebassi gmail com>]

On Wed, 2011-02-16 at 11:19 +0100, David NeÄas wrote:

> > > Gtk+ itself (not any dependency) installs this scheme file.
> > > It knows exactly, at compile time, where the file will be installed.
> > > So why it cannot find the file?
> >
> > it could be that XDG_SHARE_DIR is unset, or not set to include your
> > $prefix/share.
>
> Well, this describes the mechanism how it happened but does not answer
> why.

it does. the location is system-dependent, to allow overriding and
setting up development environments.

>   If you read the question
>
>     It knows exactly, at compile time, where the file will be installed.
>     So why it cannot find the file?

> it makes sense whether any XDG-foo gets involved or not.

no, it doesn't. hardcoding to a specific path would make it impossible
to cross-compile, or relocate, or configure the location of schemas.

that's why the path for searching schemas includes an well-known,
standardized environment variable.

also, you're misunderstanding which component is actually loading the
schema.

all gtk+ does is calling:

  settings = g_settings_new ("org.gtk.Settings.FileChooser");

then it's up to GSettings to find the schema matching that name.

GSettings is provided by GIO, which sits underneath gtk+. the location
for GSettings schemas is well-known and it can be controlled using an
environment variable. gtk+ uses that well-known location to install the
files. at runtime, it's GSettings that has to load the schema - so it
has to find the file within a set of paths. if it cannot find it then:
a) there was a bug and the file was not installed or b) the file was
installed in a different path that is not included in the list.

>   The question
> is why something that is both perfectly reasonable to expect do work and
> very easy to make work does not work?  Why it is intentionally broken?

you think it's broken; I call it being flexible.

> A package that requires to set some environment variables after
> installation to tell it where its parts were installed (if nothing has
> been moved elsewhere!) is broken.  There's no other word for it.

you're assuming too much.

a package that allows relocatability, cross-compiling and configuration
it's not broken, as much as you think so.

> If the corresponding freedesktop standard *forbids* Gtk+ from just
> working then this standard is broken and needs to be ammended/ignored.

again, you're assuming far too much.

the default value for XDG_SHARE_DIR is /usr/share. if you installed in a
different prefix then the XDG_SHARE_DIR environment variable must be
updated to include it, otherwise not only gtk+ won't work - but a whole
lot of applications will not be able to find their own shared data.

it's like complaining that compiling a gtk+ application fails because
the pkg-config file has been installed in a location different than the
ones defined in PKG_CONFIG_PATH - and thus it's gtk+ being broken since
it doesn't install the pkg-config file in an hard-coded location.

if gtk+ cannot find the files it installed then, assuming it's not a
build bug in gtk+ itself, then it's just an issue of how your system is
set up. this is perfectly reasonable, and applies to basically all
libraries and applications.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi