For the upcoming release of Red Hat Linux, we decided to configure both desktop environments we ship, KDE and GNOME, to look and behave in similar fashion. Our goals were to improve the user experience and to reduce work for ourselves. This decision has gained quite a bit of attention, some positive, some negative. My intent here is to explain what we are doing, why we doing it, and with luck, dispel some rumors that have sprung up around the project.
What are we doing? The changes in the desktop area for the next version of Red Hat Linux involve three major pieces:
We've developed a set of artwork in-house to use for the desktops as well as for other pieces of the distribution. This set of artwork, the Bluecurve look, includes, among other things, desktop backgrounds, widget themes, window border themes, and icons.
We've configured the default settings and application shortcuts for both desktops in a similar fashion.
In a few places where we feel that there are significant advantages to sharing underlying technology between the desktops, we've made code modifications to use this technology. An examples of this is modifying both desktops to use Xft2 and fontconfig for font rendering.
So, why are we making these changes? First off, the desktop is one piece of a larger Red Hat Linux product. Other components range from our configuration tools, to the applications we include, to our website, to the box that Red Hat Linux comes in. We believe that all of these components should look and behave consistently.
Creating two sets of configuration tools, two websites, and two boxes isn't feasible or desirable. So we have to make the desktop fit in with the rest of the product instead of making the rest of the product fit in with the desktop.
The second reason for adopting similar configurations for the two desktops is to reduce our integration work. When we ship a desktop, we need to integrate in our configuration tools, services such as Red Hat Network, and our recommended set of applications. If we start from two distinct upstream default configurations, then this job becomes two entirely different designs, instead of just two implementations of a single design.
Sharing a similar setup between the two desktops also significantly reduces our documentation work.
The third reason for the shared configuration is that we believe that we should take responsibility for the default preference settings and application shortcuts that a user sees. We're doing something wrong if a user is choosing between logging into GNOME or KDE because:
There is an application available in one and not in the other.
If an application is useful, we should make it available in both desktops.
The user likes the way a preference is set in one better than it is set in the other. Examples of such preference settings include such options as font choice, single-click versus double-click for desktop icons, and the default set of panel applets.
If we have an opinion on what is the better choice is for a particular setting, it would be irresponsible for us not to configure both desktops that way. If we don't have an opinion, it still doesn't make sense to configure one desktop one way, the other the other way; it just means that we won't get good feedback on the issue from our users.
In particular, offering two different default configurations isn't an effective means of providing choice for users. It is unlikely that a user's opinions on all applications and preference settings will align with one desktop or the other.
A final reason for configuring the two desktops in a similar fashion is that it allows us to increase the integration within each desktop.
We expect that most of our users will be using a heterogeneous set of applications, including, among other things:
If all these apps look and act the same way, then we have created a more pleasant user experience. Ideally, all the relevant parts of the configuration would be exported from the desktop the application via something like the XSETTINGS mechanism. (http://www.freedesktop.org/standards/xsettings.html) But nothing like that is yet widely deployed. So, for now, the most effective way of achieving integration is to simply synchronize the default configurations.
Before going on to explore some legitimate downsides of our strategy, it is worth taking a moment to dispel some myths that have been circulating about what we are doing.
One thing that we are definitely not doing is intentionally misconfiguring KDE to make it look bad. There is no point in shipping crippled software; all that could possibly do is give users a bad impression of Red Hat Linux.
Since we have a greater number of experienced GNOME hackers than we have of KDE hackers we are probably doing a better job with our modifications to GNOME than we are for KDE.
But we've spent more time and effort on our KDE configuration in this release than in any previous release, and we believe that the end product is, in fact, one of the best KDE desktops that we've shipped. As always, we welcome bug reports about things that don't work properly and suggestions about better ways to achieve our goals.
Another thing we are not doing is stripping out features of GNOME or KDE to reduce to them to a common subset. There are a few cases where features of one desktop or the other aren't in the default configuration because we are sharing one set of configuration decisions between the desktops. As example of this, we considered using the GNOME "menu panel" feature, but decided against it partly because an equivalent effect couldn't be achieved in KDE.
These features aren't removed, they're just not in our default configuration. And most features that you might find in one desktop but not the other have nothing to do with configuration. If someone chooses to use KDE, not GNOME because the file manager has a neat "Create Image Gallery" feature, that's great.
That being said, are there in fact downsides to our strategy? Yes, of course.
First, some amount of KDE and GNOME branding has been removed in the process of using an identical set of Red Hat artwork across the two desktops. The desktop projects have contributed an extraordinary amount of code and effort; they clearly deserve recognition for this.
Developer credit in places such as about boxes is obviously appropriate; making the desktop look like a Formula 1 race car is probably not. What forms of branding give appropriate credit to the authors while not getting in the user's way is a question that we don't necessarily have a good answer to yet.
Second, the desktop projects are interested in competing for users on the basis of:
By replacing the artwork and configuration defaults, and making a uniform set of applications visible for both desktops, Red Hat has largely removed these areas of competition from the realm of the versions of KDE and GNOME it ships. We recognize that this will not be universally popular.
So, what is left to compete on? Among other things:
Both GNOME and KDE are over 5 years old now, and there is no sign of either going away any time soon. While Red Hat has no intention of forcing cooperation on the two projects (or ability to do so), we don't think it is in our best interest, or our users' best interest to have two separate unrelated desktop universes within our product.
To summarize: We see the desktop as only a piece of the entire operating system product; integration must extend beyond the desktop. We also believe that users care most about functionality and integration rather than the underlying technology. For these reasons, we have created a single desktop look and feel for Red Hat Linux rather than maintaining two unrelated configurations.
Owen Taylor
Red Hat Desktop Team Member