A question for C++/gtkmm gurus:
Why do we have to have ALL widgets of a dialog declared in an .h file? They aren't usable outside the dialog anyway.
In general, while I appreciate many advantages of C++, the way it is used with gtkmm for Inkscape's dialogs is a major annoyance. A lot more typing in a lot more places than when using simple gtk where you can declare, create, and show a widget in a single spot in code. Is there some grand vision behind this that I'm missing?
2010/6/11 bulia byak <buliabyak@...400...>:
A question for C++/gtkmm gurus:
Why do we have to have ALL widgets of a dialog declared in an .h file? They aren't usable outside the dialog anyway.
In general, while I appreciate many advantages of C++, the way it is used with gtkmm for Inkscape's dialogs is a major annoyance. A lot more typing in a lot more places than when using simple gtk where you can declare, create, and show a widget in a single spot in code. Is there some grand vision behind this that I'm missing?
It's actually not necessary to declare them in the .h file. Just create them with "Gtk::manage(new Gtk::SomeWidget(...))" and add to a container. Using this method, only the toplevel widget needs to be declared.
I guess someone didn't know how Gtk::manage works and assumed that every widget has to be a member of the dialog's class, so it is destroyed when the the dialog is closed.
Regards, Krzysztof
And in case you mean derived widgets (e.g. derived from Gtk::Dialog), even those (as classes) don't _need_ to be declared in the .h file, but it's generally better style to do it. However, if you want to get rid of this I don't think anyone anywhere will blame you, they would just have to be moved into the .cc file and merged with their definition.
2010/6/11 Krzysztof Kosiński <tweenk.pl@...400...>
2010/6/11 bulia byak <buliabyak@...400...>:
A question for C++/gtkmm gurus:
Why do we have to have ALL widgets of a dialog declared in an .h file? They aren't usable outside the dialog anyway.
In general, while I appreciate many advantages of C++, the way it is used with gtkmm for Inkscape's dialogs is a major annoyance. A lot more typing in a lot more places than when using simple gtk where you can declare, create, and show a widget in a single spot in code. Is there some grand vision behind this that I'm missing?
It's actually not necessary to declare them in the .h file. Just create them with "Gtk::manage(new Gtk::SomeWidget(...))" and add to a container. Using this method, only the toplevel widget needs to be declared.
I guess someone didn't know how Gtk::manage works and assumed that every widget has to be a member of the dialog's class, so it is destroyed when the the dialog is closed.
Regards, Krzysztof
ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jun 11, 2010, at 3:40 PM, Milosz Derezynski wrote:
And in case you mean derived widgets (e.g. derived from Gtk::Dialog), even those (as classes) don't _need_ to be declared in the .h file, but it's generally better style to do it. However, if you want to get rid of this I don't think anyone anywhere will blame you, they would just have to be moved into the .cc file and merged with their definition.
Well, it can be done but then it really needs to be done with care.
That is, some things (such as packing widgets) can be best left to Gtk::manage() in the base class ctor, but many others (such as checkboxes, edit areas, etc) are best left as members in at least some class.
I've been doing various cleanups of this sort for some time now, and it's not quite as simple as some might think. But I agree that it's good to keep the .h files to only what they really need to have, and hide everything else in the .cpp files.
On Jun 11, 2010, at 2:37 PM, Krzysztof Kosiński wrote:
I guess someone didn't know how Gtk::manage works and assumed that every widget has to be a member of the dialog's class, so it is destroyed when the the dialog is closed.
That's not the main reason.
One of the reasons that was at least meaningful early on is to allow access to widgets after construction.
Sometimes you can set everything up cleanly in event handlers, but I've see it more common to come up with needing to access at least some widgets in other handlers, etc.
W dniu 12 czerwca 2010 08:39 użytkownik Jon Cruz <jon@...18...> napisał:
That's not the main reason.
One of the reasons that was at least meaningful early on is to allow access to widgets after construction.
Sometimes you can set everything up cleanly in event handlers, but I've see it more common to come up with needing to access at least some widgets in other handlers, etc.
When using Gtk::manage for all widgets in a dialog, the widgets that need to be accessed after creation can be added to the .h file as pointers to partially specified types; this provides consistency without requiring header bloat, e.g.
class SomeWidget; class SomeDialog { ... private: SomeWidget *_widget_that_needs_to_be_accessed_after_creation; };
However, I see no point in specifying *all* widgets as members of the dialog. The advantages are unclear and at the same time it makes dialog coding very tedious.
Regards, Krzysztof
On Jun 13, 2010, at 3:00 PM, Krzysztof Kosiński wrote:
When using Gtk::manage for all widgets in a dialog, the widgets that need to be accessed after creation can be added to the .h file as pointers to partially specified types; this provides consistency without requiring header bloat, e.g.
class SomeWidget; class SomeDialog { ... private: SomeWidget *_widget_that_needs_to_be_accessed_after_creation; };
However, I see no point in specifying *all* widgets as members of the dialog. The advantages are unclear and at the same time it makes dialog coding very tedious.
Yes, there generally is not a need to specify all widgets as members. I did state that in my mail.
However, there are some additional risks associated with using a pointer as opposed to just a stock gtkmm member. Among those are a risk for dangling pointers and destruction sequence errors. Gtkmm handles that more robustly with non-pointer.
A bigger gain than just using raw pointers is to follow one of the standard encapsulating patterns and not expose *any* members in the public .h file. For simplicity, non-pointer members give better management and safety. Generally one of those two overall considerations should be the driving ones.
On Jun 11, 2010, at 9:22 AM, bulia byak wrote:
A question for C++/gtkmm gurus:
Why do we have to have ALL widgets of a dialog declared in an .h file? They aren't usable outside the dialog anyway.
In general, while I appreciate many advantages of C++, the way it is used with gtkmm for Inkscape's dialogs is a major annoyance. A lot more typing in a lot more places than when using simple gtk where you can declare, create, and show a widget in a single spot in code. Is there some grand vision behind this that I'm missing?
This isn't really a factor with C++ or gtkmm. It's just more of a default architectural case.
If you want, you can just do the same "create and shove" approach via Gtk::manage(), but there are many cases where it helps to have access to members.
In the older GTK code we have, putting random pointers as data items on an object was one way to regain access. However, members make that much easier to manage. Among other factors, keeping things as member variables allows methods of the owning class easy access while blocking access by others. That's generally a good thing as far as enhancing modularity and encapsulation.
As to shoving things in the .h file, there are a few common C++ approaches to deal with this.
One approach is easy to use when construction of an object (dialog, panel, etc.) is encapsulated behind some helper function, as when a factory pattern is employed. You can declare a public base class that has all the access and functions you want people to use on it, but that has no members. Then when you create one in the creation method of the factory (or whichever), you can create a *subclass* with all the details hidden away and pass that on. So the base Foo class is declared in the .h and defined in the .cpp, while the FooImpl subclass is defined and declared only in the .cpp, thus hidden away from all prying eyes.
Another approach is to have some implementation object that is private (only inside the .cpp for the main class) and is present in the .h file only as a member that has a pointer to the FooImpl class. The FooImpl doesn't inherit from the base Foo class, but gets assigned in the Foo class constructor and then cleaned up nicely in the Foo class destructor.
I often use both of those approaches, and gtk itself heavily leans towards the second approach. It all depends on the exact use case as to which is the most suited to a given area. There are many factors that contribute to this.
participants (4)
-
bulia byak -
Jon Cruz -
Krzysztof Kosiński -
Milosz Derezynski