Language Selection

English French German Italian Portuguese Spanish

KDE 4.0: Everything that has an end, has a beginning

Filed under

Note: This review's based on KDE 4.0 installed on openSUSE 10.3. If you're running openSUSE 10.3, KDE 4.0 is extremely easy to install. (Apologies to the Wachowski brothers for the title.)

Get Over It

A confession: I was among the many who griped publicly (and privately) about KDE 4.0's release date. I thought KDE 4.0 was not ready for release and should be held back until it was. (Hey, my wife and my dog listened to me. So there.)

Why? There were two main reasons.

First, one of the things I've loved the most about KDE is its large range of configuration options. For example, there's about a gazillion things you can do with the "kicker panel" (a.k.a. the taskbar) at the bottom of the screen in KDE 3.5.7.

Some of KDE 3.5.7's many kicker configuration options

By comparison, there's little you can do with the panel in KDE 4.0 — and, compared to KDE 3.5.7, not a lot you can do with the desktop, either. It didn't help that the betas and release candidates of KDE 4 contained even less functionality than the final version.

Second, although I've been playing with Linux distros since the late 90s, I didn't start using Linux seriously until around 2003. So the only version of KDE that I learned well was KDE 3. Changes to the KDE 3.x series seemed incremental; in other words, if you ran a live CD containing KDE 3.0, you could definitely recognize it as the precursor to KDE 3.5.8. I assumed KDE 4's user interface (UI) would be a "superset" of KDE 3.x's.

Instead, the KDE developers chose to concentrate on rewriting KDE's "plumbing," focusing (as far as this non-developer can tell) on simplifying and modernizing KDE's application programming interfaces (APIs), and updating it to Qt 4 (Qt is the development framework that KDE's based on). Among other things, this new "plumbing" includes a multimedia back-end named phonon; a new way of dealing with hardware named solid; and, most noticeably, a new user interface named plasma. As its Wikipedia article notes, "Plasma is still undergoing heavy development."

(Long-time KDE users have already noticed that, for some strange reason, none of the names for these technologies begin with the letter "k.")

Wikipedia mentions that, in KDE "x.0" releases, the developers can break compatibility with former releases. They didn't go that far, since KDE 3.5.x apps seem to run just fine on KDE 4.0. But we did see an example of the open source mantra, "release early, release often," in action. And it's worth mentioning that, while still very rough around the edges, the released version of KDE 4.0 was greatly improved compared to the betas and release candidates.

Developers as Politicians

Something else happened that was interesting. Several KDE developers, realizing the controversy there would be over KDE 4.0's unfinished state, took the time to explain what was going on. In particular, Aaron Seigo, president of the KDE foundation and the man mainly responsible for Plasma, addressed naysayers in a long blog post titled "Talking Bluntly" (a recommended read). openSUSE's Stephan Binner wrote a couple of posts about the situation. As the openSUSE KDE 4 page says:

"To make a long story short: KDE 4.0 is not and never was meant to replace 3.5.x for regular users. The main goals were porting to Qt4 and creating the frameworks to create all the things announced for KDE 4. Frameworks are unfortunately hardly visible to the user, so most things that use them, like plasmoids, panel-functionality etc., will only appear after the frameworks are in place, i.e. starting with 4.1."

(If you've got the time and bandwidth, download and listen to The Linux Link Tech Show's Jan. 2nd interview with Aaron Seigo (link goes to a 33.8 MB audio file in ogg format). He comes across as a very intelligent, thoughtful guy, and does a great job explaining the decisions behind KDE 4. Mr. Seigo seems to have taken quite a bit of grief over Plasma, but handles criticism with aplomb. Calling someone a politician is not always an insult!)

From Kubuntu to KDE 4.0

Users of Kubuntu 7.10 "Gutsy Gibbon" were treated to a simplified file manager named Dolphin, a simplified control center named System Settings, and a web-based desktop search engine named Strigi. All three are in KDE 4.0. Moreover, Dolphin now plays the role of KDE's default file manager, and System Settings replaces the KDE Control Center.

Left: Dolphin and System Settings on Kubuntu. Right: Strigi desktop search on Kubuntu.

Dolphin, System Settings, and Strigi on KDE 4.0

KDE 4.0's user interface will seem familiar to users of former versions of KDE. The major change is the addition of so-called "widgets," or "plasmoids," to the desktop. (I'll use the terms interchangeably.) Widgets are usually SuperKaramba-like applets, which could potentially be anything from a clock to a calculator to a system monitor. But it goes further than that — even desktop icons are widgets.

The KDE 4.0 panel (itself a plasmoid), L-R: Kickoff menu; traditional menu; task manager; desktop pager; Klipper (in the System Tray); New Device Notifier; and clock

Desktop widgets can be added by mousing over the Plasma icon in the upper right-hand corner of the screen, or from a desktop context menu. If you want to add one to the panel (such as the "traditional menu" seen above, or a trashcan), you can click and drag them from the "Add Widgets" dialog to an empty spot on the panel. You can also filter your favorite widgets from that dialog, as well as take them off your desktop.

Miscellaneous widgets

Messing around with widgets (click for larger image)

Widgets can be rotated, made larger, configured (if there are any configuration options for that widget), and made to quit, via small icons in the frame surrouding them that shows up when you mouse over them. You can lock them to the desktop, which hides the frame (which is handy, because at this point, sometimes the frame doesn't go away when it should).

Essential Apps

It would seem that the KDE developers wanted users to be able to differentiate between the web browser (Konqueror) and the file manager (Dolphin), instead of having the confusion of having Konqueror perform both functions. Although you can still use Konqueror as a file manager (by pressing Alt+F2 to open KRunner, and entering the command "konqueror --profile filemanagement" as before), for now, Konqueror uses Dolphin as its file management engine. (What's missing in both is a tree view in the right-hand pane. Hopefully that'll come back soon.)

Dolphin seems to have borrowed from GNOME's Nautilus file manager and from Mac OS X in its design. Of particular interest: the "breadcrumb" bar across the top, between the toolbar and the file window. Click on a ">" symbol to get a vertical listing of directories. The "breadcrumb" bar can be interchanged with a regular editable location bar with a mouse click. Also of interest: the new "columns" and "split" views (which sort of make up for the lack of a tree view in the right-hand pane).

L-R: Dolphin with "breadcrumb" bar; Dolphin using column view; Konqueror in file management mode

KDE 4.0's new default document viewer, Okular, can open up a huge variety of document formats. Gwenview is KDE's default image viewer. Konsole, KDE's terminal application, has a subtly revamped feel. (I could swear the line spacing is just a bit larger than it was in KDE 3.5.x; a pleasant surprise.)

L-R: Okular's list of supported formats; Gwenview in browser mode; Konsole's "profiles" settings

Games in KDE 4.0 now usually use scalable vector graphics, for a much nicer look. There are some interesting new applications, including Marble, a searchable "desktop globe;" and KPhotoAlbum, which is apparently complicated enough that the new user's offered a 10-minute series of introductory videos. As of this writing, KOffice 2.0 is still under development, and while some parts of it work, others (such as KWord) instantly crash.

L-R: Games in KDE 4.0; the Marble desktop globe; KPhotoAlbum; the Amarok audio player (version 2.0 "pre-alpha")

More Eye Candy

KDE 4.0's default theme, named Oxygen, comprises a new set of default sounds, a new, more photo-realistic set of icons, a windows decoration, or "windec" (the part that surrounds your application windows), and a widget style ("widget," in this sense, meaning buttons, scroll bars, progress bars, etc.).

(For those keeping score, most of these screenshots use Plastik as the windec and (the new) Plastique as the style. You still get to choose.)

The Oxygen style

If you've got a graphics card capable of displaying compositing effects (such as you'd see with Compiz Fusion), you'll find that KDE 4.0 includes many of its own. (They're turned off by default, but can be switched on from System Settings > Desktop > Desktop Effects.) Some of the effects are quite useful, such as the one that darkens the window underneath an active dialog box; and some are just for fun, such as the Explosion effect that makes windows that are closed, explode into pieces. Be advised that, at this point, turning on desktop effects can make other applications unresponsive, cause general flakiness, and make the entire UI unresponsive if you use an OpenGL screensaver.


L-R: Desktop effects settings; an Alt+Tab "box switch" window switcher; a "desktop grid" virtual desktop chooser

Finally, KDE 4.0 also comes with some gorgeous wallpapers.

In Conclusion...

KDE 4.0's release has been a learning experience, at least for me. KDE 4.0's got a long ways to go before it's ready to replace KDE 3.5.x. (For example, my desktop icons have suddenly stopped working!) But one thing is for sure: improvements (which is what you'll call them if you approve of them) and changes (which is what you'll probably call them if you don't) are occurring rapidly. (It seems like openSUSE releases new KDE 4 packages on an almost daily basis.) As far as the prior complaints go — fuggeddabouddit. Time to move on. I'm looking forward to seeing what KDE looks like, six months from now, and longer-term, years from now.

— Andrew Heil, aka "eco2geek"

For More Information:


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

A Fair Summary

My experience has been similar. I do remember one slightly angry diatribe by Aaron Segio in early beta days on his blog in response to some criticism. It appears to me that Mr. Segio has matured and grown in this development/release process. He is certainly a bright, thoughtful, and engaging person as his appearance on the TLLTS podcast clearly demonstrates.

I look forward to KDE 4.1 and 4.2, as I do believe that it will make for a magnificent desktop experience.

> KDE 3.5.x apps seem to run

> KDE 3.5.x apps seem to run just fine on KDE 4.0

That's because they use Qt4, whereas KDE4 uses Qt4, so I suppose KDE3-apps don't actually use anything from KDE4!

Makes sense

And since openSUSE puts KDE3 into /opt, and KDE4 into /usr (which is where all the other distros I've seen usually put KDE3), that probably makes it a whole lot easier to have them both installed at the same time, without naming conflicts.


Béranger wrote:
That's because they use Qt4, whereas KDE4 uses Qt4
Obviously, what I wanted to say is "because they use Qt3, whereas KDE4 uses Qt4".

Nice summary Eco2geek.

I too was one of the ones that complained alot about the kde 4 rc/betas. I still feel there's alot of missing functionality and such..but overall, I was actually a lot LESS disappointed with kde 4.0 than I thought I would be. Some seems they really made everything fall into place right before the release. I've been using it ever since..and aside from a few minor annoyances, it's a fairly solid desktop. I really like it..and I'm looking forward to future releases..which should be greatly improved feature-wise.

More in Tux Machines

KDE: Linux and Qt in Automotive, KDE Discover, Plasma5 18.01 in Slackware

  • Linux and Qt in Automotive? Let’s meet up!
    For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)
  • What about AppImage?
    I see a lot of people asking about state of AppImage support in Discover. It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.
  • What’s new for January? Plasma5 18.01, and more
    When I sat down to write a new post I noticed that I had not written a single post since the previous Plasma 5 announcement. Well, I guess the past month was a busy one. Also I bought a new e-reader (the Kobo Aura H2O 2nd edition) to replace my ageing Sony PRS-T1. That made me spend a lot of time just reading books and enjoying a proper back-lit E-ink screen. What I read? The War of the Flowers by Tad Williams, A Shadow all of Light by Fred Chappell, Persepolis Rising and several of the short stories (Drive, The Butcher of Anderson Station, The Churn and Strange Dogs) by James SA Corey and finally Red Sister by Mark Lawrence. All very much worth your time.

GNU/Linux: Live Patching, Gravity of Kubernetes, Welcome to 2018

  • How Live Patching Has Improved Xen Virtualization
    The open-source Xen virtualization hypervisor is widely deployed by enterprises and cloud providers alike, which benefit from the continuous innovation that the project delivers. In a video interview with ServerWatch, Lars Kurth, Chairman of the Xen Project Advisory Board and Director, Open Source Solutions at Citrix, details some of the recent additions to Xen and how they are helping move the project forward.
  • The Gravity of Kubernetes
    Most new internet businesses started in the foreseeable future will leverage Kubernetes (whether they realize it or not). Many old applications are migrating to Kubernetes too. Before Kubernetes, there was no standardization around a specific distributed systems platform. Just like Linux became the standard server-side operating system for a single node, Kubernetes has become the standard way to orchestrate all of the nodes in your application. With Kubernetes, distributed systems tools can have network effects. Every time someone builds a new tool for Kubernetes, it makes all the other tools better. And it further cements Kubernetes as the standard.
  • Welcome to 2018
    The image of the technology industry as a whole suffered in 2017, and that process is likely to continue this year as well. That should lead to an increased level of introspection that will certainly affect the free-software community. Many of us got into free software to, among other things, make the world a better place. It is not at all clear that all of our activities are doing that, or what we should do to change that situation. Expect a lively conversation on how our projects should be run and what they should be trying to achieve. Some of that introspection will certainly carry into projects related to machine learning and similar topics. There will be more interesting AI-related free software in 2018, but it may not all be beneficial. How well will the world be served, for example, by a highly capable, free facial-recognition system and associated global database? Our community will be no more effective than anybody else at limiting progress of potentially freedom-reducing technologies, but we should try harder to ensure that our technologies promote and support freedom to the greatest extent possible. Our 2017 predictions missed the fact that an increasing number of security problems are being found at the hardware level. We'll not make the same mistake in 2018. Much of what we think of as "hardware" has a great deal of software built into it — highly proprietary software that runs at the highest privilege levels and which is not subject to third-party review. Of course that software has bugs and security issues of its own; it couldn't really be any other way. We will see more of those issues in 2018, and many of them are likely to prove difficult to fix.

Linux Kernel Development

  • New Sound Drivers Coming In Linux 4.16 Kernel
    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle. The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.
  • Varlink: a protocol for IPC
    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1. The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.
  • Statistics for the 4.15 kernel
    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall. This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.
  • A new kernel polling interface
    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance. On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

  • Another Face to Face: Email Changes and Crypto Policy
    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended. One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre
    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure. For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.
  • Addressing Meltdown and Spectre in the kernel
    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly. First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.
  • Is it time for open processors?
    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea. Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.
  • Notes from the Intelpocalypse
    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel. All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks. A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.