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.h

Ahh, 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.

Jon A. Cruz

jon@...18...