Hi!
I started porting inkscape widgets to gtkmm and c++ and have a few questions:
1) There are two directories src/widgets and src/ui/widget. Is the former deprecated? 2) Should I move classes to src/ui/widget after c++-sification? 3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0?
Regards, Tomek
Just one more:
4) Should child widgets be stored as pointers as in glyph.h or directly as in text-edit.h?
Tomek
On Wed, May 21, 2014 at 6:39 PM, Tomasz Boczkowski <penginsbacon@...400...>wrote:
Hi!
I started porting inkscape widgets to gtkmm and c++ and have a few questions:
- There are two directories src/widgets and src/ui/widget. Is the former
deprecated? 2) Should I move classes to src/ui/widget after c++-sification? 3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0?
Regards, Tomek
On Wed, May 21, 2014, at 09:57 AM, Tomasz Boczkowski wrote:
Just one more:
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"?
-- Jon A. Cruz jon@...18...
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?
- 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
Tomek
On Wed, May 21, 2014 at 7:16 PM, Jon A. Cruz <jon@...18...> wrote:
On Wed, May 21, 2014, at 09:57 AM, Tomasz Boczkowski wrote:
Just one more:
- 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"?
-- Jon A. Cruz jon@...18...
"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
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. :-)
- 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...
2014-05-21 18:57 GMT+02:00 Tomasz Boczkowski <penginsbacon@...400...>:
Just one more:
- Should child widgets be stored as pointers as in glyph.h or directly as
in text-edit.h?
Storing child widgets directly (as members) is preferred, because it's harder to make mistakes resulting in memory leaks. However, this is up to you.
If you store widgets as pointers, you need to call Gtk::manage() on them upon creation and before adding them to the containing widget, so that they'll be destroyed correctly.
Be sure to follow the coding style, especially when it comes to variable and function naming: http://www.inkscape.org/en/develop/coding-style/
Regards, Krzysztof
On Wed, May 21, 2014, at 09:39 AM, Tomasz Boczkowski wrote:
Hi!
I started porting inkscape widgets to gtkmm and c++ and have a few questions:
1) There are two directories src/widgets and src/ui/widget. Is the former deprecated? 2) Should I move classes to src/ui/widget after c++-sification? 3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0?
First is that the different folders came from early refactoring efforts that were originally focused on doing an all-at-once conversion to C++. We probably just want to do things carefully in regards to change history, tracking, etc. but I believe the latter folder is now the preferred destination.
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 (due to being libraries copied in-tree, code meant for reuse with other projects, etc.). For those the preferred approach would be to keep core functionality in C-compatible files and provide C++ wrappers with Gtkmm. (this is also how Gtkmm itself is written)
*HOWEVER* do be careful about low-level and/or wrapping issues with Gtkmm. If the behavior is added only at the C++/Gtkmm level, some widgets misbehave when interacting with Gtk. The 'native' Gtk object held by Gtkmm class instances may sometimes be passed to C API's of Gtk or other classes. This is especially common with some of the data APIs such as trees, UI lists, etc. In those cases C++ methods don't get invoked, object slicing might occur, etc.
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 them. Conceptually this is easy to visualize for the case where Inkscape is invoked from the command-line on a system that doesn't even have a display. In that case all functionality will work (via command-line params, scripting, DBUS, etc) even though no widgets should even get instantiated.
-- Jon A. Cruz jon@...18...
On Wed, May 21, 2014, at 09:39 AM, Tomasz Boczkowski wrote:
3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0?
WITH_GTKMM_3_0 is an autoconf variable that is set up during configuration of a build and signifies a user's desire to use (or not) the newer version of Gtk. It can be checked in code that includes config.h.
GTK_CHECK_VERSION(3,0,0) is the macro provided by Gtk itself, and is not tied directly to a build/configuration system. For most cases for "Gtk 2.x code vs Gtk 3.x code" this would be the preferred macro to use.
-- Jon A. Cruz jon@...18...
2014-05-21 18:39 GMT+02:00 Tomasz Boczkowski <penginsbacon@...400...>:
Hi!
I started porting inkscape widgets to gtkmm and c++ and have a few questions:
- There are two directories src/widgets and src/ui/widget. Is the former
deprecated?
Yes, src/widgets and src/dialogs are deprecated and should eventually be removed. There are also several widgets in files in the src/ directory.
- Should I move classes to src/ui/widget after c++-sification?
Yes. Note: a lot of code uses Java-like deeply nested namespaces, e.g. Inkscape::UI::Widget::Foo. I think this is completely unnecessary, you can use Inkscape::UI::FooWidget.
- What is the proper macro to differentiate between gtk versions?
GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0?
The latter, but be sure to include config.h whenever you check this macro.
Regards, Krzysztof
participants (3)
-
Jon A. Cruz -
Krzysztof Kosiński -
Tomasz Boczkowski