Several people have taken interest in how the Gtkmm work is coming along, particularly in where they could help move it forward.
The Gtkmm conversion is required for the 0.42 release, so it's got the high priority currently. We've got a ton of cool features besides gtkmm already in the can, so we have strong incentives to getting gtkmm done.
We really don't want to bump the gtkmm work to next release; we've already bumped it for the past three releases, plus we have a bunch of other highly requested features (like the layer dialog) that are dependent on the gtkmm work being in place.
Good progress has been made so far, but as you can imagine, reimplementing the Inkscape interface is not a trivial task! We've got most of the bones in place, but there's a lot of flesh to be hung.
We had started from the point of Gtkmmifying dialogs. We've made good progress in this area, and have converted most of the simpler dialogs. There's a few challenges still left, such as figuring out how to do TreeView-based dialogs like the XML Editor and the much-anticipated Layer Dialog, however for the most part I think we've got a good framework in place so it'll just be the effort needed to do the conversions. There's still a lot of TODO's in the code for doing things like hooking up preferences, gaining some better abstractions, etc. Jon Philips has been plugging away at some of these items.
Converting dialogs to Gtkmm is pretty straightforward. You choose the dialog you want to convert, create a new class derived from Inkscape::UI::Dialog, and go through the old dialog code, migrating function calls over. You look at the manual on gtkmm.org to learn what the C++ versions of the gtk calls are. Usually you can eliminate a lot of unnecessary code in the process (gtkmm is more concise, and the Dialog class takes care of a lot of the basics for you).
Meanwhile, Jon Cruz has been experimenting with a cool new idea that abstracts the contents of dialogs into "Panels" that could either be presented in dialogs or embedded in the GUI frame itself. I think this adds flexibility that many users may find quite helpful; it should be possible for someone to adapt the Gtkmm dialog architecture to this without too much trouble.
Jizzbug has done a bang-up job of Gtkmmifying all the toolbar and menu stuff. The Gtkmm interface now at least *looks* like the current interface. There's still some optimizations and tweaks needed - button sizes aren't quite right, for example, and we probably need to update the toolbars and menus with recent changes to the main codebase, but these are bite-sized tasks that seem very appropriate for new Gtkmm developers so I'm not worrying about them for now.
There's still a lot of chunks of the UI that haven't even been started yet, such as the statusbar and rt-click context menu. They're of medium priority, so I'm not worried about them yet, but they'll definitely have to be tackled before we can make the new UI the default.
The highest priority right now is getting the Canvas hooked up. This will be a major milestone to achieve since it'll finally let us *see* SVG documents inside the new interface. With that in place, the work of hooking up toolbars, menu items, dialogs, etc. can finally get under way in full earnest.
It looks to me like the path to achieving this is to C++-ify SPView and SPSVGView more, then reimplement SPDesktop and SPDesktopWidget in Gtkmm. This is what I'm focusing on myself right now. Last night I created some C++ member function wrappers for the sp_view* routines, and intend to continue this work through the weekend. Converting SPDesktop will be a sizeable project, but I'm hopeful within a week or so I'll have it in working order, if not completely done.
I'm really looking forward to having the Gtkmm work available for us to use in the main interface. Beyond just making the ui code a lot easier to work with, it's bringing in some rather cool innovations we will be able to take advantage of. It will eliminate a ton of quirks in the current UI. It will give users much more flexibility in how the UI is laid out. It will enable us to do some much more sophisticated UI designs, and give Inkscape the advanced UI capabilities that other leading edge GNOME applications have today. :-)
As you can see, there's a lot of areas where work can be done in parallel. There's still a lot of blank-page type areas for pure creativity, other areas that mostly work now but need good problem solvers to perfect, and plenty of bulk-work places where C++/gtkmm novices can have a big impact while they learn. I would strongly urge anyone that has some time in the coming months, a little C++ skill, and an interest in pushing Inkscape forward, to think about joining in on the Gtkmm effort. Contact me and let me know what you're interested in, and I'll help you get going. :-)
Bryce