Since everybody nowadays comments on the future of GNOME/GTK+, I’d also like to add my two cents – although more briefly than others.

In short, I think we’ve reached our objectives and should polish GNOME 2 ’til doomsday.

3.0? No!

As of writing, I see no reason for delivering a (long-term) API/ABI-incompatible GNOME 3.0 or GTK+ 3.0, and many have written the same before. I’m just repeating it here to make sure that everybody, including the kind-hearted individuals who try to force a GSEAL’ed GTK+ to make it more clean, are aware of the massive opposition against this plan.

C is ugly as hell and does not support public/procted/private classes. Therefore, no C programmer can really mind ugly exposed internals. Adding setters and getters is a in principle a good idea, but there is no reason to break working applications that access data exposed in GTK+ structs. Maybe a GSEAL() fan could tell me how third-party subclasses that are derived from GTK+ stock widgets can access protected member variables? If you just expose getter/setter functions, everybody can access the internals, and you could have put it into the object’s struct anyway.

Status Quo: Conservative + Boring

The current GNOME and GTK+ development clearly “stalls” or “stagnates”. From the point of a developer this sounds horrible. However, you could also formulate that positively and call it “solid”. We’ve come a long way. Since GNOME 2.0, our target was to deliver a non-obtrusive, simple and useful desktop environment. We’ve done our best, and people love it. I know many people who use GNOME because it’s simple and clean.

Radical Concepts => New Project

We created a successful brand by radically sticking to one strategy: Simplicity. The current traditional desktop approach without any fancy database concepts is very successful and is used by many people.

The brand will be damaged if we throw in half-baked complex interaction concepts. Like many of you my dear readers, I love the idea to use the computer as a personal assistant or secretary, and I’ve also thought how it could work in such a scenario. However, at least radical concepts (“GNOME Online Desktop”, “everything is organized as database”, etc.) should clearly be put forward outside the GNOME project, at least until they are mature and proven in a testing environment with average people instead of “innovation” fanboys. “Innovation”, after all, is just a buzzword, and in science they often just re-invent old concepts. I’m sure that the scientists among you will agree with this.

It may sound a bit disappointing that we’ve become conservative, but that’s the typical life cycle of people in western civilization, why shouldn’t it also apply to software projects with well-defined objectives?

I’d walk around and tell people to find more useful projects than wasting their time with adding tabs to each single GNOME application. Maybe the semmingly true rumors that one or another GNOME fellow might be somewhat lunatic (panties, anybody?) inspired theprogrammers who are implementing this.

One initial aspect: Calumn is totally right that tab implementations at application level are an effect of the lack of platform MDI support. We implement it at application level where we need solutions today and tomorrow, rather than the day after tomorrow. However, it is not yet clear whether tabs are useful at all for 90% of the applications.

Why tabs for Nautilus (and web browsers, spreadsheet, …) are a good idea

Let me briefly explain why I added tab support to Nautilus: It helps people with their workflow. Today, I used it to tidy up my document folders. I could use it to navigate between file operation source and destination folders extremely quickly, using the keyboard and ctrl-x, ctrl-v, and ctrl-page-up/down. I was two times as fast as with a console (where you need auto-completion), and five times as fast as with a mouse

Tab support for browser-like file managers is a good idea, because people know how to use the tab concept properly since it has been invented for web browser. It is also useful for spreadsheets, where you often compare multiple documents and calculations. It is also useful for having multiple conversations at once, because each of them is linear, and you can use the tabs to switch between losely-associated linear tasks or documents.

Why tabs for media players are a bad idea

On the other hand, tab support in Totem is ridiculous. Somebody must have put LSD into the GUADEC social event food, and everybody now feels like Syd Barrett and his Lucifer Cat!

Regarding Totem: It is already perfectly doing what it should do: Play a song or video, and let me queue more of them. One song or video at once. How can I watch two videos at once?

Why you should think first, and implement features afterwards (i.e. gcalctool tabs)!

Let me exemplify this regarding gcalctool:

Even my non-programmable pocket calculator (Casio FX-991ES) has more features than this non-noticeable desktop calculator. Amongst others, it can not deal with symbolic calculations, complex numbers, nature constants, variables. It does not even have a calculation history as I mentioned in a comment in Scott James’ blog. This is a shame! Before you implement such a craptastic feature, think about how it will be used! Again: gcalctool does not have any calculation history. This is as if I implemented tabs in Nautilus without implementing the back/forward button before, so you had to switch to a new tab each time you want to display a new folder.

Now I’ll do something useful and learn for my function theory exam.

You talented developers at GUADEC should also do something useful and fix the GTK+ tree view mouse interaction.

All-Clear :o)

It turns out that the tab implementations were just mockups. Have fun at GUADEC!