On Feb 11, 2012, at 12:17 PM, Josh Andler wrote:
I should have elaborated. By saying sooner rather than later, I wasn't meaning immediately. :) The deprecated stuff needs to be handled first, but we still have to take http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies into consideration. With that, trunk can't require anything above 2.22 until 9/15 of this year.
Since I am unsure if the goal of making changes to achieve "disable deprecated" being successful requires anything actually included in 2.24, that was why I mentioned the possibility of sooner rather than later. Basically, that branch would start by getting GTK2 requirements met that we may not be able to do in trunk due to project policy. If there's nothing that requires 2.24, it's obviously a non-issue about branching in the near-ish future as it could all still be handled in
I think, as Alex highlighted, we'll have a natural progression to getting compatible with 3.x.
It's looking like getting compatible with 2.x and 3.x both will allow a few things, including getting to native OSX.
So I think the next immediate step is working on cleaning up to get to GTK3 compatibility (but not dependence).
Then the second step should be working with native the OS X version of GTK. That GTK work is going on in the 3.x line, and is probably the point that will give us the most user benefit in the near term. This probably can be done a bit in parallel with the general 3.x compatibility cleanup.
Another thing we will get with supporting GTK3 is multipointer (MPX) and then multitouch support. However, many parts of our internals will need to get refactored to work well in those areas. This also is related to much of what needs to get cleaned up for multithreaded support, etc. So I think this sort of cleanup will be helpful for many things. It also will clear up some entanglements that get in the way of new code and/or functionality.
Finally I think we can then focus on a few GTK3 specifics and later on dropping GTK2 compatibility.
That then gives these rough phases:
* GTK_DISABLE_DEPRECATED / GTK3 compatibility ** few simple #ifdefs to keep 2.22 compatibility * Work on native OSX GTK. * Tool/context/global cleanup. * Leverage MPX * Add targeted GTK3-based features * Drop GTK2 compatibility
Looking through our current codebase and the various changes we will need to be making, nothing really jumps out that flags needing a formal branching (aka nothing more than the normal local branches devs do now when working towards trunk). This strikes me very similar to our early efforts to move from C to C++. We tried the whole "new code" branch thing, but that didn't pan out. Instead just steady incremental improvements in trunk turned out to be far more successful.