Derived Gtk::Dialog discomforts



I am working on a collection of classes to make creating GUI easier for
our junior programmers. The idea is that they 'paint' a GUI using Glade
and then write a single class to define the behavior of the Window or
Dialog, e.g. MyDialog or MyWindow. 

So I read in the tutorial that the correct way to do this by adding a
special constructor to MyDialog: 

MyDialog::MyDialog(BaseObjectType* cobject, const
Glib::RefPtr<Gnome::Glade::Xml>& refGlade)
: Gtk::Dialog(cobject)
{
//do stuff
}

and instantiate an object of MyDialog using a construct like:

MyDialog* dialog;
refXml->get_widget_derived("mydialogname", dialog);

, where spiffy function template instantiation magic is used to call the
special ctor.

However, the disadvantage is that when creating an object of MyDialog
the 'client' (or creator or whatever) needs to know about the location
and name of the .glade-file as well as the name of the dialog widget.
I'd like to encapsulated such detailed information in the derived class'
implementation (e.g. MyDialog.cpp).  

I understand the get_widget_derived template function is a generic
solution and that it can be applied to any widget-type that may occur
now and in the future, but back to my 'making it easier for junior
programmers'-thingie. I'd like to optimize for the common case and at
least for now they can do with just creating derived Gtk::Window and
Gtk::Dialog classes. 

Therefore, I've created two convenience classes that derive from
Gtk::Window and Gtk::Dialog, called GladeWindow and GladeDialog, that
they should use to create subclasses from. (Thus not directly from
Gtk::Window or Gtk::Dialog.) These classes have a single constructor
that accepts the glade-file plus widget-name and creates an Gtk::Window
or Gtk::Dialog instance internally (NOTE: if we take a dialog for
example, this occurs in the constructor and hence we have a dialog
instance being in construction and another one created from
the .glade-file in GladeDialog's ctor) then the widgets are transferred
from the internally created widgets onto the 'current' instance. This is
implemented using reparent_widget and just setting various properties
from the internally created to the 'current', such as title,
border-width etc.

Now for my problem, this works just fine for windows derived from
GladeWindow, but there is an issue with GladeDialog as the response id
are not returned when clicked on the buttons in the 'action area' and
hence I have to add code like the following in every GladeDialog
derivative to fix it or wait for run() to return forever..

Gtk::Button* button;
m_gladexml->get_widget("cancelbutton1", button);
   button->signal_clicked().connect(
sigc::bind(sigc::mem_fun(*this,&SelectGroupAndProjectDialog::response),
Gtk::RESPONSE_CANCEL)
      );   
//etc. for all buttons.. 

Any idea why this is not transfered from one dialog to another?





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