Re: Global GladeXML

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).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]