GSettings schemas

2016-02-11 Thread Fabian Harfert
Hi!

Trying to use some successfully built packages I noticed that they fail
to start because of missing installed GSettings schemas. When the
profile is build, each package, that has a gschemas.compiled file in
its share/glib-2.0/schemas/ directory overides the one of the last
package so that lots of schemas are missing.

I think it would be enough to just call 'glib-compile-schemas' with the
profile output directory as an argument after all packages are in the
profile, where their XML schema files live in share/glib-2.0/schemas/.
That would generate one gschemas.compiled for all of them.

WDYT?

Fabian



Re: GSettings schemas

2014-09-23 Thread Mark H Weaver
l...@gnu.org (Ludovic Courtès) writes:

 Federico Beffa be...@ieee.org skribis:

 I've found that setting the environment variable GSETTINGS_SCHEMA_DIR
 solves the problem.

 $ 
 GSETTINGS_SCHEMA_DIR=/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/share/glib-2.0/schemas
  emacs

 Can the schema location be fixed at configure/compile time?

 We could use ‘wrap-program’ to set that variable for Emacs, but we need
 to address that problem more generally.

This 'wrap-program' strategy of setting environment variables before
running a program has problems.  In this case, it means that every
program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value.

Along the same lines, I've noticed that when running WindowMaker, all of
the programs within my X session include a WindowMaker-specific
directory at the front of PATH.

It would be good to find another solution.

  Mark



GSettings schemas

2014-09-22 Thread Ludovic Courtès
Federico Beffa be...@ieee.org skribis:

 (emacs:33176): GLib-GIO-ERROR **: attempting to create schema 
 'org.gtk.Settings.FileChooser' without a path

 Program received signal SIGTRAP, Trace/breakpoint trap.
 0x74dfd0ba in g_logv () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
 (gdb) bt
 #0  0x74dfd0ba in g_logv () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
 #1  0x74dfd212 in g_log () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libglib-2.0.so.0
 #2  0x75f6af54 in g_settings_constructed () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgio-2.0.so.0
 #3  0x750f433a in g_object_new_internal () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
 #4  0x750f6444 in g_object_new_valist () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
 #5  0x750f6834 in g_object_new () from 
 /gnu/store/7v44p77l3867slbpnamzs5jgbyps2v7q-glib-2.40.0/lib/libgobject-2.0.so.0
 #6  0x76830e9c in _gtk_file_chooser_get_settings_for_widget () from 
 /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
 #7  0x76828130 in gtk_file_chooser_default_get_default_size () from 
 /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0
 #8  0x7682eda4 in file_chooser_widget_default_size_changed () from 
 /gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/lib/libgtk-3.so.0

[...]

 #24 0x004cc010 in xg_get_file_with_chooser ()
 #25 0x004d00ea in xg_get_file_name ()
 #26 0x004bd3f9 in Fx_file_dialog ()

I see, I can reproduce it by clicking on the “open file” icon.

 I've found that setting the environment variable GSETTINGS_SCHEMA_DIR
 solves the problem.

 $ 
 GSETTINGS_SCHEMA_DIR=/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/share/glib-2.0/schemas
  emacs

 Can the schema location be fixed at configure/compile time?

We could use ‘wrap-program’ to set that variable for Emacs, but we need
to address that problem more generally.

This is actually a longstanding issue:
http://lists.gnu.org/archive/html/guix-devel/2013-10/msg00171.html
http://lists.gnu.org/archive/html/guix-devel/2013-10/msg00024.html
http://lists.gnu.org/archive/html/guix-devel/2013-11/msg00019.html

I would introduce a ‘glib-build-system’ that would have a post-install
phase to recompile the schemas visible to the package being built, and
wrap the binaries so GSETTINGS_SCHEMA_DIR refers to them.

I think that makes for a good project for this week-end’s hackathon.
Any volunteer?  :-)

Thanks,
Ludo’.