The Gtk+ 3.0 proposal being discussed currently sounds like
a disaster for GNOME. The reasoning was first articulated in
the
histrionic Imendio
Gtk+ 3.0 Vision presentation done at the Gtk+ Hackfest in
Berlin. This is a meeting where application developers were
underrepresented, and somehow we have accepted those proposals
as the community consensus.

The proposal goes like this: Gtk+ 3.0 will hide all public
fields in objects, provide accessors to these, remove APIs
that have been flagged as deprecated and introduce no new
features.

All the actual new features that some people want would
come up in future versions. Which features will come is yet
to be decided, because nobody knows when and what will be
implemented.

There are lots of technical problems with the
proposal, and from my discussions this week at GUADEC it does
not seem that the Gtk+ developers have discussed the
implications with the users of Gtk+.

There is a major strategic problem with the plan as
well. The most important one is that there is no actual plan
for which features will be added, and when these features will
be added. There are no prototype implementations, and the
idea of first developing the new features in a branch to
actually study the code, the implementation and its potential
APi breakage is not even on the agenda.

Basically, we are being told that we should trust that
first breaking the API and hiding fields will suddenly enable
a whole generation of new features to be implemented.

But it gets better. There are no guarantees that 3.x will
not break the API if the feature in question turns out to
require API breakage. Which means that we might actually end
up in a situation where there will be multiple API breakages.

This by all means sounds like a bad plan.

Towards a Better Plan for Gtk+ 3.0

I am not against breaking the API for newer versions of
Gtk+ if the benefits outweigh the downsides, and the execution
presented is not bad. But "3.0 will help us clean up" is not
a good enough reason.

We need:

A Clear Roadmap: We need a clear roadmap of
which features will be implemented and when they will
be implemented. This is the first step to making
decisions.

A clear roadmap would also allow new developers to
join the efforts and big companies like Red Hat and
Novell to dedicate some full time resources to make
some of these feature happen. As things stand today,
we are basically being told to
"wait-until-3.0-then-we-will-sort-it-out".

Working Code: Before a feature for a future
version of Gtk+ can be considered a reason to break
the API, the technology must exist in the form of a
patch/branch.
This is not new, and should be of no surprise to
anyone. This is how the Cairo integration into Gtk+
was done, how the layout changes are being implemented
and how every other software product is ran.

New API-breaking features must be publicly
discussed with the community: Since this will
affect every application developer (open source and
proprietary) we should get the feedbacks of these
communities.
We could all get as excited as we want about a
"gboolean bouncing_text" field in a GtkLabel, but that
does not mean that we should break the API for the
sake of it.
Application developers were underrepresented at the
Berlin hackfest, and even GUADEC is a microcosm of the
ISVs that we had to reach. For instance, I did not
see anyone from Adobe, VMware or Medsphere at the
conference.

Transitional 2.x Releases: For a long-enough
period to get distributions to include the code, Gtk+
2.x should include getter/setter macros to allow
software developers to upgrade their source code to
work with and without the public fields. To
soft-land the switch to a hiding-field Gtk release
(this is covered in the Imendio proposal).

This is by no means a comprehensive plan, it is only the
beginning of a plan.

Gtk+ Extensions

From looking at the original Imendio proposal. it seems
that plenty of the things they want can be implemented without
breaking the API:

Animation: doable entirely without breaking the
API. The animation/storyboard framework is an
entirely new codebase, that would not touch anything
in Gtk+. Some widgets might require smoother
rendering on changes, but all can be done in an
API-compatible framework.
public API.

Physics: same, add-on.

Data-binding: same, add-on.

Easier language bindings: same, add-on.

Improved back-ends, more OS integration: Can not
think of a major issue, but granted, I could be
missing something, and Imendio has done the OSX port.

And my own favorite: killing all Gtk+ theme engines, and
replacing it with a Qt-like CSS theme engine. This is not
really an API break, as the only consumers of this code are
the theme engines, and those we can safely kill and replace
with CSS themes, no application code would break.

Maybe
Havoc's
proposal requires an API breaking change. And maybe
this is worth breaking the API for. But breaking it for no
gain, and no prototype to even understand the actual effects
post 3.0 is wrong.

Update: For what its worth, I would lean towards breaking
compatibility in 3.0 if it meant 3.0 would include the
Havoc-like Scene system. That would make it worthier of a
change.

Update: As usual, the Linux Hater
Blog has
some great commentary. Some of his feedback on KDE 4.0
applies to our own decision making. Worth a read.