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?
In short, I think we’ve reached our objectives and should polish GNOME 2 ’til doomsday.
what goals? there are no “goals” defined — except “make a desktop”. for whom? and with what features? whom do we target in terms of preferred audience?
there has been no discussion on this, and we kind of settled in the “do whatever others are doing” routine.
this is obviously wrong.
finally: stagnation means extinction &mash; unless you want to be a living fossil.
That’s exactly my point of view; to me the GNOME desktop has reached rock stability and is the most intuitive UI, but it can still evolve without breaking anything that already exists.
What it now needs is :
– more functionality : continue adding features while keeping GNOME’s famous intuitiveness, eventually through plugins that could be disabled/enabled by the distribution and then by the user.
– more prettiness : enhance the appearance of the desktop, make theme creation more convenient, implement sober and useful compositing, extend panels functionality/customization.
– application polishing : redesign the apps that are part of the gnome desktop but don’t integrate well.
What it doesn’t need :
– fundamentally changing the desktop concept : the semantic desktop, document centric desktop, etc.. sure are sexy concepts, but the casual user will be lost : we need to implement features from these concepts when we feel the user is ready and follow the evolution, instead of thinking that the future of the desktop is THIS concept or THAT concept and break something that already worked for everyone.
think of firefox; they implement useful functionality (awesomebar, tags, phishing filters, ..) but with no major break in terms of user experience. they just enhance it step by step so the user has enough to discover, enjoy and finally adopt them.
GNOME should not wipe its actual user base to create a new desktop that no one would understand. It must learn from parallel projects and implement what would really help users in their daily tasks, and focus on not confusing them.
Emmanuele Bassi:
> what goals? there are no “goals” defined — except “make a desktop”
I agree that we never had an agreement / corporate charter.
I think we put a major emphasis on the HIG. And that implies the objective of building a simple and clean desktop. There is no centralized roadmap, but it’s clearly a consequence of a strategy or Mantra, if you prefer. After all, I think you joined the GNOME development crew since you agreed with this basic intention.
Nevertheless, I like that you are trying to enforce momentum :).
I am a bit surprised that you commented on GNOME, without commenting on GTK+ in particular. Maybe you could briefly sketch how you plan to map the “private” and “protected” concepts into the GObject properties and wrappers?
What is important to me is that the last version of GTK+ 2.x uses the same theming mechanism as GTK+ 3.x. One of the things that really sucked about the GTK+ 1.x to GTK+ 2.x transition is that they used different theming engines and looked totally different from one another. We could make sure old apps integrate so well this time people don’t realize they are using an old version of GTK+ without digging. We could also guaranty that the last version of GTK+ 2.x is present throughout the GTK 3.x and Gnome 3.x life cycle.
“C is ugly as hell and does not support public/procted/private classes”… Time for a C++ version of Gnome??? (just a joke, i’m not a programmer)
I’ve been using Gnome since the 1.4 days, and there is clear to me what Gnome needs. First of all let me explain what I think happens in the Gnome world as a desktop. When Gnome was just 1.4 there was a consensus that there should be a revolution in all the platform, just because people wasn’t happy with it. So, Gnome/Gtk 2.0 was developed. As time passed, Gnome has reached a mature state where there doesn’t seem to be a clear way to go, because basically, Gnome as a desktop just files most of the people needs. But, what should we focus on now, and what is the most lack of Gnome? To my thoughts, what we lack more are applications. We can’t compete with Windows or MacOS just because of this. That gives real power to a desktop. We haven’t any easy way to develop applications, and I see most applications reinventing the wheel just because Gnome/Gtk doesn’t provide real power to the developers to do whatever they want. There isn’t any databinding support on gnome, no real way to make MDI applications, neither a way to make rich UIs, because we lack a canvas, there isn’t even a real gnome integrated web engine (It seems webkit/gtk will provide this, but it isn’t mature enough), gstreamer also isn’t mature enough for making advanced multimedia applications (I heard pitivi somewhere??). What about online applications? libsoup is great, but it’s enough?. There isn’t even any advanced IDE for Gnome (Monodevelop is doing quite well, but we all know the problem with mono). To my though here is where Gnome is losing. Gnome as a desktop it’s great, but as a platform is a mess. There aren’t many people programming for Gnome because people feel it isn’t attractive. GSealed Gtk is a sterile debate, because it doesn’t really push Gnome anywhere. Gnome has always tried to make developers life easier, but does it really make it?
Just my two cents
Just use qt for the next major GNOME version.
I agree. Either break everything and start over in a way that it’s not JUST a desktop environment but a whole platform that works perfectly with the underlying Linux world, or just do evolutionary releases that remain compatible. Breaking Gnome/GTK 3.0, while the desktop and usage paradigm remains largely the same, will anger users because they won’t see these underlying changes, and they will ask themselves: “why the hell did we have to go through the pain of break if all looks the same?”
“… 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.”
Sure. But when the day comes and one of these experimental “fanboy”-driven innovations prove to become the GNOME killer application, you won’t be saying “I made this possible” or “This is based on my work”, because you didn’t – you shifted the responsibility and risk for putting GNOME’s theoretical powers into practice onto someone else.
Your sentiment reminds me of Richard Stallman with his childish “GNU/Linux” crusade (whether thats a compliment or not is for you to decide): deliver half a OS, pray that someone is able to finish what you cooked up and if someone is, claim half credit for their work.
No offense intended.
Okay.
You want to keep maintaining the 2.x series? Great, get on it.
The problem with GTK maintenance right now is that the exposure of internal API has made implementing new features on existing widgets virtually impossible. Any change that would alter that internal API in ABI-changing ways is a no-no. And that means a lot of the changes that developers actually want to see in their widgets – feature improvements and so on – can’t be done, or at least, can’t be done without hacks that make the problem of maintaining GTK exponentially more difficult. Anyone can tell you that getters and setters are a lot simpler to keep compatible than simple members. That’s the raison d’etre for getters and setters in the first place.
Clearly, the people who are currently doing that have enough reason to think that GSEAL is essential that they’re willing to push forward on it. Most of them are pretty knowledgeable about the maintenance problems of GTK+. This is what they want to spend their free (and paid) time on. If you disagree, you’re free to work on GTK+ 2.x, and try to keep it from stagnating and becoming less useful. But you can’t force other people to do the same.
Innovation is not reinvention!
If you innovate you take the current concept and add shine and polish in areas, small adjustments which improve the smooth running of the whole. Innovation changes things but doesn’t change everything, keep what works and improve on what doesn’t.
If you reinvent, you take the old concept/paradigm and throw it away starting something new. Semantic Desktop, Online Desktop, “Computer as a Personal Assistant” WTF?! and all the other hair brained schemes should be put in the bin with the rest of ToPaZ.
We need to innovate, making changes which although subtle improve the way we work…
Anders Feder:
> you shifted the responsibility and risk for putting GNOME’s theoretical powers into practice onto someone else.
I also shift the risk of massively disappointing people with a failed radical concept onto someone else. I have a responsibility for those who expect us to deliver a traditional desktop system.
> (…) pray that someone is able to finish what you cooked up and if someone is, claim half credit for their work.
I’d never do that. However, credit is an important aspect in FOSS world because most of us work for appreciation. Concepts are copied between projects all the time. Remember how Mr. Kaplinski felt so bad because Sodipodi was forked? That’s just a concsequence of FLOSS one has to cope with. After all, we all agreed that we do not use patents to protect our intellectual work.
eosten:
> The problem with GTK maintenance right now is that the exposure of internal API has made implementing new features on existing widgets virtually impossible.
That’s an interesting aspect. Actually, I never noticed this when looking though bugzilla. Maybe you could give a few examples?
Karl, you’re drawing an artificial distinction there. Something completely different can be innovative, as can an improvement to something we already have.
Christian, exposing struct fields is not the same as exposing getters and setters – if the struct fields are hidden away, they can be removed, changed, turned inside-out, and as long as the getters and setters which are exposed still function in the same way (whether they now simulate it by the setting of four new internal variables or by doing something else entirely), the user code doesn’t have to care. That’s what’s called encapsulation, and is one of the greatest benefits of object-oriented programming.
It is unfortunate that GTK+ is implemented in a language which doesn’t support these concepts natively, but it is even more unfortunate that people ever felt the need to use the struct fields directly in the first place. Even without GSEAL() or other means to simulate private data, there should have been no need to talk to objects in any way other than through their methods. That way the position could be taken – as Perl programmers accept – that although the internals of the objects are there for all to see, messing with them directly is not supported and if you do it, don’t blame us if it breaks when we release a new version.
Of course, GTK+ has to live with that historical baggage now. Breaking API is the only time it can be fixed, but breaking API just to fix it is clearly an unpopular solution. It’s not going to be accepted by everybody unless it can be shown that an API break will allow an enormous, obvious and immediate improvement.
Karl Lattimer:
> Innovation is not reinvention!
Yes, you are right. When writing the article, I was under the impression of recent discussions about novelity in science world. I agree with your points.
I don’t have any on me (and I’m actually on vacation now) but here’s a hypothetical case; let’s say there’s a desire to eliminate the GdkWindow-per-widget (perhaps to create Havoc’s scene graph or whatever). Right now the GtkWidget struct has a window member window that can’t be changed, preventing any work there. If it were encapsulated in a getter/setter, it would be much easier to eliminate the need for GdkWindow without causing horrible breakage.
This is the same for basically every struct field – take the GtkStyle style struct, or any number of others. None of these can ever be replaced as it stands, or substantially modified, because there’s no way to encapsulate them. That’s what GSEAL fixes.
cneumair:
“I also shift the risk of massively disappointing people with a failed radical concept onto someone else. I have a responsibility for those who expect us to deliver a traditional desktop system.”
Definitely. I agree those responsibilities should generally come first. But it’s no reason to alienate those who work to keep GNOME up with the competition in terms of new technology.
Karl Lattimer:
“If you reinvent, you take the old concept/paradigm and throw it away starting something new. Semantic Desktop, Online Desktop, “Computer as a Personal Assistant” WTF?! and all the other hair brained schemes should be put in the bin with the rest of ToPaZ.”
Actually, I have not heard one single proponent of any of those ideas suggest throwing away the existing paradigm or calling for API breakage. Which exact proposal are you actually referring to here? Or are you just taking stabs at random projects to make a point about something entirely unrelated?
I was making a stab at all the crazy that came out of the woodwork around topaz. The future shouldn’t be particularly radical, but we need to be innovative about what we do.
Karl Lattimer:
There was radical ideas around ToPaZ (there always is in any development community), but that is no reason to ridicule the not-so-radical projects which specifically make an effort to innovate by building on what we already have and not by throwing away the existing paradigm? At least to me that seems highly counter-intuitive.
Please take a little care not to let your anti-disruption sentiment turn into anti-progress sentiment.