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

10 thoughts on “Diving into Plasma’s 2015

  1. Hi, any plans to KDE improve support for BSD systems? BSD has not udev, then Wayland was ported but wasn’t tested yet…then BSD gonna support X11 for while. ConsoleKit is forked as ConsoleKit2 here https://github.com/ConsoleKit2/ConsoleKit2 , so KDE could still support ConsoleKit instead logind for those who doesn’t wanna use systemd or doesn’t have systemd.

    1. The Plasma team currently doesn’t have any developers using BSD and doesn’t have the resources to provide platform specific solutions. If BSD users/developers are interested in e.g. ConsoleKit2 they should look into providng patches for it.

  2. I hope that the support for high-dpi out of the box means it’s also easy to take advantage of the extra pixels to show more information on the screen. I’m typing this on a 170 dpi laptop, and the comment text at 11 px is still easily readable if I zoom out to 50%. It would be nice if it’s easy to keep the same pixel dimensions on a 300 dpi screen, too, and see more at once. I’ve run into issues before where a high vertical pixel count screen causes KDE’s mouse cursor to become enormous until I select a non-scaling cursor.

  3. Definitely excited for you guys to get full HiDPI support soon. I’ve been waiting on getting a 4k display because the current support is severely lacking from my experience with KDE4 on my MBP with retina display. I was hoping to get rid of OS X but no can do just yet.

    If you guys need alpha/beta testers let me know. As long as I can run from USB I could help out.

  4. Well that consoleKit2 is a one man project a few days old, I don’t see where KDE should even consider this for now.
    Also Martin Graesslin mentioned a few thing on his blog about BSD, may have a look there.

    1. It looks like he is going to provide the logind dbus api, so I don’t think KDE should have to do anything to support it afaik.

  5. I’m hoping the HiDPI support will allow me to scale up the size of the UI so that my ageing eyes find it easier to read the screen. Being able to nudge the size up a 1% at a time would be wonderful and the HiDPI screen should mean that is possible without nasty artefacts.

    1. That’s part of the solution, but not a complete one (the above works for scaling something up that is scalable already). We also need to detect high dpi displays and adjust font size, make it known to QWidget-based apps, make sure larger assets are loading to prevent scaling artifacts, fix hard-coded pixel sizes, etc..

Comments are closed.