Havoc's Blog

Chris Blizzard said it
struck him at GUADEC that there were two very different initiatives,
desktop and mobile, happening in the GNOME community.

Miguel’s
post on GTK+ 3.0 reminded me of Chris’s comment.

In the mobile world GTK+ is not quite ideal, and GTK+ based platforms
are in the early-to-mid stages, not the highly-mature stage. I bet
GTK+ needs a lot of evolution to be what it could be in non-desktop
contexts.

For the Linux desktop, GTK+ should be kept stable and mature, while
for new opportunities, perhaps not.

In a post last
month I argued that evolution was appropriate for the Linux
desktop, while revolution was appropriate for new ideas and
categories of product. But what if GTK+ is part of both?

Two new directions people are working on: 1) GTK+ as an improved
cross-platform desktop toolkit, and 2) GNOME technologies refactored into
a mobile platform.

Thought: in the GTK+ 3.0 discussion, discuss how GTK+ can
address both these new directions and the traditional Linux
desktop, without screwing anybody.

Thought #2: as with any project, GTK+ will be driven by whoever is
doing the work. And as with most big projects (Mozilla, Linux, GTK+
itself historically), clusters of developers with funding will be able
to do a lot of work. Most of the work today seems to be funded by the
non-Linux-desktop developers (who have some significant-to-them
revenue stream attached to GTK+), not by the desktop Linux
distributions (who can’t connect GTK+ work to revenue in a compelling
way). If the Linux desktop developers can’t find revenue, and can’t
muster significant volunteer resources, they are going to have less
and less influence – that’s how open source works.

2.x forever?

GTK+ needs an ability to evolve, which means a 3.0. Another way to say
it: new toolkits should not have to start from scratch, they should be
based on existing GTK+ code. Because 3.0 would be parallel-installable, it’s
a new toolkit in the GTK+ tradition, but not the same library. It does
not replace 2.x in an operating system install.

3.0 replaces 2.x to the extent that the people working on 2.x
stop working on it, and shift to 3.x. If there’s nobody who wants to
keep working on 2.x beyond a certain point, it’s tough to argue 2.x is
important beyond that point. 2.x could live forever if someone were
interested in doing the work.

In open source, “important enough to me that I’ll work on it or
pay someone to work on it” matters. “Important enough to complain
about” does not matter much.

ABI sealing and deprecation

All approaches to GTK+ 3.0 have their downsides. The downside of
“break ABI without adding features” for me is that an ABI break
opportunity is “wasted.”

Sealing struct fields and removing deprecated stuff doesn’t much
increase the list of features that can be implemented without breaking
ABI. Most ABI breaks are semantic, not a technicality about a struct
field. Example: whether you have gtk_widget_get_window() or
((GtkWidget*)widget)->window, you still can’t get rid of the
GdkWindow, nor can you move GdkWindow creation out of realize().

Most features requiring an ABI break would end up in GTK+ 4.0, which
is in a long time. So the 3.0 ABI break will be “wasted” in that
sense.

I was kind of hoping for some things like killing all non-toplevel X
windows, or killing X11-centric GDK API in 3.0 … instead of waiting
for 4.0. That’s the part of the GTK+ 3.0 proposal that makes me a
little disappointed.

However: the sealed struct fields and deprecated-stuff-removal would
make it simpler to work on ABI-breaking features in a branch,
and simpler to maintain an ABI-incompatible device-specific or
platform-specific branch, I imagine. It would also be simpler to
automatically find all uses of a given field or behavior in a set of
apps, in order to update them. Maybe it’s ideal to have a bunch of
“4.0 candidate” feature branches over the next few years, eventually
merging them to ship 4.0 in five years.

I’m skeptical, as many others are, of claims that “cleaning
up code” or “removing deprecated stuff” are ends in
themselves… sometimes code cleanup is important, because the code is
still in active use, and it becomes impossible to make it correct or
understand it anymore. But the deprecated GTK+ widgets aren’t like
that; they are just sitting there untouched and are a cosmetic problem
at worst. They don’t significantly affect anyone who isn’t using them,
that I know of.

It bugs me when people act like deleting deprecated stuff is an end in
itself, without discussing what it enables. Even if deprecated stuff
is using up more than a few percentage points of maintainer time (is
it? I have trouble buying that), if the problem with it is
maintenance time, maybe the way to address that is to find some way to
pile another maintainer on, instead of disrupting all app developers.

Besides, the worst deprecated stuff was all kept out of GTK+
… there’s a bunch of free deprecated-stuff-ectomy still possible by
finishing Project
Ridley.

Conclusion

I’m happy people are trying some new directions such as mobile and
GTK-as-true-cross-platform-toolkit. Ability to break ABI will be
needed for that work at some point.

To be clear:

• I don’t know on balance what approach is best for 3.0.
• I’m not doing the work, and those who are will/should
  decide on the future path.

Here’s to progress!

(This post was originally found at http://log.ometer.com/2008-07.html#16)