There has been a lot of discussions about the proposed GTK+ 3.0 plan since Imendio presented it at GUADEC last week. Oddly, the presentation is months old, but it seems that the majority of people didn’t become aware until the GUADEC presentation. Imendio, a consulting firm that does a lot of GTK+ consulting, feels that GTK+ needs to move forward, and that their vision is the best means for that. Unfortunately, their vision involves breaking the Application Binary Interface (ABI) stability promise of GTK+ 2.x. Seriously, it’s on page 5 of the presentation linked above.

Why is this a problem? It means that developers will always have to struggle to keep up with the ABI. Independent Software Vendors (ISVs), who have favored GTK+ on Linux to date, would absolutely not put up with this kind of shit. Luckily, Miguel De Icaza, recognizes that Imendio’s plans are short-sighted, particularly in that the current ‘plan’ involves no new features. Breaking the ABI for GTK+ 3.0 isn’t necessarily a bad thing, major version releases change ABIs, and it’s possible to install the 2.x series alongside the 3.x series. Hell, I still have a copy of GTK+ 1.2 on my system, though few applications use it.

Windows is successful because of ISVs. There is really no doubt of this. Unfortunately for Microsoft, some ISVs are beginning to become interested in Apple’s platform, which has a better programming interface. As ISVs begin to support the Macintosh, the current status quo will continue to shift. However, part of the reason that developers love Microsoft’s platform so much is that Microsoft works amazingly hard to prevent ABI breakage. In the early days, this meant buying every application for Windows, and making sure that the old applications worked on the new version. Later, this just meant making sure that the even when fixing bugs, the OS still would function as an application expected, even if the application depended on bad behavior. There is a very, very good chance that I can take a Windows 1.0 Application and run in on XP (Vista actually did change things, so I won’t claim Vista).

Everyone remembers DLL Hell, which was largely a symptom of Microsoft’s approach to this problem, but ultimately, it kept ISVs happy, and kept software coming out for the platform. Apple’s biggest weakness with developers, is that they have been breaking the ABI with every new version of OS X. They usually try to give Developers an opportunity to test the new version of the OS before they release, but this doesn’t always work out. If anything is going to slow the adoption of the Mac platform for desktop application developers. This is it.

And Imendio feels that this is the direction that GTK+ should take. Part of this, I’m fine with. Breaking the ABI when it is necessary to move forward because of an actual design flaw in the previous version, or because some new functionality is actually impossible to provide in the previous version. Occasionally, bringing satellite libraries into the core is worthwhile as well. However, Imendio is not taking about either of these things.

So far, the only things suggested for the 3.0 road map, is getting rid of Public fields in favor a getters and setters, and removing anything marked as deprecated. Okay. Great. Both of these sounds like reasonable things to do. But what then? What does doing these things gain you that you can’t already do in GTK+ 2.x? How does this give you the ability to stack widgets? Build non-standard UI? What the hell is ‘non-standard UI’ (Actually, I think they want WPF-like functionality)? Why do you think we need physics support in GTK+? How do you intend to make creating widgets easier? What kind of OS-level functionality do you think belongs in GTK+? And what’s the deal with tabs?

Okay, so the tabs thing was a joke at KDE’s expense. Back at the point…

Can GTK+ be improved? Almost certainly. However, before it’s worth discussing too much, you need to be able to provide a good case for the move. You need to prove to developers how GTK+ 3.0 will actually improve things for them. Emmanuale Bassi seems to feel that GTK+ 3.0 is absolutely necessary. However, I haven’t read anything that presents a strong case of how GTK+ 3.0 will actually improve GTK+. In fact, Emmanuele even seems to acknowledge that the current GTK+ 3.0 proposal will be feature weak.

The real danger with GTK+ 3.0 at this point, is that the GTK+ team will begin moving in that direction and let the proven GTK+ 2.x fall to the wayside, to be ignored as the team tries to move forward without a plan that ISVs can get behind. Perhaps Emmanuale is right, and the ISVs don’t seem interested in shaping GTK+. However, before embarking on a new major version, the GTK+ team needs to reach out to those ISVs, and make the discussion open to all users of the platform. The GTK+ platform needs to be shaped by the ISVs who use it. And frankly, it should probably be shaped largely by the commercial ISVs. If anything, this is largely QT’s biggest leg up on the API war. It has always been a commercial library, with a commercial company backing it and responding to commercial customer needs.

GTK+ began it’s days as a toolkit for the Gimp, and that’s basically all it was used for until Miguel and Nat decided to use it for the beginning GNOME project. Since then, GNOME has been the primary force driving GTK+ development. But because of the ABI-compatibility promise in GTK+ 2.x, there are more ISVs using GTK+ than even QT on the Linux platform. But this number is still abysmally small. Don’t fork for GTK+ 3.0 until there is a solid picture for what GTK+ 3.0 needs to be in order to supply the functionality that ISVs demand, but GTK+ 2.0 is unable to provide.

I don’t think anyone is completely opposed to the idea of GTK+ 3.0. We just want to see a really, honest to god plan and reason before that direction is taken.