On Sat, 2007-05-26 at 10:31 -0600, Jim George wrote:
> On 5/26/07, Felipe Balbi <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > my problem is the folowing...
> > I have a glade xml file being opened in my code...
> >
> > I wanna use the same pointer to this XML file in other functions...
> > how could I do it??
> > I have the implementation below, but my signals are not connecting.. why??
> > (maybe this IS a newbie question... but I'm not figuring this out...
> > the purpose here is to make it easier if I wanna port the application
> > to other Graphical Interface Toolkit such as Maemo/Hildon, QT or even
> > text...)
>
> Apparently there's no "standard" way of doing this, my approach is to
> have a structure of data associated with the main_window widget using
> g_object_set_data, then retrieve the structure wherever I need it,
> using g_object_get_data. One of the structure items is the glade XML
> object. You can also pass the structure (or just the glade XML ptr) as
> a parameter to your signal handlers. This seems to be a more common
> approach.
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.
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
