Lightweight KDE Desktop Project

KDE Gets a Refit

By

An openSUSE project called KLyDE plans to streamline the KDE desktop.

“KDE is not intrinsically bloated,” veteran developer Will Stephenson maintains in a recent blog. “At its core, it jumps through a lot of hoops for memory efficiency and speed and is modular to a fault.” However, Stephenson has long seen a need to improve how KDE is installed. Recently, he has been working with other developers from SUSE and openSUSE on the Lightweight KDE Desktop project (KLyDE) to provide multiple solutions for improving KDE’s performance.

Stephenson developed an interest in free and open source software while studying computer science in the late 1990s. Seeing installations of KDE 1.0 in a university computer lab, he began compiling it himself so he could follow the latest developments. His first contributions were to KDE 2, in which he added a feature in KPP, as well as icons and plugins for Kopete. These contributions helped him at SUSE in 2004, where he implemented its Novell Groupwise plugin and became a member of the openSUSE Boosters team.

Over the years, Stephenson has worked on various KDE projects. This year, during the recently completed Hack Week 9, a developer sprint in which SUSE developers work on projects that personally interest them, he began working on KLyDE with other past and present members of SUSE and openSUSE, including community manager Jos Poortvliet and Klaas Freitag, Raymond Wooninck, and shumski.

The Rise of KLyDE

“Efficient customization has always been an interest of mine,” Stephenson tells me. Some years ago, he proposed an idea for SUSE KDE that he called Project IKEA, “where the desktop would be configured using the metaphor of filling a shopping cart with options while browsing through attractive screenshots."

“It was rejected,” he adds simply.

Stephenson first began thinking of KLyDE five years ago in the early days of the KDE 4 release series, when lightweight desktops like Xfce and LXDE were becoming popular, and a strong anti-KDE reaction still existed. Stephenson was returning from a meeting about the KDE personal information management (PIM). At the meeting, he had analyzed the efficiency of how Nepomuk indexed data in Akonadi, KDE’s PIM module. At the time, Nepomuk was very much a work in progress, and Stephenson was among those who were “trying to improve the user experience by indexing less and smarter. The journey gave me time to think about applying this principle to the desktop as a whole.”

Stephenson presented his ideas at COSUP 12, and talked to PCMan, the founder of LXDE, at the same conference. As time for the latest Hack Week rolled around, he says, “I decided to make a real project out of the ideas I’d been kicking around and recruit some help.”

Multiple Approaches

Stephenson explains that KLyDE is needed because of the increased variety of applications. A decaded ago, he explains, “if you were a KDE user, everyone tended to be using the same tools – Konqueror, KMail/Kontact, KVirc or Kopete, and JuK or, later, Amarok. Nowadays, there a lot more variability. Look at the choice of browsers – many use webmail or streaming media services instead of local rich clients, and wagging your finger at people about the superiority of native code over HTML gets you nowhere.” Under these conditions, “a desktop that brings with it unused middleware and apps feels cluttered and distracting.”

Over the years, efforts have been made to improve the situation. For instance, in 2005, Marco Fioretti tried to promote the RULE Project to streamline installations, particularly for KDE. Similarly, Kubuntu has its Low Fat minimal KDE install, whereas Gentoo allows users to pick precisely what to install.

However, according to Stephenson, such efforts “are either no longer active, are not visible enough, are for hardcore users only, or don’t go far enough” – which is where KLyDE comes in.

Stephenson has several goals for KLyDE. The first involves a revision of the standard KDE packages, removing from the standard installation features such as Nepomuk and Akonadi and the tasked-based Activities workspaces that aren’t used by everyone. Stephenson compares this approach to starting “with a basic workbench, and if you want a CNC lathe at one end and a 3D printer at the other, you can add those as you need them.”

Such changes “are actually the easiest [to implement] if you know the internals of KDE well,” he says. “We started with a profile representing a basic session minus the PIM and indexing middleware, then removed things like NetworkManager and PackageKit applets, then sound mixer, power management, and bluetooth applets – then got really aggressive and started using ‘simple’ styles and windows decoratons, and used a solid colour as a wallpaper. But I’m sure that is going too far down the path of compulsive dieting.”

Stephenson continues by explaining that the second goal:

involves coding to make it seamless when optional components are disabled or not installed. For example, when Activities are not in use, don’t show the Activities button on the panel or in the desktop toobox. Likewise, the whole range of workspace configuration options KDE offers are overkill for many, and we can’t just reduced those by packaging, so we’re planning to work on some basic config modules that offer just enough personalization to feel at home.

These first two goals by themselves could add to the complexity of a KDE installation for both maintainers and users. To prevent that, a third goal is to create profiles of different types of installations. On his blog, Stephenson writes, “We’ve collected sets of configs that represent these profiles, but I’m not entirely sure how to package this yet.” He raises the possibility of shipping these configurations as X sessions and using a first-run wizard so that users can select a profile the first time they log in. Alternatively, profiles might be set from KPersonalizer, allowing users to reconfigure their desktop whenever they choose.

Stephenson also plans to make profiles capable of being applied to an existing installation without affecting other users on the same machine. “We want the default profile to be useful out of the box, and comfortable integration with common Linux infrastructure is part of that.”

Along with these main goals, Stephenson is also exploring a simplified System Settings that includes only the apps that are relevant to the chosen profile, as well as how to reduce boot time. These minor goals are partly cosmetic, adding to the lightweight impression without necessarily being the result of any changes. In fact, Stephenson notes that rearranging the core packages does not greatly effect startup speed.

However, he jokes on his blog that, “I’m not above exploiting this fallacy to give people what they want.” To this end, he is currently exploring optimizing KDE’s startup scripts as well as startkde, kdeinit, and ksmserver,all of which were written before multiple procesor cores became the norm. Another alternative might be to build KLyDE specifically for systemd, the current favorite to replace init on Linux systems.

Next Steps

When I interviewed Stephenson, he noted that “we’re about 80% done on the packaging and profiled configuration and simple system settings.” Those interested can view the state of the project on Trello, including rejected ideas, such as replacing FolderView with a desktop with a single set of icons.

KLyDe’s results to date are available on the openSUSE Build Service, separate from the main openSUSE KDE. Stephenson plans for a Live disk image to be released shortly.

After that, work is scheduled to begin on simplifying the Systems Setting interface and improving startup time, ending with some efforts to benchmark the results.

“Because memory use benchmarking is such a dark art, we’re concentrating on modularizing to a basic useful desktop rather than becoming slaves to probably worthless numbers,” Stephenson says. “But it would be nice to have a credible way to measure the changes we’re making, not so we can claim to be X% lighter than vanilla KDE (although we’ll probably fall prey to the temptation), but so we can see what our incremental changes do compared to the last build.”

In its goals, KLyDE reminds me of those children’s games in which each player has to remove a piece from a structure without bringing down the rest of it. Yet, as a piece of housekeeping, it is a timely project. Five years after KDE 4.0 was released, developers have a clearer sense of what people are using, and a cleanup of core libraries and functions seems overdue. Aside from any other improvements that KLyDE might offer, cleanup alone makes it a project whose time has finally come.

Related content

comments powered by Disqus

Issue 170/2015

Buy this issue as a PDF

Digital Issue: Price $9.99
(incl. VAT)

News