Re: libglade replacement for gtk+ 2.8 [SNEAK PREVIEW]

[Tristan Van Berkom <tristan van berkom gmail com>]

On Mon, 28 Feb 2005 15:57:40 -0300, Johan Dahlin <johan gnome org> wrote:
> Hi gtk-devel list
> 
> In preparation for the meeting tonight I'd like to present this document
> describing integration of libglade in gtk+.

Hmmm, 
    I would have liked to attend this meeting too but probably won't be able to
make it (at what time/channel ?). I've been wondering for a while what the 
outcome would be for "libglade in gtk+" and am looking forward to get this
clear ;-)

> * Custom properties
> 
> Most widgets exposes all important states through GObject properties,
> however in some cases the state is not properly exported. Libglade
> handles this by having custom properties; one example is the
> set_format_string accessor for GtkProgress. Currently there are 36
> custom properties handled in libglade. Ideally all of these "fixes"
> should be moved into the widgets themselves so libglade doesn't need to
> patch them to work in a compatible way.

    Please note that custom properties aren't only usefull for objects that were
written without introspection in mind, but are usefull for the builder to store
information pertaining to the builder's environment but essentialy useless
to the application when using the gladefile (like <placeholder> tags, these
properties are simply ignored).

> * GObject support
> 
> The most important thing libglade lacks today is support for GObjects.
> Without this GUI Builders like gazpacho cannot support GtkUIManager and
> GtkTreeModel properly. To be able to build a modern graphical
> builder/designer this is of highest priority.
> 
> James has written a proposal on how to handle arbitrary GObjects, he'll
> not be able to attend the meeting today
> (due to timezone differences) but the document can be found here:
> http://live.gnome.org/LibgladeWithGobjects

As a side note, 
    I've updated http://bugzilla.gnome.org/show_bug.cgi?id=161903
today with a cleaner version of this patch. 

glade-3 atm has support for non-widget GObjects (although it currently
does not integrate any gtk+ non-widget objects).

An essential thing I've had to think about to acomplish this is container
relationships, One can not implement non-widget objects without considering 
that a GtkWidget can be the parent of a GObject which in turn can be the parent
of another GtkWidget, luckily using the afore mentioned
"build_children" callback
through libglade, the client loading code wasn't too hard to write; although 
it was 100% special case code for every integrated non-widget 
(note that it wasn't so easy in the builder, I had to abstract the GtkContainer
interface and add entry points for packing properties, etc).

One possible way to deal with this (and I'm sure I'm not the first one to dare
ponder this idea) would be a GContainerIface, possibly to be extended
by the traditional GtkContainerClass *cough* pretty extreme *cough*.

Cheers,
                                                        -Tristan