>> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to keep a proper logical separation between Gtkmm UI objects and the functionality they trigger or state they manifest. The bulk of code ends up in plain C++ classes, while the Gtkmm widgets merely provide a thin layer to expose>> in the 'proper' manner. That might including moving certain functionality out of the widget classes themselves.I see your point. Could you please name some inkscape UI classes that preserve the separation?
I would like to go on with SPColorSelector refactoring. In Inkscape color can be selected using one of two widgets: sp-color-wheel-selector, sp-color-icc-selector. They share common functionality in sp-color-selector. Currently there are six structures consisting of both Gobjects and c++ classes.I made a simplified diagram, listing possible options for refactoring [1].1) ColorSelector widgets contain a reference to their state (ColorSelector). It is accessible via getColorSelector() method. Optional ColorSelectorWidget abstract class provides the method. Parent UI component would initialize color selector widgets in ctor. Reference to widget would be kept in ctor only. Parent class would contain a pointer to widget state, returned by getColorSelector().2) Double inheritance. ColorSelector provides widget state. Concrete implementations inherit ColorSelector and aproppriate Gtk::Widget.3) Full wrapper. Color selector widgets contain reference to their state and have full set of thin wrapper methods. They only call corresponding methods in ColorSelector.Which is the best? What is the suggested naming and namespacing of mentioned classes?Which of the options fits the separation between gtkmm and functionality best?On Wed, May 21, 2014 at 8:21 PM, Jon A. Cruz <jon@...18...> wrote:
On Wed, May 21, 2014, at 10:31 AM, Tomasz Boczkowski wrote:Thank you for the answer.>>Also, take care on what widgets you are looking at. We have a few groupings in our source tree that are meant to stay C.I started with src/widgets/sp-color-slider. I plan to continue with widgets related to fill and stroke dialog (sp-color-notebook, sp-color-scales, sp-color-wheel-selector etc.). Are they safe to port?Those should be OK... but in the 'proper' manner. That might including moving certain functionality out of the widget classes themselves. *Additionally* those I recognize as some of the first files I poked at when I initially joined Inkscape (before the project had its name). They're probably quite outdated by this point.
Then also keep in mind that "sp" stands for Sodipodi, so when you move files you can drop such. Just be sure to do it in a source-control friendly way that won't break history. :-)>>>> 4) Should child widgets be stored as pointers as in glyph.h or directly as in text-edit.h?>> Which file are you referencing as "glyph.h"?src/ui/dialog/glyphs.hAhh, that's an interesting question.For widgets, the design and intent of Gtkmm is to place children via new + Gtk::manage(). That ensures consistent object lifetimes and helps reduce memory leaks. For even stronger encapsulation often it's better to not list pointers as members in the public .h file, but keep them all to setup in the constructor. Since you won't have to delete them, you don't have to track them... for those cases where you set up events and handlers then add the child. That also goes on to event driven programming, and fewer bugs once you wrap your head around it.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel