Hi, some more thoughts: Aren't widgets usually stored in Glib::RefPtrs? You can't use them because the compiler needs the full definition of the classes you use as template type parameters, doesn't it? How does this affect speed and memory usage?

Regards, Markus

-----Ursprüngliche Nachricht----- Von: Markus Engel [mailto:p637777@...1081...] Gesendet: Montag, 31. März 2014 17:09 An: 'Alex Valavanis'; 'Inkscape Devel List' Betreff: Re: [Inkscape-devel] Private implementations of widgets

Hi, if you used references or pointers, where would you get the actual widgets from? "newing" them? Then please make sure that every single widget is correctly deleted no matter what happens. You probably don't want to do that. How often are these files or the files referencing them changed? Are you sure that this will have an impact on the compilation times? Do some measurement and prove it :) .

Don't get me wrong please. Just some of my first thoughts ;) . Regards, Markus

-----Ursprüngliche Nachricht----- Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Montag, 31. März 2014 15:45 An: Inkscape Devel List Betreff: [Inkscape-devel] Private implementations of widgets

Hello All,

Just wondering if we ever came up with a coding style for the private components of our widgets and dialogs. Our GUI components, for example, the dialog in [1] contain many different Gtk widgets (rather than pointers/refs to widgets) and so we need to include lots of <gtkmm/*.h> headers in our GUI class definitions.

If the embedded widgets were replaced by references to objects, we could just use forward declarations of the appropriate classes and then pull the header inclusions into the relevant .cpp files so it should improve our compilation times.

Is there a reason why we don't do more of this already?

AV

[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/ui/d ialog/grid-arrange-tab.h

---------------------------------------------------------------------------- -- _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---------------------------------------------------------------------------- -- _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---- Markus Engel <p637777@...1081...> wrote:

Hi, if you used references or pointers, where would you get the actual widgets from? "newing" them? Then please make sure that every single widget is correctly deleted no matter what happens. You probably don't want to do that. How often are these files or the files referencing them changed? Are you sure that this will have an impact on the compilation times? Do some measurement and prove it :) .

I agree with Markus. It doesn't make sense to complicate code and the chances of bugs, only to reduce compilation times (is it really that significant?). Note that the dialog's cpp files would still have to include the headers :-) I you move the gtkmm/*-includes from .h to .cpp, by how much does it reduce the number of compiled files (.cpp) that include those gtkmm/*-includes?

cheers, Johan

Don't get me wrong please. Just some of my first thoughts ;) . Regards, Markus

-----Ursprüngliche Nachricht----- Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Montag, 31. März 2014 15:45 An: Inkscape Devel List Betreff: [Inkscape-devel] Private implementations of widgets

Hello All,

Just wondering if we ever came up with a coding style for the private components of our widgets and dialogs. Our GUI components, for example, the dialog in [1] contain many different Gtk widgets (rather than pointers/refs to widgets) and so we need to include lots of <gtkmm/*.h> headers in our GUI class definitions.

If the embedded widgets were replaced by references to objects, we could just use forward declarations of the appropriate classes and then pull the header inclusions into the relevant .cpp files so it should improve our compilation times.

Is there a reason why we don't do more of this already?

AV

[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/ui/d ialog/grid-arrange-tab.h

On Mar 31, 2014, at 10:30 AM, Krzysztof Kosiński wrote:

2014-03-31 17:08 GMT+02:00 Markus Engel <p637777@...1081...>:

...

Hi, if you used references or pointers, where would you get the actual widgets from? "newing" them? Then please make sure that every single widget is correctly deleted no matter what happens. You probably don't want to do that.

With Gtk::manage() this task is actually rather simple - the widget is deleted automatically when its container is deleted. You just need to make sure you don't create any orphan widgets which are not actually added to any container.

That being said, I'm not sure if there is a compelling reason to change from one approach to the other.

Krzysztof is right in regards to Gtk::manage() and also the bigger issue about usefulness.

Another danger with using Gtk::manage() only, however, is if your code holds pointers to the objects. If their parents go out of lifecycle the would be deleted and code left with invalid dangling pointers. Writing the code to avoid such problems is something to keep in mind. As long as that is addressed, it does end up much better than the alternative Markus pointed out about having to manually delete everything.

Now moving #includes into the .cpp to avoid excessive Gtkmm includes is not going to be too useful for us (since those hardly ever change, etc.). However... for code *consuming* our header it can be a big gain. By moving members to be parts of a private struct/class that is not directly in the .h, the internal implementation details are not exposed. Leaving only the public API in the header first of all will make the class easier to use, easier to maintain, and in general increases the encapsulation which is a good software engineering principal.

Also, this means that whenever the details of a given dialog are changed (members added, types tweaked, etc.) they only affect a single .cpp instead of dozens of other files that directly or indirectly have included the initial header. During a developer's normal workday this savings makes working in areas go much faster, and shorter incremental builds pay off in developer productivity.

Of course, how to specifically implement this problem needs some annotated examples so that we can clearly see the different trade-offs. Since most guides on good C++ engineering recommend this encapsulation we should take a look at it.