Gnome 2.0 RC1

lurgyman writes "The GNOME Desktop 2.0 release candidate 1 has been released! It looks like it's finally on schedule for its projected June 21 release." The release notes have some good information.

Comments

Re:Can it compete with KDE?

[IamTheRealMike]

Asking .... will KDE vanquish GNOME, or "which will win the desktop environment wars" is the wrong question. It's like asking "Which will win, Ford or Vauxhall?". I wouldn't be surprised if a decade from now, KDE and GNOME are still around, still with plenty of happy users. I think KDE will be loved more by those who came from Windows and are most happy with a Windows style desktop environment (which is in fact quite a good design, MS bashing aside).

I think GNOME should start to differentiate itself in some way, and I expect we'll start seeing them diverge somewhat as GNOME realise they can't out-KDE KDE, and instead try and do their own thing.

Differences appear minor

[Outland Traveller]

I'm not sure what you mean when you ask "Can Gnome compete with KDE"?

I've installed both KDE-based systems and Gnome-Based systems and shown them to Linux newbies- everyone from relatives to co-workers (caveat: I work in an engineering dept.)

After spending a few hours playing around with each one, my personal experience is that Gnome is their preferred choice, apparently because the icons and screen widgets look better, the interface appears simpler, and most of the engineers like the graphical virtual desktop manager on the gnome panel as opposed to the KDE version.

Granted, I use Gnome a lot and there are some deficiencies.. Nautilus is very slow. Sawfish has focus problems. The panel can behave in unexpected ways. The library dependencies for applications like Evolution are scary, but it generally works well and many people use Gnome as their full time desktop.

It looks to me like KDE may be slightly more stable, and may be easier to program for. Still, the differences between gnome and KDE from a user's point of view do not seem so great that you can call one "high level" and the other "mid level". They both look high level to me.

So, does someone want to try to explain the qualitative user-experience differences between KDE and Gnome, or is it as I suspect very minor?

Re:Differences appear minor

[akeru]

Wow, do I have to disagree about the development standpoint here. Sure the dependencies can be a pain, but that's where the beauty and flexibility of autoconf/automake and pkg-config make life easy again. The additional modularity granted by separating different functions into their own libraries far outweighs the additional overhead of a lot of dependencies. Having watched GNOME and KDE development closely since before the 1.0 KDE and 0.3.0 very unstable "technology preview" GNOME I can say the essential difference between the two projects is that KDE is focused on "doing it now" and GNOME cares more about "doing it right" than they do about timelines. And it shows. KDE has caused me nothing but problems, and, from a systems administration standpoint, is a real PITA. GNOME, on the other hand, has continually tried to integrate and play nice with existing standards and conventions, which means that, among other things, configuration files are in /etc and everything else is where it is "supposed" to be.

And while you may prefer C++ to C (and for good reason too), the decision to use plain old C for GTK2 was, IMHO, a good one. In so doing you enable the maximum flexibility and, when done right (as GTK2 is, for the most part) makes writing language bindings (almost) trivial. I can't say for QT, but GTK/Glib 2 allow for complete run-time introspection of types, parameters, etc. in a very clean manner. By doing the base object-system in C with a clean API, it allows binding authors and programmers in general, a way to write to the underlying library in a way that fits in naturally with the language they are using to write it. Rather than using moc hacks or other ugliness, you get clean, standard, C (which may be, IYHO, ugly, but it is standard C, which most compilers support at this point in history -- excluding C99 -- which cannot be said for either C++ or the C++ derivitive used by Qt/KDE). Say what you will about C the language, but using it to implement the object system was a good idea, the additional complexity involved in coding for it is minimal and a the code, in large part, for creating a GObject subclass is largely boilerplate anyway which can be scripted or wrapped by something like 'gob'
Everytime I've looked at Qt/KDE development I've been struck with just how . . . unwieldy and inflexsible it is.

The differences in attitude ("let's do it now and invent some new, quasi-documented, way of doing it" vs. "is there a standard way to do this and how should we do it RIGHT") are behind most of the differences in toolkit and, more importantly, time line. GTK2 took a long time to get out, because a lot of thought and planning when into it. Whether this was actually the case with KDE2/3 as well or not, I can't tell, but it certainly doesn't look like or feel like it.

--Shahms