GNOME 2.26 was released a few months ago, bringing some small changes and overage polish to the venerable GNU/Linux desktop environment. In six months time, GNOME 2.28 will be released which will bring yet some more polish a few more changes. One year from now comes GNOME 2.30. This release should be a bit different than the other releases before it. GNOME 2.30 will renumbered to GNOME 3.0. That’s right, what would be the 15th release (only even numbered releases count, here.) of the GNOME 2.x line will indeed be the start of the GNOME 3.x regime.
But with GNOME 3.0 is supposed to come GTK+ 3.0. GTK+ is the toolkit upon which GNOME and its applications are written. It standardizes the look and feel of the desktop using widgets for things like title bars, buttons, text fields, and pretty much everything making up the user interface. For the folks that develop GTK+, branding it as a 3.0 release will mean taking a huge step forward. Unfortunately, for both the folks that develop GTK+ and the folks that develop GNOME, baby steps are usually the norm. Its no wonder they picked little gnome feet for the logo.
For the longest time, the GTK+ crowd has prided themselves with not breaking backwards compatibility. By “the longest time” I mean 2002. For 7 years, GTK+ has been written so applications written with earlier versions of the 2.x release will be compatible. Ideally, a GTK+ program written for version 2.0 will work with 2.16. This means 2.16 is carrying around 7 years of code. Functions that have been depreciated still exist and are built for the sake of older applications. With GTK+ 3.x, some developers are calling for the backwards compatibility to finally be broken. They want a clean break from the ABI.
So what does breaking the ABI mean? It means every GTK+ application written would need to be recompiled against the new version of GTK+. But, since GTK+ has kept their ABI untouched for so long, pulling out all the old dusty code will likely cause every application to break. In my opinion this isn’t a bad thing. In fact, I think it could help weed out the older no-longer-maintained applications. If someone wants to take charge of an older app and fix it up to work with GTK+ 3.x, maybe even refactoring along the way, it will actually benefit the community as a whole.
The point is, in order to move forward GTK+ needs to break with tradition. Out with the old, in with the new. By cleaning up the codebase by deleting the depreciated code, developers will know where holes exist in their API. They will be able to come up with creative solutions without worrying about whether it will break something else.
Imendio, a now defunct company due to personal reasons, had a proposal on how GTK+ should move forward. That proposal can be found here. They not only call for a change of the code, but also wish to see a change in the development model for GKT+. This would allow the ABI and API of the toolkit to be changed on a timely basis so the underlying architecture of window’d applications can make use of new features.
The issue most developers are going to have with this is that as the ABI and API change, even on a regular, planned basis, any applications that rely on an older version’s ABI will need to at the very least be rebuilt to accomodate the new interfaces. This isn’t much of a problem since it would spark maintainability for projects relying on GTK+. No longer would an application suffer from bitrotting over time. Instead, it would just altogether break, and someone would need to fix it (hopefully, the developer of the project). Yes, it does add more work, and more maintanence. But isn’t that the reason we use open source software?
So, in order to modernize GTK the way Trolltech did with QT4, and in order to modernize GNOME the way KDE has been modernized, some drastic steps need to be taken.
- Actually remove depreciated code. Code marked for depreciation should throw compiler warnings for some time before its actually taken out. This will alert developers to either change their software, or explicitly ignore the compiler warnings.
- Break ABI during major releases. That’s the point of doing a major release. Providing new functions and getting rid of the ones that no longer work is part of the lifecycle of software. Besides, not breaking ABI can cause security issues like private structures being exposed as public.
- Focus on clean, fast functions. Make sure data structures use getters and setters instead of exposing private data.
- Allow, for a short period of time, perhaps 2 years, for GTK+ 3.x to live in a separate namespace so GTK+ 2.x can be coinstalled. This will allow applications to continue working under GTK+ 2.x while developers can transition applications to GTK+ 3.x.
In one year the GNOME team is planning to release GNOME 3.0. This should be the starting point at which all of GNOME begins porting to GTK+ 3.x. In the meantime, GTK+ 3.x will be able to work without fear of causing applications to stop working every other day. KDE was able to do this with QT4 but it caused some problems. KDE was attempting to completely rewrite their desktop environment in one swoop. GNOME needs not do this. However, getting GTK+ 3.x out as timely as possible will allow GNOME developers to start porting sections over. Hopefully, once GNOME compiles cleanly without GTK+ 2.x installed, the real fun can begin as contributors start seeing areas of vast improvement using the new version of GTK+.
Here’s to hoping both the GTK+ folks, and the GNOME folks, can pull off a massive rewrite. Time will tell.
I think I’ll be fine with a rewrite, given that it is done in a clear manner (ie, 3.0 means “done, go use it”, not “yay it’s here!!! no, not done, wait until .2″) and brings out some very favorable features (ie, animations).
What I really wish they could do, that I didn’t include in my posting, was if they co-released gtk 2.x and gtk 3 along with gnome 2.28 in august. Give people a chance to play with it before the final release. I guess we’ll see what happens in the near future.