Next means Focus on the Core

The metaphor of a home make-over crossed my mind today, and I think it implies a few ideas that connect to Plasma Next quite well.
Plasma Next
Plasma Next is a new iteration of the Plasma workspaces. This is the first time, that KDE’s workspace is released independently from its underlying libraries and the applications accompanying it. It is built upon KDE Frameworks 5 and Qt5. “Plasma Next” is our name for the development version of Plasma, the final product will not be called “Next”. The planned release does not include the applications that are shipped today as part of the KDE Software Compilation. Applications, just like the Frameworks follow a different release schedule. Of course it’s entirely possible to run KDE SC 4 Applications on a Plasma Next desktop, and vice versa.

We have now settled on a release schedule for Plasma Next, which plans for the first stable release in June. It’s a good time to talk about what’s to expect in this first release. I think we’ve got some pretty exciting improved technology in the works. As our new baby shapes up, let’s take a look at what’s old and what’s new in more detail.

Frameworks 5

Plasma Next bases on KDE Frameworks 5, which is a modularized version of the venerable KDE development platform, kdelibs and friends, so to say. This results in a reduced footprint in terms of dependencies. The Plasma libraries and runtime components are one of those Frameworks itself, providing the tools to build applications and workspaces. Plasma has been one of the early adopters of Frameworks 5, mainly for the reason that we had to do some development in parallel. While building on an unstable base wasn’t always easy, it certainly has its benefits: We could check the viability of the Frameworks goals, and catch regressions early on. A good test harness only goes so far, actually building a real world application with the libraries makes sure they’re stable and functioning. These days, the issues are gone, KDE Frameworks has stabilised enough that applications can be ported quite easily.
With the move to Frameworks 5 come some architectural changes that allow us to cut out some “runtime fat”, we can get rid of some separate processes with the new architecture, which results in a leaner system for the user.

QtQuick for the UI

Plasma Next wallpaper selection
Plasma Next wallpaper selection

The transition to QtQuick reaches a very significant milestone in Plasma Next: the whole UI is written in QML. This concludes a transition process which we’ve started in Plasma 4.x, as a side-effect it solves a whole class of long-standing quality and maintenance problem in the code, it means a higher quality for many users. The transition to QtQuick-based UI has been fairly smooth so far, so we are not jumping onto something entirely new here, which means that we have been able to port much of the existing and matured functionality from Plasma 4.x over to Plasma Next. Our QML APIs have not changed radically, so porting existing code written in QML to Plasma Next is not a huge amount of work. For add-ons written in other languages (UIs written in C++, Python and other languages are currently not supported, this is a conscious design decision, and unless there are QML bindings for these languages (which seems like a weird idea), this is unlikely to be supported in the future. Instead we’ve improved and matured the QML API to a level where it’s very easy to create almost anything you can dream of in QML.

New Graphics Stack

Plasma’s graphical stack reaches a new state-of-the-art this year. We are now able to fully offload the rendering of the UI into threads, and other processes, making the UI responsive by default. We also offload visual effects almost entirely onto the graphics card. This means that it’s faster, so you get better framerates out of it, it frees up CPU time for the user and it’s also more energy-efficient, so saves some battery life.
In case the system falls back to software rendering, we can now centrally disable animations, so even on systems that paint slowly, or we can reduce repaints drastically to give a snappy feel. This means that the visual effects in the UI degrade gracefully with available graphics features on the system. For the vast majority of users, this isn’t an issue anyway, their systems run a fully hardware-accelerated desktop with complete ease. On these systems we can improve the user experience by using the graphics card’s capability — and not only that: The transition to QtQuick 2, which is part of Qt5 means that all the work at UI level can be offloaded onto the GPU as well.

Another hot topic these days is Wayland readiness. This is currently work in progress, Martin Gräßlin’s blog shows some impressive progress on running KDE applications on Wayland. This is one of many important milestones. The most complex case is running a full Wayland session with Plasma and KDE applications, and we are not there yet. Wayland support is continuously improved.

Polished Interaction

Let's try a dark theme
Let’s try a dark theme

Next to these architectural changes, we’ve also put some work into the actual UI visuals and interaction. We are in the process of establishing a Visual Design Group in KDE. Which already participates in the development of Plasma Next. The first results of this will be visible this summer, and the group is currently hashing out plans for the future. There is some serious design love appearing. You can follow the progress of it on the wheeldesign blog.

One of my favourite new features that has recently landed is Marco’s work on contrast behind translucent dialogs, which hugely improves readability in many cases, and make “the old Plasma” almost look bland in comparison. We’ve cleaned up quite a lot of workflows, not by making them any different, but by removing visual noise in between. The idea is to polish common elements to feel fresh and like an upgrade to users, but not entirely different. In the UI, known behavioral patterns are kept in place, with more pronounced core functions, and less fuzz around them. We’re aiming at keeping all the functionality and adaptability in place. To the user, the migration to Plasma Next should feel like an upgrade, not something completely new, but trusted after a bigger step in its evolution, yet recognizably true to its values.

We want to achieve this by concentrating on the core values, on what makes us good, and what users love us for. But we also do not want to pass the opportunity to fix what nags us and our users. Improvements in details mean that we listen to our users, a large portion of which do not want to be the subject of UI experiments, but who require a reliable system that supports and improves the personal workflows they have almost brought to perfection.

Of course, all of these workflows rely on many details behaving as they do, and these things are different for everyone. A small difference in behavior, or a missing seemingly minor feature might make or break any given workflow, there is no guarantee to be made, just a promise of best effort.
Many, but not all parts are co-installable, and it will be possible to use KDE SC 4 applications in a Plasma Next environment, and vice versa.

Beyond Devices

Plasma Next runs on top of a device-independent shell. The whole UI is structured into logical blocks that can be exchanged at runtime, this allows for dynamic switching the user interface to suit a different form factor. A target device will typically have the plasma-shell (and runtime bits) installed, and one or more device-specific shells. We are now readying the first of these “workspace user experiences”, Plasma Desktop. Others, such as the tablet-oriented Plasma Active UX will join in subsequent releases.

When will it be good enough for me?

While no .0 will ever be perfect, I expect that Plasma Next.0 will feel very much like an evolutionary step to the user, and certainly miles away compared to the impact of Plasma in KDE 4.0. For those that still remember the transition from KDE 2.2 to KDE 3.0, this seems rather comparable. While KDE 2 was almost a complete rewrite of KDE 1, the 2 to 3 transition was much less radical and far-reaching. We saw the same pattern between KDE 3 and 4, which again was quite radical, especially in and kdelibs and even more so for the workspace — Plasma which was completely new in 4.0.

In the first stable release of Plasma Next we want to provide a stable and fully functional core desktop. We concentrate on making the most important default functionality available, and are polishing this first and foremost. I expect that most users can be just happy with this first release, but as I said, there’s no guarantee, and maybe you’re missing something. For those that want to make the switch later, we have of course our long-term maintained current Plasma stable, so there’s no rush.
This concentration on the core also means that not every single feature will be available immediately. We are, however aiming at feature parity, so in most cases, a missing feature in .0 will be brought back in a later release. The kdeplasma-addons module, which contains additional functionality will likely not be ported by summer.

Ultimately, the way to make a good Plasma Next happen is to lend us a hand and take part. Even better, you don’t have to wait with this until summer. Take the plunge, build KDE Frameworks 5 and Plasma Next, try it and help us completing the core functionality and to fix bugs. That is exactly what we will be doing in the next months leading up to the release this summer, and we hope the experience will be delightful one for our users.

DBus-Activated Systemtray Plasmoids

In this article, I’m describing a way to dynamically load Plasmoids into the systemtray. It’s interesting for you if you develop Plasma addons, or if you’re interested in the design of Plasma by KDE.

One of the wishes that came up during the latest Plasma sprint in Barcelona was a more dynamic way of showing functionality in the systemtray, that little notification area sitting in the panel next to the clock. The systemtray can have different kinds of “things” in them: Statusnotifiers, which are basically systray icons of applications, and Plasma widgets, which allows for much more functionality and freedom in UI development. Statusnotifiers are instantiated by applications, so their lifetime is entirely in the hands of the application they belong to. For Plasma widgets, this is a bit different, they’re currently loaded on startup. Ideally, we want to load specific services on-demand, say when a specific service becomes available.

You may have guessed by the title already, this feature has now landed in Plasma Next. It was actually quite easy to do, yet it’s a very powerful feature. First, let’s see what it looks like:

This feature allows loading and unloading Plasmoids when dbus services come and go. Applets can specify in their metadata which service should control their lifecycle.

This has the following advantages:

  • We can dynamically only load widgets when they’re useful, reducing clutter in many cases
  • Applications can provide widgets that appear and disappear based on the application running
  • We can load controls for system services dynamically as they come and go
  • It makes it easier to delay loading of widgets in the systemtray until when a specific service appears, cutting down startup time
  • It makes widgets and their features more discoverable as they’ll be able to appear automatically

One immediate user for this is the media controller widget, which will now only be loaded once an MPRIS2-compatible media player is running (as indicated by a dbus interface becoming available on the session bus.)

How do you do that? It’s quite easy. Two things need to be done: the widget should indicate to be loaded into the systemtray automatically, and it needs to specify a service which triggers loading it. That’s two lines in your metadata.desktop file, looking like this for example:

X-Plasma-NotificationArea=true
X-Plasma-DBusActivationService=org.mpris.MediaPlayer2.

That’s all. Enjoy your cleaner, more dynamic systemtray!

Reasonable DPI in Plasma Next

We are currently looking into how we can improve Plasma (but in extension also other applications, including QWidget-based ones) on hardware that sports unusually high DPI (also called “reasonable DPI”). In this article, I’ll outline the problem space and explain our tools to improve support for high DPI devices in Plasma.

First, let’s take a step back, however, to explain the problem space to those who haven’t yet spent that much thinking on this. Most of today’s desktops and laptops have have roughly the same amount of pixels per square inch of screen space. The amount of pixels per inch is measured in DPI (dots per inch) or PPI (pixels per inch). This value is around 100 DPI for laptops. Tablets and smartphones are already available with much higher DPI screens, making for sharper fonts and overall higher fidelity graphics. A while ago, Apple has started producing laptops with high DPI displays as well, these are the so-called Retina screens. There are Macbooks on the market with 220 DPI.

Test Plasmoid showing a scaled UI
Test Plasmoid showing a scaled UI

Some people have complained for years about the low DPI value of screens available on the market (and I am one of them), higher DPI simply allows for nicer looks, and reduces the need for “dirty tricks” such as subpixel rendering algorithms (which come with their own set of problems). Graphics chips also have become fast enough (and with enough memory) to not have a problem with high resolutions (think 4K on your laptop, for example).

I’ve done some research (Well, lazy-webbing, mostly), and it seems that higher DPI screens for desktop systems, but also for laptops are still quite rare, and when you find one, they’re often really, really expensive. I believe this is caused by two reasons: production-line quality is not always good enough to produce high DPI screens, one could say that the more pixels there are on a given device, the higher the chance that one or more of them are dead, making the display unsellable, and thus increasing the price of the ones that are pixel-perfect. Also, tablets and smartphones, which often already sport high DPI screens are currently taking up almost all of the production capacity. The obvious result is scarcity and a high price. I believe it’s only a matter of time until high DPI displays become more common, however. A few friends of mine already have high DPI displays, so there is a real need to support this kind of screen well.

Battery Widget without icon scaling
Battery Widget without icon scaling

So what’s the problem? Many applications assume a fixed DPI size, or at least that the DPI value of the screen is within a certain range, so that when you render an icon at 22 pixels, it will look like a small icon, compared to text, and that its details are visible. Also, icons and sizing of fonts are loosely related, so an icon that is way smaller than the size of the text as rendered will look weird and cause layouting problems. (Imagine huge letters and cut off text, for example.)
For graphical elements, this is a real problem, but less so for text. Today’s text rendering engines (Freetype, for example) take the DPI value of the screen into account. This means that this at least partly solves our problem. Luckily, it solves the problem for very complex cases, so at least this is not of great concern. It’s only a partial solution, however, so this at best eases finding a complete solution. We need to fix these problems in different areas, and all need to have well-thought out solutions.

Limitations in X11

The bad news is that this problem is only partly solvable in an X11 world. X11 has no real concept of different DPI values per screen. This is not so much a problem for single screen systems — we just use the DPI of the only screen. As soon as you attach a second screen that has a different DPI, this is going to be a problem, and it’s not possible to solve this completely in an X11 world. We’re planning to first make it work in a single DPI environment, and then work towards supporting different DPI values per screen. (Of course we’ll keep multi-DPI-screens in mind, so that we don’t have to take too many steps back once we are actually in a position to be able to support this. This means Wayland, basically.)

Battery Widget using icon scaling
Battery Widget using icon scaling

Cheating with fonts

A pretty easy, yet neat solution is to use font metrics to compute sensible dimensions for graphical elements on the screen. The very short version is to stop thinking in numbers of pixels, and to start thinking in lines of text and with of characters as they end up on the screen. This is not a pure solution to the DPI problem, which in many cases is actually an advantage. The size (for example height) of a given letter rendered on the screen depends on a number of properties:

  • The DPI value of the screen which is used to render the text
  • The font size setting
  • The size of the font itself, as it is designed (this is usually more relevant for the aspect ratio between width and height)

This means that taking the font height as rendered, we actually can compute values for sizing elements that not only take the low-level technical properties of the hardware into account, but also user preferences (or system presets). In Plasma 2, we started using this mechanism in a number of places, and so far we’re pretty happy with the results. Some examples which where we use this is the sizing of popups coming out of the panel (for the notification area and the calendar for example), but also the sizing of the icons in the notification area (or system tray). This means instead of hardcoding pixel sizes, these UI elements grow and shrink depending on your settings. This solves a part of the problem, but is obviously not a complete solution. If you would like to implement this mechanism, here’s two snippets of code, which, with some necessary adaption, you can use to make your app work well on High DPI devices.

in Qt C++ code:

const int fontHeight = QFontMetrics(QApplication::font()).boundingRect("M").size().height();

This gives you the height of the letter “M” as it would be rendered on the screen. It’s a useful mechanism to get you a pixelsize that is dependent on the DPI value of the screen. Note that you want to use an int here, in order to not end up aligning UI elements at half pixels, as this leads to blurriness in your UI.)

We’ve bridged this API in the Plasma Theme class, which is available from QML applications by importing org.kde.plasma.core (the global property theme will be automatically set, which allows you easy access to Plasma::Theme from everywhere, in case you’re wondering where the “theme” variable is coming from).

import org.kde.plasma.core 2.0 as PlasmaCore

/* Paint an orange rectangle on the screen that scales with DPI 
   This example makes the rect big enough to paint about 8 rows
   of text (minus spacing), and allows for a column with of about 
   60 characters. Mileage varies on fonts used, and the text 
   itself, so this is an approximation.
 */
Rectangle {
    width: theme.mSize(theme.defaultFont).height * 8
    height: theme.mSize(theme.defaultFont).width * 60
    anchors.margins: units.largeSpacing

    Item {
        anchors.fill: parent
        /* ... more stuff ... */
    }
}

In the second example, you see that we’re using another property, “units.largeSpacing” for the margins. This is another piece of DPI-dependent UI which you can use to apply margins and spacing that take DPI (actually font-as-rendered-settings) into account.
To get the size of a piece of text on the screen, in QtQuick code, you can use the paintedWidth property of a Text elements, but not that this can be tricky due to text elision, line breaks, etc., so this is to be dealt with with care.

Icons and other graphical elements

Another interesting case which affects the usability of our graphcal interfaces on high-DPI screens is the sizing of icons. We are using standard sizes there, which you access via properties “units.iconSizes.small”, “units.iconSizes.large”, etc.. In Plasma, these sizes now get interpolated with the DPI value of the screen, while making sure the icons are still getting rendered correctly. The sizing is done in steps, and not linearly to avoid getting washed-out icons. This mechanism works well and automatically solves another piece of the puzzle. The result of doing this is a more balanced look and better alignment and spacing across some widgets (notably the battery gains quite a bit of beauty with this treatment).
In other UI elements, especially the toolkitty widgets we provide in PlasmaComponents, we often already scale with the text, which works just fine for reasonably-but-not-excessively high DPI values. We have done some experiments with scaling up the graphical elements that are used to, for example, render a button. As we are using SVG graphics throughout the user interface, we don’t have to resolve to dirty tricks such as doubling pixels, and we can get quite neat results. This needs some more work, and it hasn’t been merged into master yet.

The Higher-Level Picture

Now, having discussed lots of technical details, how does the user-facing side of this look and work? The changes we’ve done right now only affect the user in one way: More UI elements scale with the DPI of the screen, this means no change for displays around 100 DPI. On my laptop (which has a 180 DPI screen), this gives a more balanced picture.
As Plasma is making its way onto a wider range of target devices (think tablets, media centers, as well as high-dpi laptops or monitors), this topic becomes increasinly important. I have good hopes that we will be able to solve this problem in a way that really leverages the power of this kind of hardware. In Plasma Next, we’re now providing some of the basic tools to make UIs work well on high-DPI displays, and we’ll continue this route further on. The user will notice that in Plasma Next, most of the problems that could be seen on high DPI screen are gone, and that the whole behaves much better without many tricks.