Please take a little care not to let your anti-disruption sentiment turn into anti-progress sentiment.

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?

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.

> 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.

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.

> 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?

> 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.

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…

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.