Since the main focus of 0.47 is refactoring, I'm posting some ideas for discussion I've come up with while refactoring the preferences code (the final version of which just made it into SVN).
1. id-clashes.cpp - this is a stopgap solution at best. The roadmap proposes to solve this problem by making SPObjects ref-aware. I think this isn't a good idea, as it uses a canvas level API to solve an XML level problem. The real solution would be to make the XML tree CSS-aware (to detect ID references in CSS), and handle this transparently by special-casing the "id" attribute so that setAttribute("id", "something") would automatically update every ID in the document. An alternative approach would be to have an XML::Document level API like alterID(gchar const *oldid, gchar const *newid) which would do the same.
2. 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.
3. Namespace proliferation. Many namespaces contain just a few members and their fully qualified names are very long. The record is namespace depth of 4 for internal bitmap extensions and a few other things. Is this level of granularity really necessary? There's also the UI namespace - its purpose is unclear to me because Inkscape::UI::Widget::SuperGizmo conveys no additional information compared to Inkscape::Widget::SuperGizmo. It's obvious to me that widgets and dialogs are parts of the UI, so why put Widget and Dialog namespaces in another namespace? On top of that, names of many classes are redundant, like Inkscape::UI::Dialog::SomeDialog. It should be either Inkscape::UI::SomeDialog or Inkscape::Dialog::Some. BTW: The "using namespace" directive is discouraged in the coding practices.
4. Transferring data between Inkscape and other apps. The new clipboard code is a step in the right direction (by the way - thanks for everyone for fixing the issues with it I weren't able to find), but the "import/export drawing data as some format" functionality should be split off into another function/object, so that the same code is used for importing and exporting via drag-and-drop, the Import and Export dialogs and the clipboard.
5. 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.
6. 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.
Please let me know if you have any suggestions / objections regarding those refactoring problems, and whether they make sense to you.
Regards, Krzysztof Kosiński.