RE: [gtkmm] design question using libglademm

On Fri, 2003-10-31 at 02:41, Murray Cumming Comneon com wrote:
> Yes, that's why I added the derived_widget stuff in libglademm 2.1/2.2.

Ok, so I had a look at the derived example in the latest libglademm and
must admit that I'm missing how it solves matters from a design
standpoint given that one must instantiate the Glade::Xml outside of the

First off, I'm assuming that the proper way to use libglademm is to
instantiate the Glade::Xml objects on-demand, i.e., when a compound
object is needed, a new Glade::Xml is created, rooted at the desired
widget, and then it is re-parented or otherwise used as necessary. If
one is intended to create only one application wide Glade::Xml instance
please correct me now (although my understanding is that get_widget()
returns a pointer to the instantiated widget in the Glade::Xml and not a
pointer to a newly instantiated widget based on the template in

If my understanding is correct, then what I would like to do is
something like:

Gtk::Notebook *notebook = new CustomNotebook();

where CustomNotebook is defined as:

class CustomNotebook : public Gtk::Notebook {
  Glib::RefPtr<Gnome::Glade::Xml> glade_ref;
  void on_foo();
  virtual ~CustomNotebook();


  try {
    glade_ref = Gnome::Glade::Xml::create(GLADE_FILE,
    Gtk::VBox *tab_1;
    // deal with re-parenting somehow
    pages.push_back(TabElem(tab_1,"Tab 1");

This way the glade usage is encapsulated in the class, and outside users
needn't know whether the widgets have been coded, or are being loaded
using libglademm. The problem with the above approach is that it would
be nice to somehow use the whole notebook widget directly without having
to add pages one at a time.

Maybe a combination of a proxy class and get_widget_derived will do what
I'm really looking for? Any ideas?



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