Re: [[gtkmm] Libglademm autoconnecting callbacks]

[Christof Petig <christof petig-baender de>]

Murray Cumming schrieb:
> > If not, a new entry in a map<string,signal_handler> is created, with
> > a proxy function that can be called by Gtk+ C code and calls back
> > to a sigc++ slot.
> >
> > The idea is that the user have to fill this map, connecting each
> > of the signals stored in it to the correct handler, at runtime,
>
>
> Oh well. thanks a lot for investigating. I guess that the libglademm 1 code is
> not the answer.

Well, this is what I had in mind before (which is much like the glademm 
behaviour I realized), but didn't find time to implement:

For each window which is constructed look for a same named class. Then 
look for a decent ctor (perhaps with a Glib::RefPtr<Gnome::Glade::Xml> 
and a gpointer argument). Call it and associate the object (and it's 
lifetime) with the widget structure (AFAIK this is better done in a C 
style (you can't create objects of types no earlier known than at 
runtime in C++)).

Then you can call member methods of this class corresponding to the name 
entered in glade.

----

This is a radical breakage of the C like nature of libglade and an OO 
approach which has worked well in most glademm programs. IMNSHO it's a 
proven (I wrote several huge FLOSS programs using this scheme) good way.

   Christof

PS: You can even extend that to user defined (widget like) types: Look 
for a ctor of a  class of this name.
PPS: glademm has a mechanism to cut the widget hierarchy into defined 
pieces to maintain a lower number of per-class callbacks.