Here I collect my thoughts concerning libglade (I was tempted to optionally 
base glade-- programs on libglade).

- Libglade offers you no constructor for your classes
- Libglade's signal connection scheme is designed for C not for C++
- In a signal callback you can't pass your data (e.g. class methods don't
	work)
- How to access widgets in your C++ program?

This can be circumvented the following way:
- Create user classes all at once in a big 'array' and pass the appropriate
  this to user callbacks (sigh)
- Contain user classes inside (empty) glade classes which's constructor
  calls xml = glade_xml_new("some-interface-file", "menubar");
        glade_xml_signal_autoconnect(xml);
  etc.
- generate macros for glade_xml_get_widget(xml, "menubar");
  hmmm, we can't construct gtkmm classes on the fly, their lifetime
  is too short to do any real work, so construct them dynamically in the
  constructor and have them as members (this will work)
- perhaps a custom glade_xml_signal_autoconnect should do it, since we need
  the methods(C or C++ linkage) and 'this'. How to get this?
  perhaps we should connect the signals ourself (glade_xml_get_widget,
  Gtkmm ctor, connect_to_method)
  
  we could use the monstrous GladeXMLConnectFunc() and some wrapper magic
  done inside gtk-- (how does gtkmm deliver C signals to C++?)
  
  use glade_xml_signal_connect_full() ! it delivers user data!

- we might use glade_widget_tree_parse_memory() to drop dependancy on an
  external file