Re: GnomeModule, libglade

[James Henstridge <james daa com au>]

jacob berkman wrote:

> this has been talked about in the past, but i would like to bring it up
> one more time and try to get it to happen before gnome 2.0.
>
> so currently, libglade can support bonobo, gnome, etc. through extra
> modules.  these libraries could instead directly provide libglade
> support themselves.
This sounds like a good idea.  I have been trying to reduce the amount 
of widget specific code in libglade, which has made it a fair bit 
cleaner (and far fewer infrequently followed code paths).

There are a few changes I want to make to the libglade core that will 
allow it to use the generic handlers for widgets it hasn't ever heard 
of, but have been registered (ie. there get_type() function has been 
called, which is pretty inexpensive).

This will probably result in a few small changes to the way handlers are 
registered with libglade.  Hopefully this will minimise the amount of 
work needed to maintain the libglade support in your modules.

> advantages:
>
>    libraries add libglade support / fixes directly, and can use private
>    functions / struct fields if necessary
>    
>    no possibly-broken dependencies if libglade wasn't built with say
>    bonobo support but an app needs it.  if the app needs bonobo with
>    libglade, it comes with bonobo.
>    
>    less dlopens / libs to load - libglade doesn't have to load the
>    different modules as they are already loaded when the main lib is.
>    
>    if libgnomeui depends on libglade, it can use gtk glade files itself
>    (as an example)
If people are happy to depend on libglade, then this sounds like a good 
idea.  It should reduce startup time for apps that open a libglade 
window on startup (for apps that only use libglade for dialogs, this 
dlopen hit is deferred til the dialog box is opened).

>    
> disadvantages:
>
>    libraries probably have to add their stuff to libglade when they are
>    initialized
>    
>    libglade having a stable api becomes very important to the platform
>    
> so these libraries need to tell libglade which widgets they support,
> which can happen in the GnomeModule stuff i guess - except that like
> libgnomeui provides the GnomeModule for the canvas!  which seems totally
> broken.  
>
> the fact that things like gnome-vfs's version are hard coded in
> libgnomeui rather than coming from gnome-vfs is ludicrous at best.  it's
> too late to change this stuff for 2.0, but does anyone really feel
> confident in it?  or does it not really matter?
>
> so anyway - does anyone have objections to putting the libglade support
> for things in the module where they come from (because i will actually
> do the work this time)?
It might make sense to get rid of the init function for libglade all 
together, and only initialise when needed.  Libglade doesn't need to do 
any argument parsing, and there are only a few entry points which rely 
on the initialisation having occured.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/