Hi michi7x7, Thanks for the information. I think I understand better now the "derived widget".
P. ----- Original Message ---- From: michi7x7 <[email protected]> To: [email protected] 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 [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
