> 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). _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
