User: Password:
|
|
Subscribe / Log in / New account

The GNOME project at 15

The GNOME project at 15

Posted Aug 16, 2012 22:33 UTC (Thu) by hp (subscriber, #5220)
In reply to: The GNOME project at 15 by jmspeex
Parent article: The GNOME project at 15

Also of course, my first post on this article says why I don't think "GNOME should learn from GNOME 2" is right. Unless you think the main goal of GNOME 2 should have been to avoid flames. GNOME 2 became much more popular than many desktops that did _not_ get flamed (as much). Taking a lesson away from GNOME 2 like "we shouldn't change stuff" or "regressions are never good" would be historically wrong, because either of those lessons would have doomed GNOME during 1.x -> 2.x. Knee-jerk "CADT bad" would have doomed GNOME too. Truly targeting mainstream users instead of Linux users would have doomed it too. There are lots of ways GNOME 2 could have gone wrong. But flames were non-fatal.

It doesn't mean that if you're getting flamed you're going to succeed, but it does mean that you _might_ be right to do something that gets you flamed. You also might _not_ be right. That's the hard part. One needs to figure it out.


(Log in to post comments)

The GNOME project at 15

Posted Aug 17, 2012 0:38 UTC (Fri) by jmspeex (subscriber, #51639) [Link]

It seems like you're assuming that software cannot change without a rewrite. Just look at the Linux kernel and compare what it was at the time of 1.0 vs 3.0. The two versions have nothing in common. Yet, nobody ever started a rewrite of the kernel and the only regressions that occurred were either unintentional (i.e. bugs happen no matter what) or were about hardware stopped using 10 years earlier. It's been an evolution and that's how you keep your users happy. It took years for gnome2 to re-implement many of the features that gnome1 had. Some It's not clear to me whether these features were always meant to be re-implemented or were only re-implemented because of angry users, but the bottom line is that for gnome2, "change" resulted in several years of being stuck with something worse. Not to mention that gnome1 had stopped improving long before gnome2 was out. So far, gnome3 appears to be the same. gnome2 development slowed down long before the gnome3 release and developers are still re-implementing features that were "lost" in the rewrite (again don't know how much is from "it took time" vs "we changed our mind and re-implemented the feature").

The bottom line is that this development method (and KDE is just as guilty as gnome) leads to long periods where the software is much worse than it should be. So by "learn from gnome2" I meant "learn to avoid these long periods of regression". I now realize that "it's a feature" and that even if gnome3 ever becomes as usable for me as gnome2 was before the "rewrite", it would only be temporary because by the time it works for me, all developers will have moved to gnome4, which will break the features I use.

I especially don't see how it needs to be that way. You can implement a gnome-shell like feature on top of gnome2 and make it optional (or even by default, I don't care). You can make the wm evolve without breaking everything. And more importantly, you don't have to make all these changes at once and you don't have to ditch the old behaviour. This means 1) people have time to get used to the changes when they like it 2) there's a chance to react when you're going in the wrong direction, and 3) you avoid bad regressions.

The GNOME project at 15

Posted Aug 17, 2012 1:43 UTC (Fri) by hp (subscriber, #5220) [Link]

It sounds good, but if it were that simple... There's something hard about it. Nobody is just trying to piss people off.

If nothing else: there are very few developers doing quite a lot.

I don't think the kernel is directly comparable; one reason is 100x more developers, but another reason is that evolving UI is a different problem from evolving code. GNOME 2 to 3 evolved the _code_ quite gradually and smoothly with no big rewrite.

I'm trying to think of examples of UIs that gradually evolved between two pretty different states like GNOME 2 and 3, and having trouble. But maybe there are some interesting ones out there. I guess Apple is currently doing some sort of make-OS-X-more-like-iOS-in-each-release thing according to the media but I haven't tried it out myself.

The GNOME project at 15

Posted Aug 17, 2012 5:44 UTC (Fri) by jmspeex (subscriber, #51639) [Link]

I understand that developers aren't *intentionally* pissing people off and it's just a side effect of something else. Also, I understand that making code evolve isn't easy, but rewrites tend to be even worse -- even if it looks simpler because "hey now I can understand all the code". UI or not, I can't think of any project (though there may be a handful) that really benefited from a rewrite. The only viable way I can see is when you have the resources to keep maintaining the old version until the rewrite is not only released, but achieves feature parity with the (still evolving) old version. This is what Microsoft did with NT and I'm sure it wasn't cheap.

In the end, I think the problem isn't even just for users, but for developers as well. From 1999 to ~2005, I wrote and maintained an application that had a gnome front-end. All I can say is that it was a rather painful experience. The API itself was OK (except for being C rather than C++, but I could deal with that) and it didn't take too long to get something working. The real problems came with maintaining the code with ever-changing APIs. Part of that was the gnome2 transition, which not only changed how some widgets behaved (it's OK for a major release), but also completely removed some widgets (GnomeMDI for example, which was supposed to be "the right way"). Even after the transition, APIs would keep coming and going. Oh, we're no longer supposed to use the gnome canvas, there's something new instead. Need graphs? Use GtkPlot, no use Guppi, oh wait we rewrote it and Guppi2 is much better, no but Guppi3 will be... You would never know which API you could trust to not end up being deprecated in 6 months. I stopped being involved around in that project around 2005, at which point the other main developer was working on a Qt frontend. (I still work on FOSS, but fortunately I haven't have to work with GUIs since then)

The GNOME project at 15

Posted Aug 17, 2012 6:54 UTC (Fri) by hp (subscriber, #5220) [Link]

That sort of code and API sanity (avoid giant rewrites, keep the API stable) is far, far better these days than back then.

In OSS one can only do so much. The libgnomeui/GnomeMDI stuff took a long time to reach consensus. So for example, in January 2001 I was apparently telling people not to use it:
https://mail.gnome.org/archives/gnome-devel-list/2001-Jan...
But, someone else would have told you to use it at that time.
It just depended on who you asked. There wasn't a dictator to decide.

There's more consensus/process/cultural-norm now than there used to be.
For example, a list of "official" API: http://developer.gnome.org/platform-overview/stable/

I was surprised by it just now, but libgnomeui appears to still be on my Fedora 17 system. So the ABI remains to this day.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds