I'm coming in a bit late in this thread, but let me reiterate the plan, and address some of the issues that were raised.
* If you have strong feelings for how/when the gtkmm code is integrated, you are welcomed to get involved with working on the code.
* The inkscape_gtkmm code will be merged immediately after 0.41 is released. Remember, we were going to do this for 0.40 but people wished to squeeze out one more release before then.
* I do not think we can wait any longer than that, though, because while the code is not diverged yet, there is less and less we can do without having the full codebase behind it.
* If you've been refusing to help on the gtkmm work in order to boycott it into getting merged, I think you're a twit. ;-)
* I would like to continue with the current numbering scheme, and not jump to 0.50. As others point out, this is not the first big change brought to Inkscape.
Several people have suggested that a refactoring-in-place would have been a better approach. I had thought so too, but consider: That was already being done BEFORE I started on my side work. Honestly, I entirely expected that most of the gtkmm work would be done before I'd ever get anywhere with my codebase; after all, I'm one of the least prolific coders in this project!
Yet consider what actually happened: Different people each worked on different dialogs; each person's gtkmm implementation is different. There is now a lot of inconsistency between the dialogs, much more than when Inkscape started. Several of these dialogs were only partly finished before the coder became inactive or switched to other things. In several cases of Gtkmm conversion there was functionality lost, which some found particularly consternating due to the absence of the implementor. Clearly refactoring-in-place is not without a few risks.
Meanwhile, I've found working in a distinct codebase for the early portion of the development to be quite effective for me. With less total code to deal with, I found it easier to keep track of everything. It was faster to compile, easier to rip things out and do wholesale rewrites, and simpler to enforce code style and write documentation for it. On more than one occasion as I've learned new gtkmm tricks, I've realized I was a complete idiot; I was able to chuck the code out and start again, no harm no foul. The upside to having few people working on it, is that I've been able to keep the whole reasonably internally consistent.
But (thankfully) the code's been growing quickly. The simpleminded build system is now more hinderance than help, and we need Autoconf. Wholesale rewrites are much rarer now, and I think the framework is fairly solid now. I think that with this conceptually-unified structure, it will help address and avoid the inconsistencies that were such a problem before. Yet it's still young and pliable enough that it won't be very painful to change it where needed.
I've dug through the main codebase, and I've got a strategy for how to merge this into there, that I've talked about before. I'm fairly certain it can be done without too much trouble (magic shouldn't be required), however there are several things I'm concerned about:
* We need to be careful about things becoming highly inconsistent again. Don't Rush.
* The code is far from ready to be used right now. I don't think it is practical to replace the current ui with it; it has to be kept off to the side at least for a little while, until it's ready to go.
* The new ui code will almost surely have some (many?) aspects that won't be as good as the current codebase. Be Patient.
Bryce