The KDE project saw the writing on the wall. They saw that they had reached a certain limit when it came to what could be done with the KDE 3.x series - they named it the "big friggin' wall", and decided that in order to get over that wall, incremental updates wouldn't do - they needed massive changes, a big jump, and they went for it. It's been a rough road, but it seems as if KDE 4.1 is showing signs of the vision becoming a reality. And it now seems as if several people within the GNOME community are seeing the writing on the wall too: GNOME 2.x has reached its goal - now what?
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2008-06-11
Granted, if written correctly things like these can be pushed out to the swap and take up space there instead. It's still bloat. Features like Quicklook, and hovering over a music file to play it are really something that needs to be thought about twice before implementing into a profissional desktop interface imho. They create more code that is rarely used and simply offers more maintenance time to keep working for limited returns.
Gnome is liked by those that like it because it is very straightforward and easy to use. Nothing ambiguous about it. I personally use it simply for the fact that it is more stable then KDE in my use, part of that is the fact that there is so much that KDE does it makes maintenance all that much more of an issue. I personally like the way KDE handles multiple monitors much better then the GNOME way, but I have gotten into the habit of the virtual desktops now and I get the same funcionality that way for the moment.
If Gnome is to grow, it should grow in usefull ways that enhance what it does best; offer a clean looking visual environment that doesn't get in anybodies way. Adding better support for multiple monitors and/or viewports is good, but that is all back end stuff.
And your point of how the something as modern as GNOME is written in plain C is very well taken, and is really what I think the crux of the matter is here for most of these folks posting. It is more difficult to add a feature to GNOME directly, or write an app with GTK then it needs to be. And with precious volunteer dev time being spent working around coding issues, it's no wonder adding things is slow going.
If an revolution is to occur, a fork to take the GNOME codebase fully into C++ would be a worthy project and the best way to move forward. A year later and the ap could be fully re-written. Once something is working it pretty much just keeps working in true OO languages, that is why they are used.
Member since:
2005-07-06
No, it isn't. If it's never queried or accessed most of the time, it'll just be swapped away on the harddisk.
As for why gnome fails from a development point of view, well, it's built on gtk and glib, which are horrible c-based implementations of oo-programming and containers, using macros and all kind of other disgusting shit.
This is bound to make for some shaky, pointlessly complicated and difficult to maintain foundations.
Before some clown tells me that the end result is the same and that it's a matter of taste, it's not.
There's no notion of type safety in C, there's no notion of scoped resource allocation (which forces you to write redundant cleanup code for all exit path of your functions, which mean that you can get it wrong, omit stuff etc), and you essentially have to learn a bunch of gtk-specific idioms to accomplish things that can be expressed in a standardized way in other languages.
There no single good reason to do OO programming with a non-OO language in this day and age.
It's just unecessary complication, and unecessary complexity is the enemy of efficiency and ease of maintenance.
The "language bindings are easier to write for c" argument is quite bogus as well, as demonstrated by the amount of bindings existing for Qt and KDE.