Plans for Gtk+/GNOME 3.0 surfaced

At the GNOME conference GUADEC plans were presented how the transition to the new Gtk and GNOME is supposed to happen. The basic idea is to make the transition as smooth as possible by first cleaning up everything and introducing new concepts later on.

The news flash came right from GUADEC today: there will be a GNOME 3.0, and it will break the libs. Most news sites picked that up, but unfortunately there are hardly any further information out there.
A notable exception is the Austrian which covered the topic with a bit more details.

Basically the main aim for Gtk+ 3.0 is to clean up everything. Old/Not anymore needed functions will be dropped. The current state of this cleaning is tracked at the GNOME wiki. New features are planned for versions coming afterwards. This will of course include ABI/API brakes, but an aim is to make such a transition smooth. Well, it would be surprising if it wouldn’t 😉 One notable idea though is to flag all dropped functions as “deprecated” in an upcoming GTK+ 2.x release.

The GNOME release team also plans to drop unnecessary/old code and to clean up the code base, and again the plan is to make this transition as smooth as possible. Additionally, it is planned to come up with a two-sided release schedule: there will be a release every six months, but there will also be long time rhythm for larger aims and features.

These aims sound and ideas sound reasonable – and do remind of course of the KDE 4 process. I do hope for the GNOME team that they had a close look at the KDE 4 process and learned from it: many things worked out surprisingly well, some things didn’t, and they can copy the first and learn from the second, why not.
I must admit though that I wonder how the “first-clean” idea can be realized – at least for KDE that would not have worked. Or said different: where such an approach was used it was also strongly criticized. The best example here is probably the KDE-PIM suite: as part of KDE, it was cleaned and will be introduced first again with KDE 4.1. Many people missed it heavily, although of course it was made sure that KDE-PIM-3 worked perfectly well with KDE 3, so a smooth transition is indeed possible. With the plasma panel a simple version of a panel was introduced to build upon, and again there have been many critics.
Also, sometimes straight cuts are necessary – think of arts->Phonon here.

Anyway, in the end GNOME is a quite different project compared to KDE, so it is difficult to compare both. But they will face some similar problems, and so it would not be the worst idea to see and learn from the KDE experiences. It’s always easier if something is done a second time because you have the experience from the first run, but good luck nevertheless! 🙂

8 thoughts on “Plans for Gtk+/GNOME 3.0 surfaced”

  1. It could not work for KDE 4 because Qt 4 was a majour step.
    If GTK+ goes it smooth GNOME can do the same.

  2. The plans for Gnome 3 feel less like a radical break in the product and more of a realisation that so much change and time has passed since Gnome 2.0 that Gnome 3.0 is in order.

    KDE4 seemed more exciting as it was a very large leap and represented a major overhaul on the KDE front (imo doing very well)

    OK I’ll admit I’m not a huge fan of Gnome but give it a try every once and a while but Gnome3 doesn’t feel quite as exciting.
    However GTK3 sounds like it will offer a lot more for a lot less in the future which would be interesting to see.

    Glad to say that I’m looking forward to Gnome3 sooner the better as always 😀

  3. It isn’t mentionned but GNOME 3 will be actually 2.30 and so it will be out in 2010… I can’t imagine how great will be KDE 4 at that time !

  4. I’m wondering how long the intention to go smooth will last, I tried this when I started on kword2 and quickly realized that I would be unable to introduce any new concepts without breaking everything anyway. So I ended up starting clean and reusing code by copying it from a backup.

    Lets see how the gtk devs fare 🙂

  5. > Also, sometimes straight cuts are necessary – think of arts->Phonon here.

    This has been done oftentimes inside GNOME using a pretty successful model. That is: We code a replacement technology and port our application/library stack to use the new technology as fast as possible. Then we maintain the old code as deprecated. So it’s nice to have certain points where we can drop it.

    – gnome-vfs => gvfs
    – libgnomeprint(ui) => cairo/gtk
    – Corba => DBus

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.