I'd like to see the Gtkmm work moved into the main branch. Just get it in there as the separate program it is. The classes and GUI elements can be tacked in as you go. For example, we already have co-existing dialogs, etc. The major changes will still be major, but at least the surrounding code work will already be done for it.
I'll be honest here and say there's a lot I still don't know about the legacy code. But from what I've seen so far, and especially from my work in helping to flesh out the Gtkmm stuff, a number of the required changes/cleanups will run pretty deep. And unless Bryce has some particularly powerful magic up his sleeve, I don't see how we'll be able to have both codebases in a single tree. (I could very well be wrong, and would love to be shown otherwise.)
If we try to put them both in a single tree, many files will be duplicated as work progresses, so we'll have an effect similar to working on separate trees. Because many files will have to be dramatically edited (in most cases, removing a lot of cruft along with a fair bit of reorganizing), we'll end up with two different copies of the same (or similar) files. And if you want to fix a bug or add a feature in one, you'll have to check both. Very similar to working with two separate trees.
I was trying to describe something more along the lines of a "mostly stable" tree and a "definitely devel" tree. On a low level, their code will be identical, so as low level things get copied from "mostly stable" into the "definitely devel" branch, patches from the lower levels of stable should cleanly apply to devel. However, things that are just below the surface of the new UI will require radical changes as they're fitted to the new UI and modern GTK+ 2.4/2.6 ways of doing things. So either way we go, we'll have, as I see it, the same amount of duplicity to wrangle with.
You brought up the issue of the dialogs in the Gtkmm code. That actually helps to illustrate my point. There's almost no way to migrate the new dialogs and dialog manager down into the legacy codebase. We could certainly put that work in some subdirectory of the main tree, and have configure/compile options to use the new stuff instead of the old. But within that single tree, we'd then have two dialogs for everything until the old dialogs were entirely ripped out and the compile options for the old stuff were removed. So developers would still have the problem of having to edit two separate dialogs in two separate locations just to uniformly add a checkbox to "Align and Distribute".
But, anyways, I'm still young and dumb and have a lot to learn. I'm probably seeing this all wrong, and I hope it ends up all fitting together much easier than I imagine it might.
Peace out,
Derek
PS: I don't mean to scare up any FUD by introducing this thread. I don't think we have to worry much about a "divergence" between the two codebases or other such concerns that have come up with regard to the Gtkmm work.