On Mon, Jan 03, 2005 at 02:58:48AM -0600, Derek P. Moore wrote:
that radically different. And many development communities are familiar with the concepts of separate "stable" and "development" trees. The people working a lot on 0.4 can keep working a lot there. In about a month or so, we'll probably be ready for 10% of your coding time to help move your bits to the development tree.
In projects with a lot of process and tight code control, when there is "stable" and "development" code, all coding happens to the "devel" branch. The "stable" is just that: stable. It only gets major bug fixes. This separation is pretty strict. What is sounds like you're describing is two "devel" branches. I don't think that's a good idea.
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.
Inkscape has survived a least two whole-sale replacements (renderer, fonts). I think the work involved in making incremental changes to hook the new GUI into the code is less than that of doing a major import some day in the far future where all the bugs need to be hammered out. It's too large of a back-loaded plan. Doing it now forces bugs to be worked on while the new code is fresh, rather than having all the bugs of the entire replacement system appear at once at the end. This is hard to deal with (font bugs were chased for two release cycles, if I remember correctly, and we've still got open specific-to-a-font bugs now).
Another worry I have is that of design memory. There are a lot of usability design features incorporated into the way the various existing systems and widgets work now, and doing a whole-sale replacement (rather that working in parallel in the same code) could cause those missing features to go unnoticed for a while. (Take for example, the loss of the filename extension selection preferences in the new file dialog.)
I'd say, just set up the directory hierarchy like was suggested, get it imported and set up as a separate compiling thingy (like inkview is) and continue work in the main branch. As major elements are finished or become usable, tack them into the "real" inkscape. This will cause some amount of code bloat in inkscape for a while, but I still think that's worth the trouble. We don't have a lot of programmer resources, so splitting up the team between two devel branches, I think, is unwise.