Re: connecting to GtkBuilder signals
- From: Piscium <groknok yahoo ie>
- To: gtkmm-list gnome org
- Subject: Re: connecting to GtkBuilder signals
- Date: Mon, 3 May 2010 15:37:24 +0000 (GMT)
Hi michi7x7,
Thanks for the information. I think I understand better now the "derived widget".
P.
----- Original Message ----
From: michi7x7 <mailing-lists michi7x7 de>
To: gtkmm-list gnome org
Sent: Mon, 3 May, 2010 13:35:55
Subject: Re: connecting to GtkBuilder signals
Am 03.05.2010 13:58, schrieb Piscium:
> What I am looking for is something in-between the two approaches, that is, a way to have encapsulation to keep the code tidy while being simpler than the "derived widgets".
>
Either you use a derived widget or a built-in-Gtk-Widget, there is nothing between. But you don't have to derive every widget you use, a common approach is to derive every top-level-widget to store their members and leave buttons etc. as built-in Gtk::Button's.
> My approach seems to work well for the simple case of two buttons. Would it work well for more complicated widgets?
>
why not?
> If yes to the above, is my approach good C++ code or just an ugly hack? Or something in between?
>
I would derive the Top-Level window like so:
class Window
: public Gtk::Window
{
public:
Window(BaseObjectType* cobject, const Glib::RefPtr<Gtk::Builder>& builder);
private:
Gtk::Button *pButton1, *pButton2;
}
Window::Window(BaseObjectType* cobject, const Glib::RefPtr<Gtk::Builder>& builder)
: Gtk::Dialog(cobject)
{
builder->get_widget("button1", pButton1);
builder->get_widget("button2", pButton2);
}
That is the common approach. Button's are usually not derived (except they contain user-defined widgets (blinking text))
_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]