GNOME and KDE priorities [LWN.net]

February 3, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

With the KDE 3.4 and GNOME 2.10 releases on the horizon, we decided to take a look at both projects to see where both desktop teams were focusing their efforts. To get a feel for the priorities of each team, this reporter "test drove" the KDE 3.4 beta 1 using the SUSE 9.2 packages and GNOME 2.9.4 with Ubuntu's Live CD. We also spoke to KDE core developer Zack Rusin about the 3.4 release and GNOME release team member Luis Villa about GNOME's 2.10 release.

Both KDE 3.4 and GNOME 2.10 are incremental releases. That is to say, neither desktop is undergoing dramatic changes in the upcoming release and casual users may not notice many changes. Instead, there are a number of small improvements and enhancements to the current desktop that users will find in each release.

Both projects are concentrating on backward compatibility. KDE's Rusin said that the 3.x series is basically in "maintenance" mode, with the KDE team trying to add features that users want, without major changes that would compromise compatibility with older releases. He noted that one of the goals for the 3.4 release is to maintain binary compatibility with the earlier 3.x releases. GNOME's Villa said that the GTK core toolkit has a strict ABI/API compatibility policy. "If you build against GTK 2.0, you should be able to run against GTK 2.6 with no problems." He also said that other core GNOME libraries provide the same guarantee, "that's why we have Firefox and Eclipse building against us."

According to Villa, the 2.10 release will see more bugfixes than usual. He said that, depending on how you track bugs, the 2.10 release already includes between 1,000 and 5,000 closed bugs -- and that's before the final feature freezes and bug fixing before the final release. Villa did note that the GNOME team always places a high priority on quality control, but that this release seemed to have a higher than normal number of bugfixes.

Another focus for the GNOME team in 2.10 is implementation of freedesktop.org standards agreed upon by the GNOME and KDE teams. Villa noted that the GNOME team had revamped the menu structure to comply with the freedesktop.org menu specification.

The GNOME release adds a new "Places" menu to the panel that allows the user to quickly navigate between their home folder, the desktop, CD-ROM and network locations. Villa said that the GNOME team has also addressed some of the complaints about the file chooser from the last version of GNOME, and that the typeahead feature has returned.

Both desktops are increasingly friendly for users with disabilities. Villa said that the 2.10 release did not focus on improvements to accessibility because GNOME is "already far and away the leaders in accessiblity."

The KDE team, on the other hand, has made accessibility a major priority in 3.4. One major new feature that users will find in 3.4 is the text to speech system in 3.4, which would be available in many applications. Rusin said there is also a new "mono" theme for 3.4 that would be better for users who had difficulty with the high-color styles used in KDE. Rusin noted that working on accessibility was difficult because it is "such a hugely complicated area," and that the KDE team will continue to add functionality in future releases.

Multimedia has also gotten a boost in GNOME 2.10. According to Villa, the Gstreamer integration is greatly improved in GNOME 2.10. This is the first release where Totem has been integrated into the GNOME release process, and Villa also said it was the first release where the Totem team had worked more closely with the Gstreamer team. Totem had previously worked with Xine, but Villa said that Xine had "legal encumbrances" that made it more difficult for vendors to distribute. There is also a new and improved mixer applet in GNOME 2.10 that hides some of the complexity from the user, at least at first. Villa said users would still be able to get to all of the functionality of their sound card with the mixer, but wouldn't be presented with it at first glance.

Both KDE and GNOME teams have been beefing up their groupware offerings. Rusin told LWN that KDE PIM had been "hugely improved" for 3.4. Kontact has expanded its support of GroupWare servers with support for Novell GroupWise and OpenGroupware.org, and partial support for Microsoft Exchange Server 2000. Kontact also supports OpenExchange Server, eGroupWare and Kolab.

Evolution's latest release includes eplugin, a plugin architecture to allow developers to extend Evolution with new features. Some of the plugins available now include an inline audio player for Evolution, an Exchange account setup plugin and an "automatic contacts" plugin that creates address book entries when a user replies to e-mails. Evolution already includes the Exchange plugin, and Villa said that Evolution was also getting a lot of work to be compatible with Novell GroupWise.

KDE 3.4 marks the first inclusion of aKregator, a feed aggregator for KDE. This writer found aKregator very easy to use, and its integration with Konqueror and Kontact makes it a great choice for KDE users. The KDE team has also beefed up KPDF to include support for the text-to-speech features.

From talking to developers on both teams, it's clear that both desktops are trying to move towards better "enterprise" capability, and making it easier for others to develop applications for the respective desktops. From using both, it's clear to this writer that GNOME and KDE view users differently. GNOME continues to move towards a simple end-user interface, while KDE is more about adding features that users want -- even if it increases complexity.

Users who want to try out GNOME 2.10, without the hassle of compiling GNOME or installing it, should look to the Ubuntu Live CD for the upcoming Hoary Hedgehog release. Rusin said he wasn't aware of any Live CDs with KDE 3.4 beta just yet, but something might pop up on the Knoppix lists.

(Log in to post comments)

GNOME and KDE priorities

Posted Feb 3, 2005 14:16 UTC (Thu) by niran (guest, #27560) [Link]

I think what you're proposing has quite a few more "stupid user interface problems" than Totem does. Contrary to what you've stated, buttons do cost something in software: more buttons clutter the user interface and make the program harder to use. How often do you need to go back exactly five minutes? I'm guessing not that often. The slider provides enough control for most use cases. Instead of trying to go back exactly five minutes, why not drag the slider back a bit? Every once in a while you might need to go to an exact minute:second point in a video, but the sacrifice in simplicity isn't worth it for something that can be done with reasonable accuracy with the slider.

GNOME and KDE priorities

Posted Feb 3, 2005 15:39 UTC (Thu) by rwmj (subscriber, #5474) [Link]

Actually, going back 5 minutes is useful for me since
I tend to watch DVDs in small parts (while exercising),
but I take your point that it may not be for everyone.

So let's look at the rewind issue in general. On Apple's
DVD player, rewinding happens at a constant rate (say,
2x or 16x), but to set this rate you have to go through
an awkward two-level menu. On my real DVD player, rewind
begins slowly and gets faster the longer you hold the button
down. On my PVR, you press the button multiple times
to go 2x, 4x, 6x ... faster.

None of these interfaces is especially smart. The Apple
one is the most annoying, but even the PVR interface
(which I like best of them) still makes it hard to go
from fast rewind to slow forward, which is an obvious
thing to want to do (think about when you "overshoot").

In this case, multiple buttons makes an awful lot of sense,
something like:

[Rewind slow] [Forward slow]
[Rewind fast] [Forward fast]

(I only ever want to go slowly or quickly; going at
intermediate speeds is never really useful).

This still doesn't solve the "how do I get to a particular
point on the disk", or "how do I go back 5 minutes", but
if the time counter was a simple entry form which could
be modified by typing in numbers, that would solve all of
those problems and more.

Rich.

GNOME and KDE priorities

Posted Feb 3, 2005 15:44 UTC (Thu) by rwmj (subscriber, #5474) [Link]

Oh, and the other really really stupid thing about
Apple's rewind mechanism, is that it's time sensitive.
Press the button quickly, and it goes back a chapter.
Hold down the button and it starts to rewind.

Time sensitive buttons are a usability no-no, and
bad from an accessibility point too (although Apple's
DVD player has so many other accessibility problems,
that one extra hardly matters).

Why couldn't they just have had a separate button for
"go back a chapter"?

Rich.

GNOME and KDE priorities

Posted Feb 3, 2005 22:09 UTC (Thu) by amarjan (guest, #25108) [Link]

Streaming media is, I think, where exact positioning is most required. If you're listening to a 2 hour lecture, for instance, and want to go back 10 seconds because you've missed the last sentence, well good luck using the slider with "reasonable accuracy". The longer the stream, the harder it is to make such small adjustments because the slider is fixed-width, so it loses precision.

Lectures tend to be recorded rather shoddily, so small adjustments are frequently required.

GNOME and KDE priorities

Posted Feb 3, 2005 14:24 UTC (Thu) by Frej (subscriber, #4165) [Link]

Button's do have a cost, complexity. ;)

I actually agree i would be nice to have a more precise way of 'goto', since today you keep fidling arround with the slider.

There is the Go->'Skip to' menu item, But it doesn't seem to work? (totem 0.101, ogg vorbis)

It isnt 100% copy of hardware players, there is no stop button, just pause.