Re: Global GladeXML
- From: "Jim George" <jimgeorge gmail com>
- To: "Tristan Van Berkom" <tvb gnome org>
- Cc: gtk-app-devel-list gnome org, glade-users lists ximian com
- Subject: Re: Global GladeXML
- Date: Sat, 26 May 2007 18:45:19 -0600
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
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).
] [Thread Prev