Gtk+ 3.0

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.

Lets please avoid inflicting in GNOME a KDE 4.0 (yes, I know its not the exact same scenario; and yes, I know those clock applets are cute).

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.