Would you be willing to work on a patch for this ?

Sure, will take a look at this if you think this is a good solution for the problem. 

I always thought the libglade method method to include
widget types was a little clunky, if only because it makes
it difficult for people who are not interested in distributing
a widget kit and building a separate module.

In the hope this is not too quickly spoken, I think a good
and easy solution for this would be to just expose a "requires"
signal (possibly a boolean return with a major/minor version
argument and a signal detail describing the required catalog).

This would allow a few use cases with little effort I think:
   - When linking against libxfce4ui-1, you just connect
     to "requires::libxfce4ui-1" and return TRUE or FALSE
     depending on the version.
   - If libxfce4ui-1 is for any reason a dynamic module
     (like in libglade days), then you can do the above
     but just load the module in the signal callback and
     return FALSE if it fails.
   - If the user has custom widgets in his application, he
     will be using a custom catalog and the "requires" field
     will reflect that (I think thats correct since that file
     will will be unsafe to load for any other application),
     in which case the user should connect to the signal and 
     just return TRUE for his own catalog.

Thoughts ?

For custom widgets: if g_type_from_name() failes if looks for the *_get_type function in GModule g_module_open (NULL, 0), the glib manual says this is "a GModule representing the main program itself", so that would mean this only failes if the specific library (containing the widget) is not linked? Right?

The signal is not very convient, since you have to implement it for each gtkbuilder or write an object on top of gtkbuilder that implements it (not cool).

(In reply to comment #4)
> For custom widgets: if g_type_from_name() failes if looks for the *_get_type
> function in GModule g_module_open (NULL, 0), the glib manual says this is "a
> GModule representing the main program itself", so that would mean this only
> failes if the specific library (containing the widget) is not linked? Right?
> 
> The signal is not very convient, since you have to implement it for each
> gtkbuilder or write an object on top of gtkbuilder that implements it (not
> cool).
> 

Right, when the library has been linked, there is no need to
load a module, assuming you've loaded your modules into memory
GtkBuilder will "just work", which is a step up from libglade
which required that you write initialization stubs for your
library and register your widgets by hand.

The "requires" tag is primarily an assertion that the widget 
catalogs described in the GtkBuilder xml file are indeed available 
at runtime - and that they are versioned correctly.

So it will intentionally fail with an error message if for instance
your glade file uses a widget or property in libxfce4ui-1 from a 
version not yet installed on your system.

On the Glade side of things, this also ensures that if you use 
custom widgets in your app, and you sent the Glade
file to someone else, they will immediately know that they
also need your catalog and your widget code to operate with
that Glade file (which also should transparently work with
widget libraries that install catalogs to integrate with the 
Glade palette).

(In reply to comment #0)
> It looks like the "requires" xml is parsed and stored in the parser code, but
> not used. So if (in our Xfce case) the following line is in the glade file:

Ahhh sorry I did not read this part.

Yes, its there, I put it there intentionally and its used, but we
still never extended it to check other catalogs than the base "gtk+"
catalog.

If you are porting from libglade to GtkBuilder, I would suggest
that if you can - just link against the widget library you need
directly, and until this bug is fixed the version just wont
be checked.

On the other hand... there is probably some value to implicitly
pulling in a library completely via GtkBuilder and a dependancy
in the Glade file - the <requires> tag could be extended to
add a property describing the actual library to look up in
the linker path, since now it only takes a toolkit identifier string.

But that still leaves one problem: how do you check
the version of toolkit 'x' (if only all libraries implemented
a common interface ?) ?

Maybe an optional module entry point ? 
  gboolean gtkbuilder_init_module (gint major, gint minor); 

Is all that really worth the trouble just to load ui toolkit 
libraries on demand ? I mean, if you distributed the Glade file
and your app uses it, you depend on that toolkit anyway, you
cannot fallback, so why spend more time loading the toolkit
with the runtime linker ?

All true, I worked around the problem by making sure the library is linked so for now to problem is solved for us. I just could imaging people expect this to happen automagically. The module entry point is an idea, because you most likely also added support for glade-3 for the library.

Currently you dont need to make any special entry point for
a module that provides widgets for GtkBuilder, its just types.

Only libglade required that, if we go and add such possible
entry point for a loadable library, it would be something completely
new, but I wouldnt object, on the other hand we still also need a way
for the user to tell GtkBuilder about widgets in their project
that come from their own custom catalog, which could be done
with a gtk_builder_provide_catalog (builder, "catalog-name", major, minor)
api instead of a signal (even a "silent" attribute could be added to
cause builder to "assume" the dependancy all together, and you could
go and control that in Glade... all possible options).

On the other hand exposing a signal simplifies the whole implementation
for us, at the cost of strictly educating the GTK+ user about what
catalogs are involved in his load process.

The option out of these options I prefer personally is 
 "I would really just like it to be done"
I guess I dont really mind how... if it really gets done ;-)

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new