Derived Gtk::Dialog discomforts

[Dick Eimers-2]

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?


_______________________________________________
gnomemm-list mailing list
gnomemm-list@...
http://mail.gnome.org/mailman/listinfo/gnomemm-list

[Murray Cumming]

[snip]

> 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?

This works fine with Glade derived dialogs for me. If you put a simple
test case online then we can probably find the problem.

Murray Cumming
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnomemm-list mailing list
gnomemm-list@...
http://mail.gnome.org/mailman/listinfo/gnomemm-list

[Dick Eimers-2]

> [snip]
> > 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?
>
> This works fine with Glade derived dialogs for me. If you put a simple
> test case online then we can probably find the problem.

It works fine for me too, but only when I use to get_widget_derived
approach. Not when I use the reparent_widget approach implemented in the
GladeDialog class I was talking about in my previous post.

I'll paste the important parts of the GladeDialog, this may clarify how
I transfer properties and the widget-tree from dialogs to allow improved
encapsulation.

//.h
GladeDialog::GladeDialog(const std::string& gladexmlfile,
       const std::string& root)
{
   //obtain gui spec
   try
   {
      m_gladexml = Gnome::Glade::Xml::create (gladexmlfile, root);
   } catch(const Gnome::Glade::XmlError& e)
   {
      std::cout << "GladeDialog: " << e.what() << std::endl;
   }

   //adapt some properties and take over widgets
   Gtk::Dialog* dialog = 0L; m_gladexml->get_widget(root, dialog);

   //Widget ->
   {
      int width, height;
      dialog->get_size_request(width, height);
      this->set_size_request(width, height);  
   }

   //Container ->
   this->set_border_width(dialog->get_border_width());

   //Bin ->
   
   //Window ->
   this->set_title(dialog->get_title());
   this->set_type_hint(dialog->get_type_hint());
   this->set_modal(dialog->get_modal());
   {
      int width, height;
      dialog->get_default_size(width, height);
      this->set_default_size(width, height);  
   }
   this->set_resizable(dialog->get_resizable());
   this->set_gravity(dialog->get_gravity());

   //Dialog
   // ..
 
   this->remove(); //remove the one object contained in this 'Bin'
   m_gladexml->reparent_widget (dialog->get_child()->get_name(),
*this);  

   delete dialog;  
}

_______________________________________________
gnomemm-list mailing list
gnomemm-list@...
http://mail.gnome.org/mailman/listinfo/gnomemm-list

[Murray Cumming]

On Wed, 2006-01-25 at 11:07 +0100, Dick Eimers wrote:

> > [snip]
> > > 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?

Maybe you need to use Gtk::Dialog::add_action_widget() or
Gtk::Dialog::add_button() to make sure that the dialog knows about these
response widgets - you are just taking the parent container and adding
the widgets via that, without giving the dialog a chance to connect to
any signals for the buttons. See the implementation of
gtk_dialog_add_action_widget().

I guess you could add them one by one to the action area to make sure
that that code runs. I wouldn't do it for fun.

[snip]

>    //adapt some properties and take over widgets
>    Gtk::Dialog* dialog = 0L; m_gladexml->get_widget(root, dialog);
>
>    //Widget ->
>    {
>       int width, height;
>       dialog->get_size_request(width, height);
>       this->set_size_request(width, height);  
>    }
>
>    //Container ->
>    this->set_border_width(dialog->get_border_width());
>
>    //Bin ->
>    
>    //Window ->
>    this->set_title(dialog->get_title());
>    this->set_type_hint(dialog->get_type_hint());
>    this->set_modal(dialog->get_modal());
>    {
>       int width, height;
>       dialog->get_default_size(width, height);
>       this->set_default_size(width, height);  
>    }
>    this->set_resizable(dialog->get_resizable());
>    this->set_gravity(dialog->get_gravity());

This doesn't seem sensible. It's very repetitive and likely to miss
something. You could use the C API to iterate over all the properties, I
suppose. For an example, see:
http://cvs.gnome.org/viewcvs/glibmm/tools/extra_defs_gen/generate_extra_defs.cc?view=markup

By the way, I'd like to simplify the Glade::Xml API slightly, so that you don't need to provide
the widget name twice for the common case, to xml::create() and then also to Xml::get_widget(), but I can't do that
easily without adding a member variable, which would break ABI.

It shouldn't be impossible to just specify the XML file and widget name
details in the consructor's initializer if that's what you want to
achieve.

>    //Dialog
>    // ..
>  
>    this->remove(); //remove the one object contained in this 'Bin'
>    m_gladexml->reparent_widget (dialog->get_child()->get_name(),
> *this);  

--
Murray Cumming
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnomemm-list mailing list
gnomemm-list@...
http://mail.gnome.org/mailman/listinfo/gnomemm-list