On Oct 20, 2008, at 2:28 PM, Krzysztof Kosiński wrote:
- id-clashes.cpp - this is a stopgap solution at best...
Probably the #1 first step here would be to remove the legacy behavior of adding an id attribute on every object. They should only get added as needed, and be left out for the vast majority of elements.
- Tools tree. This is one of the last big chunks of GObject left
in the codebase. It's also rather messy - for example, every tool has a gradient dragger but in reality it only makes sense for the Node and Gradient tools. Converting this hierarchy to C++ would be a great step forward. It would also get rid of toolbox.cpp.
Converting to C++ is good, but it wouldn't get rid of the need for toolbox.cpp. It basically has a legacy naming now, but the general approach it currently has should probably be preserved. It is the place where the switch to dynamic UI and GtkActions has had the most traction.
- Namespace proliferation...
BTW: The "using namespace" directive is discouraged in the coding practices.
Yes, "using namespace..." is definitely bad, especially in .h files. However using a namespace{} block or "using" statements with specific classes is quite helpful.
- Memory leak problem (?). Inkscape is constantly eating memory
even when idle. Is anyone aware of why is this happening? Also of note is the fact that creating a single rect can take up to 250 kilobytes.
Please note that we have garbage collection as a factor, so eating memory may or may not be a leak. Tracking info down needs to keep this in mind.
- Verbs. It looks like verbs.cpp is a reimplementation of
Gtk::Action with some extra features. I don't know this part of Inkscape very well but it looks like we could create an Inkscape::UndoableAction deriving from Gtk::Action and use it instead of verbs. We could then use Gtk::UIManager to build menus and toolbars.
Actually Verbs and SPActions predate GtkAction itself. Verbs do a bit more than GtkAction, and there is some per-desktop tie-in to be considered. Work to move to standard GtkActions as much as possible has been ongoing for quite some time.
GtkUIManager *can* do dynamic UI, but its XML has taken the wrong approach. It's a very pixel-tweaking oriented approach, which is quite different from what we need (a more abstract representation). Oh, and toolbox.cpp has been converted to mainly use GtkUIManager internally. We've just not exposed the XML directly since it needs to be translated from a more suitable XML format that end users get to see.