Re: Justifying the GTK+ 3.0 ABI break

[Mike Kestner <mkestner gmail com>]

On Mon, 2008-07-14 at 12:08 -0400, Havoc Pennington wrote:

> On Mon, Jul 14, 2008 at 11:37 AM, Johan Dahlin <jdahlin async com br> wrote:
> >
> > Why should the life of a GTK+ developer hard per definition?
> >
> > The main reason is exactly to make it easier for existing and new developers
> > to contribute to GTK+, the rest are only secondary.
> 
> Is lack of sealed objects really what's using up most of the
> maintainers time? 

Or maintaining a bunch of deprecated API?  I'd be interested in an
assessment of the amount of effort that's involved in leaving deprecated
API in the library.  It doesn't seem logical to me that this would be a
big time consumer.  

>From Gtk#'s perspective, as long as accessors are provided for the
fields, we wouldn't need to break compat for the sealing of fields since
we wrap all the fields in read/write properties.  Ironically, the "while
we're breaking C compat let's kill the deprecated stuff" piece of the
plan kills our compatibility.

As to the initial question, a Gtk+ developer's life is "hard per
definition" so the application developer's life can be easier.  In
theory, the latter should greatly outnumber the former.

I'll jump on the bandwagon by saying I'd like to see an implemented new
feature which depends on (or at least demonstrates the clear benefit of)
the breaking of ABI/API compat before GTK+ actually breaks compat.
Otherwise this seems like an exercise in beautification at the expense
of all Gtk+ users and distributors.

Mike