Re: gtk3 planning



On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
>
> Sure, we could continue to shoehorn features in to 2.x and it will
> increasingly get harder, and the bugs will increasingly get harder to
> fix.

What we need to *realistically* look at is what big features that
aren't going to make 3.0 now will be able to land later without ABI
breaks.

> As long as I maintain the 2.x branch, it will be in maintenance mode
> and closed to features. I will gladly give up maintainership of the
> 2.x branch to you if you promise to port all the features that land
> there to 3.x as well.

Hmm?  Features would obviously land on 3 first, then get backported to 2.

> Fwiw, a big motivation for all the sealing business was to make it
> possible that GTK3 _can_ move faster and incorporate more new stuff
> without the need for disruptive ABI breaks.

Can say davidz's RI stuff land post-3.0?  Can "Full support for MPX
and multitouch devices."  Can "Revamp/rewrite the entire theming
system."?

I think the answer to all of those is "no".  While I know some MPX
code landed, as far as I'm aware none of the widgets have been updated
to possibly take advantage of it.  Do we really believe that we can do
that (easily) in an API compatible way?

> And the GTK3 plans always
> included the idea to do more regular ABI breaks, say every 2-3 years
> as well.

So, I think we agree!  2 years sounds fine to me.  However - and this
is important - we really should avoid putting Linux operating system
constructors in the position of possibly shipping multiple GTK 3.x
versions.  This means we need to communicate to application authors
that they should be willing to *stay* on the train if they hop on.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]