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.