Justifying the GTK+ 3.0 ABI break

[Murray Cumming]

Every time that a parallel-installable GTK+ 3.0 has been proposed, and
now that it has been decided, I have asked for a list of actual useful
features that it will make possible. I've had no luck so far.

We need to offer people a future with some specific advantages so it
doesn't just look like the GTK+ developers are making their own lives a
little easier and scratching an unimportant itch. People don't care if
maintenance is hard for us, but they do care about new features and
particular bug fixes.

If the code cleanup is really necessary then there should be some things
we can list that it will make possible. It would be best to have that
list soon rather than after the slashdot shitstorm hits.

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Johan Dahlin-2]

Murray Cumming wrote:
> Every time that a parallel-installable GTK+ 3.0 has been proposed, and
> now that it has been decided, I have asked for a list of actual useful
> features that it will make possible. I've had no luck so far.
>
> We need to offer people a future with some specific advantages so it
> doesn't just look like the GTK+ developers are making their own lives a
> little easier and scratching an unimportant itch. People don't care if
> maintenance is hard for us, but they do care about new features and
> particular bug fixes.

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.

I'm sure plenty of application developers are going keep on using 2.x for a
long while, that's perfectly fine.

I do think that it's a little bit of a wasted opportunity to use the 3.0
release number to something as 'boring' as doing process/policy changes etc.
I'd prefer using another number, such as 2.90.x for that and make 3.0
contain more of the 'bling', larger functionality additions.

Johan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Havoc Pennington-2]

Hi,

On Mon, Jul 14, 2008 at 11:37 AM, Johan Dahlin <jdahlin@...> 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? I would be more sold on that if Matthias, etc.
posted and said this was using up their time. I have never heard them
say that. I don't know where their time goes, but when I was working
on gtk, this was definitely not it.

To me the point should be and hopefully is to enable new features and
enhancements. Though like Murray, I'm skeptical that sealed objects
really do that. There's more to ABI than struct fields; the hardest
part is keeping _semantics_ backward compatible. You can kill the
foo::label field but people can still rely on foo_get_child()
returning a label, for example.

I don't think any fundamental semantic changes - whether making GDK
less X11-like, or moving to a scene graph, or nuking child GdkWindow,
or fixing GtkStyle to be less crap, would be enabled by sealing object
fields. I agree (I think) with Murray on that. So by sealing first
instead of having those changes ready, we're postponing all those
semantic changes to GTK 4.0 (which is however long in future - 4-5
years I guess?), because they will be new ABI breaks not included in
3.0.

All this said, I'm glad someone is interested in GTK and some
decisions are being made.

Havoc
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Mike Kestner-4]

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

> On Mon, Jul 14, 2008 at 11:37 AM, Johan Dahlin <jdahlin@...> 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

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

> Or maintaining a bunch of deprecated API?

I looked at the log for gtkclist.c and the majority of the changes over the
past five years are a direct consequence of the api having been declared
deprecated.  Specifically there is a lot of defining and undefining of
GDK_DISABLE_DEPRECATED going back and forth there.  Even so,
not much is going on.

So the maintenance burden, to the extent there is one, is _caused_ by
deprecation.  And that's even within gtk+.

Pretty ironic, isn't it?

Morten
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Behdad Esfahbod-3]

On Tue, 2008-07-15 at 20:01 -0400, Morten Welinder wrote:
>
> So the maintenance burden, to the extent there is one, is _caused_ by
> deprecation.

This is ridiculous.  It's  perceived that way because all bugs against
deprecated widgets is closed WONTFIX.  It's not like if the widget was
not deprecated it would have consumed less maintainer time...

--
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Morten Welinder-2]

>> So the maintenance burden, to the extent there is one, is _caused_ by
>> deprecation.

> This is ridiculous

Nobody is laughing and you are not reading what I wrote carefully
enough.  It really is the elaborate deprecation (as opposed to simply
dropping in a comment and not maintaining the code any more) that
is causing the burden.  That's what the log say -- assuming gtkclist
is representative -- which I would guess it is.

In other words: keep the interfaces around instead of causing grief
for applications on a weekly basis.

Morten
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Matthias Clasen-2]

On Tue, Jul 15, 2008 at 8:22 PM, Morten Welinder <mortenw@...> wrote:

> In other words: keep the interfaces around instead of causing grief
> for applications on a weekly basis.

Don't be silly.
Nobody is causing grief on a weekly basis.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Sven Neumann]

Hi,

On Tue, 2008-07-15 at 20:22 -0400, Morten Welinder wrote:

> It really is the elaborate deprecation (as opposed to simply
> dropping in a comment and not maintaining the code any more) that
> is causing the burden.  That's what the log say -- assuming gtkclist
> is representative -- which I would guess it is.

It is not representative. GtkCList is long deprecated, and there's a
working replacement for it. It is basically just kept around for
backward compatibility. What is really a burden is how difficult it is
to add new features to widgets that are still being used. And that's
because forward compatibility has not always been considered well enough
in the past. From what I understand the GTK+ developers are now trying
to eliminate that mistake.


Sven


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Murray Cumming]

On Mon, 2008-07-14 at 17:30 +0200, Murray Cumming wrote:

> Every time that a parallel-installable GTK+ 3.0 has been proposed, and
> now that it has been decided, I have asked for a list of actual useful
> features that it will make possible. I've had no luck so far.
>
> We need to offer people a future with some specific advantages so it
> doesn't just look like the GTK+ developers are making their own lives a
> little easier and scratching an unimportant itch. People don't care if
> maintenance is hard for us, but they do care about new features and
> particular bug fixes.
>
> If the code cleanup is really necessary then there should be some things
> we can list that it will make possible.

The closest thing I've seen to this so far is some items on Tim Janik's
blog:
http://blogs.gnome.org/timj/2008/07/16/16072008-guadec-2008-wrapup/
(search for "User visible gains are post-3.0 feature")

Could you please decide on some official list and put it somewhere
official. If there's no list of things that this break makes possible
then it's very hard for anyone to believe that the break is necessary.
If we get sick of asking and getting no answer then you can't just claim
that there are no objections.

>  It would be best to have that
> list soon rather than after the slashdot shitstorm hits.
>
--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tristan Van Berkom]

On Mon, Jul 14, 2008 at 11:30 AM, Murray Cumming <murrayc@...> wrote:

> Every time that a parallel-installable GTK+ 3.0 has been proposed, and
> now that it has been decided, I have asked for a list of actual useful
> features that it will make possible. I've had no luck so far.
>
> We need to offer people a future with some specific advantages so it
> doesn't just look like the GTK+ developers are making their own lives a
> little easier and scratching an unimportant itch. People don't care if
> maintenance is hard for us, but they do care about new features and
> particular bug fixes.
>
> If the code cleanup is really necessary then there should be some things
> we can list that it will make possible. It would be best to have that
> list soon rather than after the slashdot shitstorm hits.

<general thread reply>

I just wanted to jump in and say thankyou to the team for finally standing
up and making this decision, in fact, Ive been crying about this for a while
and would even consider it overdue.

Its been my (mis-?)perception that gtk+ has been under pressure by so
called ISVs for a long time to not break abi, fair. and the Gtk+ team has
made IMO extraordinary efforts to have a clean abi and way of tracking
what is new/deprecated and all.

I think this is not so much of a technical discussion, the point is that
alot of the communal code is contributed by various sources, some
completely volunteer work, other significant portions are sponsored
projects - sponsored projects will always have big features as goals.

I believe that for basic survival of gtk+ codebase (technical reasons
outlined by Behdad and Sven in this thread) - the community has to
be allowed after some time and blow the whistle and do some refactoring.

This refactoring will slim to never be a sponsored work, so all
the thankful users of free and good gtk+ I'm afraid dont get the "right"
to a new feature with an abi break - its not to be mean, we just have
to be understanding of how the resources work (some will undoubtedly
not understand, for gtk+ codebase to survive and evolve, we need to
just ignore those people and prove them wrong with 3.2).

3.0++

Cheers,
                 -Tristan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list