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.

Wayland

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.)

Mobile

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.

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.

Multiscreen in Plasma: Improved tools and debugging

cube-small
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.

kcm-videowall
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.
kscreen-doctor

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.

Getting physical

plasma-cernbannerI’ve just finished my travel preparations for this year’s Plasma sprint, which will start tomorrow with the arrival of my fellow hackers in Geneva, CH. Together with a few other groups in KDE and organized by our WikiToLearn friends, we’re honored to be guests at CERN, the European Organization for Nuclear Research where physicists and engineers are probing the fundamental structure of the universe. Of course, these scientists and engineers couldn’t do their work without Plasma, so we’re obliged to hold our meeting there. :-)

Topics range from our Wayland support to Plasma Mobile, documentation, how we can improve our desktop experience, and general planning for the next months. I’m also looking forward to some face-time with my fellow hackers, and discussions with the artists and usability experts who are holding a meeting of the visual design group in KDE. Only good stuff can come out of this.

Many thanks go to all the people who support KDE. This support makes meetings like next week’s possible. Please consider supporting us.

screen config victory!

kscreen wayland backend in action
kscreen wayland backend in action
That moment when the application “just works” after all your unit tests pass…

A really nice experience after working on these low-level bits was firing up the kscreen systemsettings module configured to use my wayland test server. I hadn’t done so in a while, so I didn’t expect much at all. The whole thing just worked right out of the box, however. Every single change I’ve tried had exactly the expected effect.
This screenshot shows Plasma’s screen configuration settings (“kscreen”). The settings module uses the new kwayland backend to communicate with a wayland server (which you can see “running” on the left hand side). That means that another big chunk of getting Plasma Wayland-ready for multi-display use-cases is falling nicely into place.

testing

I’m working on this part of the stack using test-driven development methods, so I write unit tests for every bit of functionality, and then implement and polish the library parts. Something is done when all units tests pass reliably, when others have reviewed the code, when everything works in on the application side, and when I am happy with it.
The unit tests stay in place and are from then on compiled and run through our continuous integration system automatically on every code change. This system yells at us as soon as any of the unit tests breaks or shows problems, so we can fix it right away.

Interestingly, we run the unit tests live against a real wayland server. This test server is implemented using the KWayland library. The server runs headless, so it doesn’t do any rendering of windows, and it just implements the bits interesting for screen management. It’s sort of a mini kwin_wayland, the real kwin will use this exact same library on the server side, so our tests are not entirely synthetical. This wasn’t really possible for X11-based systems, because you can’t just fire up an X server that supports XRandR in automated tests — the machine running the test may not allow you to use its graphics card, if it even has one. It’s very easy to do, however, when using wayland.
Our autotests fire up a wayland server from one of many example configurations. We have a whole set of example configurations that we run tests against, and it’s easy to add more that we want to make sure work correctly. (I’m also thinking about user support, where we can ask to send us a problematic configuration written out to a json file, that we can then add to our unit tests, fix, and ensure that it never breaks again.
The wayland test server is only about 500 lines of relatively simple code, but it provides full functionality for setting up screens using the wayland protocol.

Next steps…

The real kwin_wayland will use the exact same library, on the server as we do in our tests, but instead of using “virtual screens”, it does actually interact with the hardware, for example through libdrm on more sensible system or through libhybris on ones less so.
Kwin takes a more central role in our wayland story, as we move initial mode-setting there, it just makes to have it do run-time mode setting as well.

The next steps are to hook the server side of the protocol up in kwin_wayland’s hardware backends.

In the back of my head are a few new features, which so far had a lower priority — first the core feature set needed to be made stable. There are three things which I’d like to see us doing:

  • per-display scaling — This is an interesting one. I’d love to be able to specify a floating point scaling factor. Wayland’s wl_output interface, which represents the application clients, only provides int-precision. I think that sucks since there is a lot of hardware around where a scaling factor of 1 is to small, and 2 is too high. That’s pretty much everything between 140 and 190 DPI according to my eyesight, your mileage may vary here. I’m wondering if I should go ahead and add the necessary API’s at least on our end of the stack to allow better than integer precision.
    Also, of course we want the scaling be controlled per display (and not globally for all displays, as it is on X11), but that’s in fact already solved by just using wayland semantics — it needs to be fixed on the rendering side now.
  • pre-apply checks — at least the drm backend will allow us to ask it if it will be able to apply a new configuration to the hardware. I’d love to hook that up to the UI, so we can do things like enable or disable the apply button, and warn the user of something that the hardware is not going to like doing.
    The low-level bits have arrived with the new drm infrastructure in the kernel, so we can hook it up in the libraries and the user interface.
  • configuration profiles — it would make sense to allow the user to save configurations for different situations and pick between them. It would be quite easy to allow the user to switch between setups not just through the systemsettings ui, but also for example when connecting or disabling a screen. I an imagine that this could be presented very nicely, and in tune with graphical effects that get their timing juuuuust right when switching between graphics setups. Let’s see how glitch-free we can make it.

Embracing Mobile

At Blue Systems, we have been working on making Plasma shine for a while now. We’ve contributed much to the KDE Frameworks 5 and Plasma 5 projects, and helping with the transition to Qt5. Much of this work has been involving porting, stabilizing and improving existing code. With the new architecture in place, we’ve also worked on new topics, such as Plasma on non-desktop (and non-laptop) devices.

Plasma Mobile on an LG Nexus 5
Plasma Mobile on an LG Nexus 5

This work is coming to fruition now, and we feel that it has reached a point where we want to present it to a more general public. Today we unveil the Plasma Mobile project. Its aim is to offer a Free (as in Freedom), user-friendly, privacy-enabling and customizable platform for mobile devices. Plasma Mobile runs on top of Linux, uses Wayland for rendering graphics and offers a device-specific user interface using the KDE Frameworks and Plasma library and tooling. Plasma Mobile is under development, and not usable by end users now. Missing functionality and stability problems are normal in this phase of development and will be ironed out. Plasma Mobile provides basic functionality and an opportunity for developers to jump in now and shape the mobile platform, and how we use our mobile devices.

As is necessary with development on mobile devices, we’ve not stopped at providing source code that “can be made to work”, rather we’re doing a reference implementation of Plasma Mobile that can be used by those who would like to build a product based on Plasma Mobile on their platform. The reference implementation is based on Kubuntu, which we chose because there is a lot of expertise in our team with Kubuntu, and at Blue Systems we already have continuous builds and package creation in place. Much of the last year was spent getting the hardware to work, and getting our code to boot on a phone. With pride, we’re now announcing the general availability of this project for public contribution. In order to make clear that this is not an in-house project, we have moved the project assets to KDE infrastructure and put under Free software licenses (GPL and LGPL according to KDE’s licensing policies). Plasma Mobile’s reference implementation runs on an LG Nexus 5 smartphone, using an Android kernel, Ubuntu user space and provides an integrated Plasma user interface on top of all that. We also have an x86 version, running on an ExoPC, which can be useful for testing.

Plasma Mobile uses the Wayland display protocol to render the user interface. KWin, Plasma’s window manager and compositor plays a central role. For apps that do not support Wayland, we provide X11 support through the XWayland compatibility layer.

Plasma Mobile is a truly converged user interface. More than 90% of its code is shared with the traditional desktop user interface. The mobile workspace is implemented in the form of a shell or workspace suitable for mobile phones. The shell provides an app launcher, a quick settings panel and a task switcher. Other functionality, such as a dialer, settings, etc. is implemented using specialized components that can be mixed and matched to create a specific user experience or to provide additional functionality — some of them already known from Plasma Desktop.

Architecture diagram of Plasma Mobile
Architecture diagram of Plasma Mobile

Plasma Mobile is developed in a public and open development process. Contributions are welcome and encouraged throughout the process. We do not want to create another walled garden, but an inclusive platform for creation of mobile device user experiences. We do not want to create releases behind closed doors and throw them over the wall once in a while, but create a leveled playing field for contributors to work together and share their work. Plasma Mobile’s code is available on git.kde.org, and its development is discussed on the plasma-devel mailinglist. In the course of Akademy, we have a number of sessions planned to flesh out more and more detailed plans for further development.

With the basic workspace and OS integration work done, we have laid a good base for further development, and for others to get their code to run on Plasma Mobile. More work which is already in our pipeline includes support for running Android applications, which potentially brings a great number of mature apps to Plasma Mobile, better integration with other Plasma Devices, such as your desktop or laptop through KDE Connect, an improved SDK making it very easy to get a full-fledged development environment set up in minutes, and of course more applications.

Say hi to cuttlefish!

Cuttlefish icon previewer
Cuttlefish icon previewer
One of the things I’ve been sorely missing when doing UI design and development was a good way to preview icons. The icon picker which is shipped with KDE Frameworks is quite nice, but for development purposes it lacks a couple of handy features that allow previewing and picking icons based on how they’re rendered.

Over the christmas downtime, I found some spare cycles to sit down and hammer out a basic tool which allows me to streamline that workflow. In the course of writing this little tool, I realised that it’s not only useful for a developer (like me), but also for artists and designers who often work on or with icons. I decided to target these two groups (UI developers and designers) and try to streamline this tool as good as possible for their usecases.

Cuttlefish is the result of that work. It’s a small tool to list, pick and preview icons. It tries to follow the way we render icons in Plasma UIs as close as possible, in order to make the previews as realistic as possible. I have just shown this little tool to a bunch of fellow Plasma hackers here at the sprint, and it was very well received. I’ve collected a few suggestions what to improve, and of course, cuttlefish being brand-new, it still has a few rough edges.

You can get the source code using the following command:

git clone kde:scratch/sebas/cuttlefish
git clone kde:plasmate

and build it with the cmake.

Enjoy cuttlefish!

[Edit] We moved cuttlefish to the Plasmate repository, it’s now part of Plasma’s SDK.

Diving into Plasma’s 2015

Sea anemone with anemone fish
Sea anemone with anemone fish

TL;DR: The coming year is full of challenges, old and new, for the Plasma team. In this post, I’m highlighting end-user readiness, support for Wayland as display server and support for high-dpi displays.

Before you continue reading, have a gratuitous fish! (Photo taken by my fine scuba diving buddy Richard Huisman.)
Next year will be interesting for Plasma. Two things that are lined up are particularly interesting. In 2015, distributions will start shipping Plasma 5 as their default user interface. This is the point where more “oblivious” users will make their first contact with Plasma 5. As we’re navigating through the just-after-a-big-release phase, which I think we’re mastering quite nicely, we approach a state where a desktop that has so many things changed under its hood is becoming a really polished and complete working environment, that feels modern, supports traditional workflows well, and is built on top of a top-notch modern modularized set of libraries, KDE’s Frameworks.

In terms of user demographic, we’re almost certain to see one thing happening with the new Plasma 5 UI, as distros start to ship it by default, this is what these new users are going to see. Not everybody in this group of users is interested in how cool the technology stack lines up, they just want to get their work done and certainly not feel impeded in their daily workflows. This is the target group which we’ve been focusing our work on in months since summer, since the release of Plasma 5.0. Wider group of users sounds pretty abstract, so let’s take some numbers: While Plasma 5 is run by a group of people already, the number of users who get it via Linux distributions is much larger than the group of early adopters. This means by the end of next year, Plasma 5 will be in the hands of millions of users, probably around 10 million, and increasing. (This is interpolated from an estimation of Plasma users in the tens of millions, with the technology adaption lifecycle taken as base.)

The other day, I’ve read on a forum a not particularly well-informed, yet interesting opinion: “Plasma 5 is not for end users, its Wayland support is still not ready”. The Plasma 5 is not for end users, I do actually agree with, in a way. While I know that there is a very sizable group of people that have been having a blast running Plasma since 5.0, when talking about end-users, one needs to look at the cases where it isn’t suitable. For one, these give concrete suggestions what to improve, so they’re important for prioritization. This user feedback channel has been working very well so far, we’ve been receiving hundreds of bug reports, which we could address in one way or another, we have been refining our release and QA processes, and we’ve filled in many smaller and bigger gaps. There’s still much more work to do, but the tendency is exactly right. By ironing out many real-world problems, each of those fixes increases the group of users Plasma is ready for, and improve the base to build a more complete user experience upon.

What’s also true about the statement of the above “commenter on the Internet” is that our Wayland support isn’t ready. It is entirely orthogonal to the “is it ready for end users?” question. Support for Wayland is a feature we’re gradually introducing, very much in a release-early-release-often fashion. I expect our support for this new display server system to reach a point where one can run a full session on top of Wayland in the course of next year. I expect that long-term, most of our users will run the user interface on top of Wayland, effectively deprecating X11. Yet, X11 will stay around for a long time, there’s so much code written on top of X11 APIs that we simply can’t expect it to just vanish from one day to the other. Some Linux distros may switch relatively early, while for Enterprise distros, that switch might only happen in the far future, that doesn’t even count existing installations. That is not a problem, though, since Wayland and X11 support are well encapsulated, and supposed to not get in the way of each other — we do the same trick already on other operating systems, and it’s a proven and working solution.

Then, there’s the mission to finish high-dpi support. High DPI support means rendering a usable UI on displays with more than 200 DPI. That means that UI elements have to scale or be rendered with more detail and fidelity. One approach is to simply scale up everything in every direction by a fixed factor, but while it would get the sizing right, it would also negate any benefit of the increased amount of pixels. Plasma 5 already solves many issues around high-dpi, but not without fiddling, and going over different settings to get them right. Our goal is to support high-dpi displays out of the box, no fiddling, just sensible defaults in case a high dpi display gets connected. As there are 101 corner cases to this, it’s not easy to get right, and will take time and feedback cycles. Qt 5.4, which is around the corner, brings some tools to support these displays better, and we’ll be adjusting our solutions to make use of that.

It seems we are not quite yet running out of interesting topics that make Plasma development a lot of fun. :)

Grumpy wizards

Oxygen Font Example
Oxygen Font Example

In Plasma, we have traditionally relied on the font settings dictated by the distribution we run on. This means that we’ll take whatever “Sans” font the distro has set up (or has left to something else), and worked with that. The results of that were sub-optimal at least, as it meant we had almost no control how things are going to look like for end users. Fonts matter a lot, since they determine how readable the UI is, but also what impression it gives. They also have effect on sizing, and even more so in Plasma Next.

Many widgets’ size in a UI depend on the font: Will this message actually fit into the allowed space for it? (And then: What about a translated version of this message?) In Plasma Next, we’re relying even more on sensible font settings and metrics in order to improve our support for HighDPI displays (displays that have more than 150 dots per inch). To achieve balance in the UI sizing, and to make sizing based on what really matters (how much content fits in there?), we’ve put a much stronger emphasis on fontsize-as-rendered-on-a-given screen. I’ve explained the basic mechanics behind that in an earlier post, so I won’t go into too much detail about that. Suffice to say that the base unit for our sizing is the height of the letter M rendered on the screen. This gives us a good base metric that takes into account the DPI of the screen, but also the preference of the font as set up by the user. In essence, this means that we design UIs to fit a certain number of columns and rows of text (approximately, and with ample dynamic spacing, so also longer translations fit well). It also means that the size of UI elements is not expressed in pixels anymore, and also not relative to the screen resolution, but that you get roughly the same physical size on different displays. This seems to work rather well, and we have gotten little complaints about sizing being off.

Relying on font metrics for low-level sizing units also means that we need the font to actually tell us the truth about its sizing. We need to know for example, how many pixels a given font on a given screen with a given pointsize will take, and we need this font to actually align with these values. This sounds quite logical, but there are fonts out there who don’t do a really good job in telling their metrics. This can lead to over- or undersizes UIs, alignment and margins being off, and a whole bunch of other visual and usability problems. It also looks bad. I find it personally quite frustrating when I see UIs that I or somebody else has spent quite some time on “getting it juuuuuust right”, and then seeing it completely misaligned and wrongly sized, just because some distro didn’t pay enough attention to choose a well-working (by our standards, of course ;)) font.

Oxygen Font in Kickoff Launcher
Oxygen Font in Kickoff Launcher rendered at 180DPI

So, to mitigate these cases, we’ve chosen to be a bit more bold about font selection in Plasma Next. We are now including the Oxygen font and setting it up as default on new installs. This means that we know the defaults work, and they work well across a range of displays and systems. We’re also defaulting to certain renderer settings, so the fonts look as smooth as possible on most machines. This fixes a slew of possible technical issues, but it also has a huge impact on esthetics. By setting a default font, we provide a clearer idea of “with this setup, we feel it’s going to look just right”.

For this, we’ve chosen the Oxygen font, which has been created by Vernon Adams, is released under the SIL Open Font License and has been created under the Google webfonts project. It’s a really beautifully done, modern, simple and clean typeface. It is optimized for rendering with Freetype, and it mainly targets web browsers, desktops, laptops and mobile devices. Vern has created this font for Oxygen and in collaboration with some of the Oxygen designers. The font has actually been around for a while already, but we feel it’s now ready for prime-time, so limelight it is.

As it happens with Free software, this has been a long-lasting itch to scratch for me. One of the first thing I had to do with every install of Plasma (or previously, KDE 3 even), was to change the fonts to something bearable. Imagine finishing the installer, and being greeted with Helvetica — Barf. (And Helvetica isn’t even that bad a font, I’ve seen much worse.) I’m glad we could fix this now in Plasma Next, and I’m confident that this will help many users having a nicer looking desktop without changing anything.

Apart from the technicalities, there will always be users who have a strong preference for a certain font, or setting. For those, we have the font selection in our systemsettings, so you can always set up your personally preferred font. We’re just changing the default.

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.