Linked by Thom Holwerda on Wed 11th Jun 2008 08:14 UTC
Gnome 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?
Thread beginning with comment 318205
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Not buying it
by OlympicSoftworks on Wed 11th Jun 2008 18:45 UTC in reply to "RE[2]: Not buying it"
OlympicSoftworks
Member since:
2008-06-11

Ok, lets look at the funcionality that underlies the two things you mention. Quicklook. In order for this to work an engine that understands how to use the various file types needs to be loaded at all times. This is bloat.

While it may be nice to have a switch for an 'enhanced mode' for beefy machines that have the extra memory they want to dedicate to fluff like this but it would likely get limited tracktion and therefore limited use and therefore limited devs working on it. There are lots of nice ideas that Apple can implement because they sold you the hardware you are running the software on and can therefore expect you to have the resources to allow implementation of fluff like this.

Part of my organization's efforts is recylcing older computers to give to homes that can't afford a new machine. We use of course GNU/Linux, Ubuntu specifically, and we give weekly training meetings to help retrain folks to use their new computers. Many if not most of these machines are slower and don't have robust memory or hard drive space, they run GNU/Linux quite well would choke on this kind of added burden.

And for Expose it's funcionality seems to be present in
Compiz/Fusion. Granted it took a while to make it to our neck of the woods, mainly because of video driver quality lagging for so long. That is no longer a concern however as we have enough purchasing power to entice the hardware guys to work with us now. I noticed this on wikipedia when I looked up Expose:

>Exposé makes extensive use of undocumented features of the Core Graphics framework.

So typical of proprietary offerings, I guess even Apple is not above this.

These features are kinda cool. I myself don't use Compiz/Fusion even though my machine is more then capable, GNU/Linux has had for a very long time now the idea of virtual desktops. I pretty much organize my work onto several of these and life is good.

Reply Parent Score: 2

RE[4]: Not buying it
by MORB on Thu 12th Jun 2008 15:25 in reply to "RE[3]: Not buying it"
MORB Member since:
2005-07-06

Ok, lets look at the funcionality that underlies the two things you mention. Quicklook. In order for this to work an engine that understands how to use the various file types needs to be loaded at all times. This is bloat.


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.

Reply Parent Score: 5

RE[5]: Not buying it
by OlympicSoftworks on Thu 12th Jun 2008 17:19 in reply to "RE[4]: Not buying it"
OlympicSoftworks 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.

Reply Parent Score: 3