After the recent release KDE 4.1 beta 2 and openSUSE 11 with KDE 4.0.4, some critics have been especially vocal in expressing their displeasure with the KDE 4 user interface paradigms. The debate has grown increasingly caustic as critics and supporters engage in a war of words over the technology. The controversy has escalated to the point where some users are now advocating a fork in order to move forward the old KDE 3.5 UI paradigms. As an observer who has closely studied each new release of KDE 4, I'm convinced that the fork rhetoric is an absurdly unproductive direction for this debate.

For those who are unacquainted with the KDE 4 controversy, I'll start with a brief background overview. KDE 4.0 is the product of an extremely ambitious overhaul initiative that was launched by the KDE community. The desktop environment got its most extensive update in history with changes that impacted the underlying architecture, the development process, and the user interface. It was finally released in January in a very incomplete and marginally usable state. The developers claimed that the premature release was necessary in order to increase momentum and facilitate broader end-user testing. The 4.1 release, they said, was the one that would be ready for mainstream adoption. This decision was extremely controversial and has created uncertainty for many users who depend on the software.

A rough migration

As KDE 4 begins to replace the stable 3.5.x series as the default KDE environment in major distributions, users who are now migrating to the new version are being exposed to a lot of the rough edges. This has ignited a new wave of complaints much like those we saw shortly after the initial launch. One of the most recent critics is Steven J. Vaughan-Nichols, former senior editor at Ziff Davis, longtime Linux writer and KDE user.

He wrote a negative review of KDE 4.0.4 on openSUSE 11 last week and complained about some of the deficiencies. I was a bit surprised by his review, because I happen to really like openSUSE 11, and I think it provides a reasonably polished KDE experience that beats other distros, but I did see merit in some of his criticisms, and I could definitely sympathize with his position. It frustrated me to see the vicious backlash against his commentary from some KDE enthusiasts who seem to have no patience for negative opinions.

Although I can't reproduce most of the stability problems he complains about, his frustration with the environment is understandable. KDE 4.0.4 is still relatively incomplete and there are a lot of nice goodies in the latest 4.1 beta that offer a much better experience. Several readers encouraged him to take a look. He was apparently so disappointed with what he saw that he is now calling for a fork. His initial critique could have been the starting point for some meaningful open dialog about interface design and the technical direction of KDE 4, but bitterness on both sides has made that difficult.

Delivering on KDE 4's potential

Steven singles out KDE 4.1's desktop folder view plasmoid for criticism, but I regard it as one of the most promising features in KDE 4.1. In fact, I think the new desktop folder view offers some of the first truly compelling evidence that Plasma can deliver on its potential and provide more than just a conventional widget layer. I think it's innovative and it increases the efficiency of my workflow.

The value of conventional desktop icons is that they allow users to organize their files into spatially relevant groupings. But most users just treat the desktop as a dumping ground for temporary content because moving things to and from the desktop requires more interaction and isn't always feasible if you need your project to have a consistent path. The KDE 4.1 folder view is a plasmoid that contains the icons of a specified folder. Users can place folder view plasmoids on the desktop and interact with the contents just like regular KDE 3.5.x desktop icons. The beauty of the system is that it gives you all the advantages of a conventional desktop but allows for simultaneous access to files that are in multiple locations.

In response to my review of the last KDE 4.1 beta, several readers asked for some clarification about how Plasma windows are different from conventional windows. The benefits aren't immediately obvious to some users, but I find the Plasma model to be advantageous in many ways. Say that I have three folder-view plasmoids open on my desktop with the source code of various parts of a program I'm writing. If I was using a file manager instead, that would be three extra windows to rotate through when I'm using alt+tab. It would be three extra windows cluttering up my task list. It would be three extra windows that I have to move and manage when I need to get to something else. Plasmoids don't get in the way like that, they just cling to the desktop and pop to the top when I activate the plasma layer. It's very clean and efficient in a lot of ways.

There are also downsides, too. For instance, the mechanism for resizing plasmoids still feels cumbersome to me compared to regular windows, and there is no way to remove plasmoids directly with the keyboard. These issues, and other problems that still detract from Plasma's usefulness, are all fixable. This is why I think that the call for a fork is deeply misguided. The most egregious problems that made Plasma suck in 4.0 have all been addressed. The lack of panel configurability was one of my biggest initial complaints, for instance, but the new panel configuration system is usable and clever. The current solutions aren't perfect, but they demonstrate that Plasma is viable and has the potential to offer superior alternatives to the KDE 3.5 model in many places.

The single greatest strength of Plasma is the inherent mutability that it brings to the desktop. It provides a very flexible framework within which the developers can experiment with completely different paradigms for basic components of the user interface. That is why a fork is a profoundly misguided option at this stage. If Steven and other critics don't like the way it works, they can leverage Plasma to create something that they do like, and it would be easier and more productive to do that than it would be to maintain a complete fork of KDE 3.5.x.

KDE 4.1 doesn't force users to accept the new interface models. Users who prefer a conventional desktop can simply use one folder view plasmoid and make it fill the screen. Users who don't like the new file manager can still use the old one, which recently regained some of the useful features that were initially lost in the port to 4.0. I personally don't particularly like the new KDE 4 applications menu, but I can still happily use the old one, which is included as an optional plasmoid. Many of the complaints at this point are emotional rather than rational.

I have used both GNOME and KDE extensively over the years, but have been mostly committed to GNOME in recent times. When KDE 4.0 was first released, I was extremely skeptical about Plasma. I saw a lot of innovation under the surface, but didn't see anything at all to impress me in the parts that were visible to the end user. The work that has been done in the time since the 4.0 release is very compelling and has completely convinced me that the strength of Plasma's underlying architecture can be translated into very real and tangible improvements to the end user experience.

Although KDE 4.1 is gearing up to deliver a very strong user experience, the negative impression left by the clumsy 4.0 release will turn off a lot of users like Steven and prevent them from giving 4.1 a fair chance. That's the biggest tragedy of this whole debacle. The 4.0 release was accompanied by a mixed message that was poorly conveyed and poorly received. The developers said that it wasn't ready for users while simultaneously defending the early release by saying that they did it so they could entice regular users to participate in broader testing. A bad release burns a lot of trust and makes it hard for users to give developers the benefit of the doubt.

I encourage users to look beneath the surface and try to understand how the emerging features fit into the long-term roadmap. There is a lot to like in KDE 4.1 if you are willing to approach it with an open mind and not simply dismiss it because it's different.