Plasma’s road ahead

My Plasma Desktop in 2016
My Plasma Desktop in 2016
On Monday, KDE’s Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?

Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.

With these big words out there, let’s have a look at some specifics we talked about.

Release schedule until 2018

Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:

  • Plasma 5.9: 31 January 2017
  • Plasma 5.10: May 2017
  • Plasma 5.11: September 2017
  • Plasma 5.12: December 2017
  • Plasma 5.13: April 2018
  • Plasma 5.14 LTS: August 2018

A cautionary note, we can’t know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt’s release schedule. Here’s what we intend to do, it is really our “best guess”. Still, this aligns with Qt’s plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?

Breeze Look and Feel

Breeze Look and Feel

UI and Theming

The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.

Feature back-log

The menu button is a first sign of the global menu returning to Plasma
The menu button is a first sign of the global menu returning to Plasma
One thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app’s window (for example at the top of the screen). We’re currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.

Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.


The next releases overall will bring further improvements to our Wayland session. Currently, Plasma’s KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn’t seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma’s Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there’s some upstream bug-fixing needed, as well.

One thing we’d like to see to improve our users’ experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it’s tested, it will contain bugs.)


Plasma’s Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack’s footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.

Plasma Discover
Discover, Plasma’s software center integrates online content from the KDE Store, its convergent user-interface is provided by the Kirigami framework

Online Services

Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma’s feature-set.

Developer Recruitment

We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.

to not breathe

I’ve always loved diving down while snorkeling or swimming, and it’s been intriguing to me how long I can hold my breath, how far and deep I could go just like that. (The answer so far, 14m.)

Last week, I met with Jeanine Grasmeijer. Jeanine is one of the world’s top freedivers, two times world record holder, 11 times Dutch national record holder. She can hold her breath for longer than 7 minutes. Just last month she dove down to -92m without fins. (For the mathematically challenged, that’s 6.6 times 14m.)

Diving with Jeanine Grasmeijer
Diving with Jeanine Grasmeijer
Jeanine showed me how to not breathe properly.
We started with relaxation and breathing exercises on dry land. Deep relaxation, breathing using the proper and most effective technique, then holding  breath and recovering.
In the water, this actually got a bit easier. Water has better pressure characteristics on the lungs, and the mammalian diving reflex helps shutting off the air ways, leading to a yet more efficient breath hold. A cycle starts with breathing in the water through the snorkel for a few minutes, focusing on a calm and regular, relaxed breathing rhythm. After a few cycles of static apnea (breath holding under water, no movement), I passed the three-minute-mark at 3:10.
We then moved on to dynamic apnea (swimming a horizontal distance under water on one breath). Jeanine did a careful weight check with me, making sure my position would need as little as possible correction movements while swimming. With a reasonable trim achieved, I swam some 50m, though we mainly focused not on distance, but on technique of finning, arms usage and horizontal trim.
The final exercise in the pool was about diving safety. We went over the procedure to surface an unconscious diver, and get her back to her senses.

Freediving, as it turns out, is a way to put the world around on pause for a moment. You exist in the here and now, as if the past and future do not exist. The mind is in a completely calm state, while your body floats in a world of weightless balance. As much as diving is a physical activity, it can be a way to enter a state of Zen in the under water world.

Jeanine has not only been a kind, patient and reassuring mentor to me, but opened the door to a world which has always fascinated and intrigued me. A huge, warm thanks for so much inspiration of this deep passion!

Harbor porpoise Michael
The cutest whale in the world!

In other news on the “mammals that can hold their breath really well” topic: I’ve adopted a cute tiny orphaned whale!

Ocean Warrior

The Ocean Warrior
The Ocean Warrior

The Ocean Warrior, the newest vessel in Sea Shepherd‘s fleet docked in Amsterdam before beginning its voyage to the Southern Ocean around Antarctica to prevent poachers from killing whales. Sea Shepherd is a marine conservation society that employs direct action to protect marine wildlife. The Ocean Warrior is a 54m custom-built vessel, hosting a crew of 16. It’s very fast, reaching almost 30 knots at top speed. It is powered by 4 3000 horse power engines, and features an open deck at the stern with a hefty water cannon.

Inspecting the bridge
Inspecting the bridge

The Ocean Warrior is an incredibly slick and strictly functional master-piece of ship engineering.  Its solid build makes it a tool suitable for the extreme conditions around Antarctica.

View towards the stern from the bridge
View towards the stern from the bridge
Powerful water cannon to keep poachers at bay
Powerful water cannon to keep poachers at bay

Its unusually high top-speed will give the Sea Shepherd fleet a huge strategic advantage in the vast wideness of the Southern Ocean.

Stern deck
Stern deck


LTS releases align neatly for Plasma 5.8

Our upcoming release, Plasma 5.8 will be the first long-term supported (LTS) release of the Plasma 5 series. One great thing of this release is that it aligns support time-frames across the whole stack from the desktop through Qt and underlying operating systems. This makes Plasma 5.8 very attractive for users need to that rely on the stability of their computers.

Qt, Frameworks & Plasma

In the middle layer of the software stack, i.e. Qt, KDE Frameworks and Plasma, the support time-frames and conditions roughly look like this:

Qt 5.6

Qt 5.6 has been released in March as the first LTS release in the Qt 5 series. It comes with a 3-year long-term support guarantee, meaning it will receive patch releases providing bug fixes and security updates.

Frameworks 5.26

In tune with Plasma, during the recent Akademy we have decided to make KDE Frameworks, the libraries that underlie Plasma and many KDE applications 18 months of security support and fixes for major bugs, for example crashes. These updates will be shipped as needed for single frameworks and also appear as tags in the git repositories.

Plasma 5.8

The core of our long-term support promise is that Plasma 5.8 will receive at least 18 months of bugfix and security support from upstream KDE. Patch releases with bugfix, security and translation updates will be shipped in fibonacci rhythm.
To make this LTS extra reliable, we’ve concentrated the (still ongoing) development cycle for Plasma 5.8 on stability, bugfixes, performance improvements and overall polish. We want this to shine.
There’s one caveat, however: Wayland support excluded from long-term-support promises, as it is too experimental. X11 as display server is fully supported, of course.

Neon and Distros

You can enjoy these LTS releases from the source through a Neon flavor that ships an updated LTS stack based on Ubuntu’s 16.04 LTS version. openSuse Leap, which focuses on stability and continuity also ships Plasma 5.8, making it a perfect match.
The Plasma team encourages other distros to do the same.

Post LTS

After the 5.8 release, and during its support cycle, KDE will continue to release feature updates for Plasma which are supported through the next development cycle as usual.
Lars Knoll’s Qt roadmap talk (skip to 29:25 if you’re impatient and want to miss an otherwise exciting talk) proposes another Qt LTS release around 2018, which may serve as a base for future planning in the same direction.

It definitely makes a lot of sense to align support time-frames for releases vertically across the stack. This makes support for distributions considerably easier, creates a clearer base for planning for users (both private and institutional) and effectively leads to less headaches in daily life.

Announcing the KDE Software Store

KDE Store
KDE Store
Big news: Today, KDE announced a new software store, and that the source code for this new service has been released as Free software under the AGPL, fixing a long standing bug in KDE software: reliance on a proprietary web service.

That also means that KDE has a new software store that replaces the opendesktop sites. The migration has been happening in the background, so you may actually have used the new store from within Plasma or applications to install add-ons already without noticing it!

We have great plans for the store, one of them being that we want to offer download (and easy installation) of binary packages through containerized bundled formats such as Flatpak, Snappy and/or AppImage.

Stay tuned for more, for now, please celebrate with us a Plasma desktop (and KDE applications) that are more Free than ever before.

Update: I’ve uploaded slides, and there’s a video of my presentation online now.

Plasma at QtCon

QtCon opening keynote
QtCon opening keynote

QtCon 2016 is a special event: it co-hosts KDE’s Akademy, the Qt Contributor summit, the FSFE summit, the VideoLan dev days and KDAB’s training day into one big conference. As such, the conference is buzzing with developers and Free software people (often both traits combined in one person).

Naturally, the Plasma team is there with agenda’s filled to the brim: We want to tell more people about what Plasma has to offer, answer their questions, listen to their feedback and rope them in to work with us on Plasma. We have also planned a bunch of sessions to discuss important topics, let me give some examples:

  • Release Schedule — Our current schedule was based on the needs of a freshly released “dot oh” version (Plasma 5.0), Plasma 5 is now way more mature. Do we want to adjust our release schedule of 4 major versions a year to that?
  • Convergence — How can we improve integration of touch-friendly UIs in our workflows?
  • What are our biggest quality problems right now, and what are we going to do about it?
  • How do we make Plasma Mobile available on more devices, what are our next milestones?
  • How can we improve the Plasma session start?
  • What’s left to make Plasma on Wayland ready for prime-time?
  • How can we improve performance further?
  • etc.

You see, we’re going to be really busy here. You won’t see results of this next week, but this kind of meeting is important to flesh out our development for the next months and years.

All good
All good? – All good!


I’ve done a facelift to my website. The new version is more mobile-friendly, modern-looking and quite a departure visually from its original look. I’ve chosen for a newpaper-like, typography-based responsive layout. My site finally also supports SSL, thanks to let’s encrypt.

Going to Akademy
Next week, I’ll be going to Akademy, which is co-hosted with QtCon. As usual, my focus will be around Plasma-related topics. I’ll also hold a presentation about a KDE software store.

Multiscreen in Plasma: Improved tools and debugging

Plasma 5.8 will be our first long-term supported release in the Plasma 5 series. We want to make this a release as polished and stable as possible. One area we weren’t quite happy with was our multi-screen user experience. While it works quite well for most of our users, there were a number of problems which made our multi-screen support sub-par.
Let’s take a step back to define what we’re talking about.

Multi-screen support means that connecting more than one screen to your computer. The following use cases give good examples of the scope:

  • Static workstation A desktop computer with more than one display connected, the desktop typically spans both screens to give more screen real estate.
  • Docking station A laptop computer that is hooked up to a docking station with additional displays connected. This is a more interesting case, since different configurations may be picked depending on whether the laptop’s lid is closed or not, and how the user switches between displays.
  • Projector The computer is connected to a projector or TV.

The idea is that the user plugs in or starts up with that configuration, if the user has already configured this hardware combination, this setup is restored. Otherwise, a reasonable guess is done to put the user to a good starting point to fine-tune the setup.

This is the job of KScreen. At a technical level, kscreen consists of three parts:

  • system settings module This can be reached through system settings
  • kscreen daemon Run in a background process, this component saves, restores and creates initial screen configurations.
  • libkscreen This is the library providing the screen setup reading and writing API. It has backends for X11, Wayland, and others that allow to talk to the exact same programming interface, independent of the display server in use.

At an architectural level, this is a sound design: the roles are clearly separated, the low-level bits are suitably abstracted to allow re-use of code, the API presents what matters to the user, implementation details are hidden. Most importantly, aside from a few bugs, it works as expected, and in principle, there’s no reason why it shouldn’t.

So much for the theory. In reality, we’re dealing with a huge amount of complexity. There are hardware events such as suspending, waking up with different configurations, the laptop’s lid may be closed or opened (and when that’s done, we don’t even get an event that it closed, displays come and go, depending on their connection, the same piece of hardware might support completely different resolutions, hardware comes with broken EDID information, display connectors come and go, so do display controllers (crtcs); and on top of all that: the only way we get to know what actually works in reality for the user is the “throw stuff against the wall and observe what sticks” tactic.

This is the fabric of nightmares. Since I prefer to not sleep, but hack at night, I seemed to be the right person to send into this battle. (Coincidentally, I was also “crowned” kscreen maintainer a few months ago, but let’s stick to drama here.)

So, anyway, as I already mentioned in an earlier blog entry, we had some problems restoring configurations. In certain situations, displays weren’t enabled or positioned unreliably, or kscreen failed to restore configurations altogether, making it “forget” settings.

Better tools

Debugging these issues is not entirely trivial. We need to figure out at which level they happen (for example in our xrandr implementation, in other parts of the library, or in the daemon. We also need to figure out what happens exactly, and when it does. A complex architecture like this brings a number of synchronization problems with it, and these are hard to debug when you have to figure out what exactly goes on across log files. In Plasma 5.8, kscreen will log its activity into one consolidated, categorized and time-stamped log. This rather simple change has already been a huge help in getting to know what’s really going on, and it has helped us identify a number of problems.

A tool which I’ve been working on is kscreen-doctor. On the one hand, I needed a debugging helper tool that can give system information useful for debugging. Perhaps more importantly I know I’d be missing a command-line tool to futz around with screen configurations from the command-line or from scripts as Wayland arrives. kscreen-doctor allows to change the screen configuration at runtime, like this:

Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable

Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0

Please note that kscreen-doctor is quite experimental. It’s a tool that allows to shoot yourself in the foot, so user discretion is advised. If you break things, you get to keep the pieces. I’d like to develop this into a more stable tool in kscreen, but for now: don’t complain if it doesn’t work or eat your hamster.

Another neat testing tool is Wayland. The video wall configuration you see in the screenshot is unfortunately not real hardware I have around here. What I’ve done instead is run a Wayland server with these “virtual displays” connected, which in turn allowed me to reproduce a configuration issue. I’ll spare you the details of what exactly went wrong, but this kind of tricks allows us to reproduce problems with much more hardware than I ever want or need in my office. It doesn’t stop there, I’ve added this hardware configuration to our unit-testing suite, so we can make sure that this case is covered and working in the future.