Re: Global GladeXML

["Jim George" <jimgeorge gmail com>]

> Note that this is definitely not a recommended practice, GladeXML
> objects should be dispensed with as soon as possible after interface
> construction, its a heap of allocated strings that represents the
> parsed state of the glade file; not only a practical hash table by
> widget name thing.
>
> See the DevHelp sources for a good example of libglade usage.
>
>   - Each interface component has a GObject control object as
>     an api to that component
>   - Each component holds pointers to only the needed widgets
>     from the interface.
>   - Each component parses a glade file (or portion of the glade
>     file) at initialization and passes the control object itself
>     to signal callbacks as data.
>
> Note many progams use this paradigm but not all of them go so
> far as to use a GObject as the control data for a UI component -
> and many apps use a global data structure for the whole UI
> as well.
>
> My main pointer for libglade usage is just free up that bloated
> GladeXML memory hog as soon as possible at initialization time, its
> just not meant to be kept around.

Thanks, Tristan. I didn't realize the xml object consumes a lot of
memory. Devhelp handles the extraction of pointers from the xml in a
very elegant manner. However, confusingly enough, they decide to use
both a global pointer to the control object *and* to pass it to the
signal handlers as a parameter (see dh-preferences.c).