On Feb 11, 2012 2:56 PM, "Jon Cruz" <jon@...18...> wrote:
I think, as Alex highlighted, we'll have a natural progression to getting compatible with 3.x.
I didn't think I said anything differently, I personally think that the less ifdef'd code we have, the better. Also, I want to point out that developers come and go. If we have someone who is really inspired to craft up GTK3-only widgets for us, why deny them a proper official branch to work in? Personal branches and patches in our bug tracker are seemingly where things go to die.
So I think the next immediate step is working on cleaning up to get to GTK3 compatibility (but not dependence).
Again, I don't think I anything differently. I didn't propose abandoning GTK2 compatibility ASAP. I didn't say let's jump right to dependence in trunk, as I think that's a poor idea. But I think we need a place that is safe for people to put it if they're inspired to take the task on. Also, having a safe testing ground where things are *allowed* to have non-ancient library requirements is appealing, it's a way to provide more interesting things to the bleeding edge testing community as well.
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.
A majority of our users aren't on OSX. It's not mathematically possible to get the most user benefit from targeting the number 3 group of users explicitly. I'm not saying it isn't important to address, but definitely not something that necessarily needs any more priority than addressing Windows users needs. Performance enhancements that affect all users would give the most user benefit. Startup speed for example wouldn't be a bad area to improve (or just accept the fact that no one will every address it and just implement a splash screen already). Performance degradation after extended periods of usage as well. Better performance when dealing with larger files. The thing you mentioned about us traversing defs multiple times as apposed to only once. Crash bugs, etc.
I wouldn't be surprised if we had more overall users interested in us addressing coordinates or even a proper "layer/object dialog" than the number of overall OSX users. Please don't use "most user benefit" so vaguely in the future to justify catering to a small section of our audience. Again, it needs to be addressed, I recognize the importance to that group and how truly unnatural it feels.
I will be sure to add discussion of viability and/or desire for officially sanctioned branches as opposed to personal branches. At the very least, it might be of interest to have a "staging" branch where all changes people want to commit to trunk after a release can reside. It allows people to work on new stuff in an official branch while the bug hunt happens. I'm bringing this up from the "it's how we can possibly have tighter/regular releases on a schedule" angle.
After one more reply, I'm done with this discussion until the irc meeting.
Cheers, Josh