HighDPI in KDE Applications

Recently I was asked about the state of High DPI in KDE Applications, by someone with a fancy screen.

In Plasma we have our own solution for solving the HighDPI problem, as we were working with new code where we provide the styling, this is all fairly straightforward. However, this doesn't work for applications which have a lot of existing code we need to bring this feature to.

This upcoming release of Qt (5.4) brings us everything we need to support High DPI in our applications. It's not going to be useful for end users just now, but this is a time where we need each and every developer to start getting interested and making sure their applications are ready.

Support requires at least one line of change in every application.

High DPI in Qt

Normally my application, will look something like this. On my screen this is fine,if you see this on a high DPI screen everything will be tiny.

If we change the DPI used in the fonts we, naturally, get bigger fonts. More usable, but all of the other controls are still hilariously small as they haven't changed. This is our current state.

Device Independent Pixels

Qt borrowed a concept used in Android and iOS of separating the pixel sizes we use in the code, to the actual pixel density on the screen.

From a programming perspective we keep coding like everything is in 96dpi like a normal desktop display, but underneath all co-ordinates and graphics will be doubled or quadrupled to scale up to the device resolution.

This API at a Qt level works per screen; with every screen having it's own independent scaling factor. However, in the X backend for Qt 5.4 it's loaded from an environment variable that applies to all screens. Not ideal, but better than nothing.

This gives a result, that is now usable, but very blocky and pixelated.
(you may need to click the image to really see this)

This blockiness problem is also solved. Whenever we create a pixmap we can make sure we provide graphics that have a higher size in device pixels than their size in user space.

To quote the QPixmap documentation, "For example, painting on a 200x200 image if with a ratio of 2.0 will result in effective (device-independent) painting bounds of 100x100.".

With "pixel" now meaning one of two things can get confusing very quickly.

As you might imagine, all of this wizardry under the scenes means it's moderated likely to break at least some applications. As Qt follows the rule of never breaking existing application it requires each and every application to opt in.

I added a command line flag --highdpi to oxygen-demo, the application in the screenshots, to enable the scaling support and test both side-by-side which finally leaves us with:

There were no additional changes to oxygen demo to make this work yet we see we're using high resolution pixmaps on the icons and on the clear buttons in the text field.

How to make sure your app works with Qt's high DPI

1) Port to Qt5
If you're putting it off porting because you're scared of regressions. The reality is over time you will have more bugs from not porting. Without Qt5 we don't get /any/ scaling. Not even the blocky version.

2) Opt in to the high DPI pixmap support

app.setAttribute(Qt::AA_UseHighDpiPixmaps, true);

to your main function

3) Port code
If you don't do any low level work with unusual QPainter painting, provide any of your own pixmaps or load textures in QQuickItems, everything will just work.

Most likely your app will have something broken. Useful links are here and here.

4) Test
I only have a poor person's screen, but it's still easy(ish) to test:

  • Change the DPI under system settings -> font -> force font DPI to 192
  • Set the environment variable QT_DEVICE_PIXEL_RATIO=2

On a normal screen everything will appear massive, but hopefully also super smooth.

My new library: Qlogind

What is it?

A high level wrapper round logind.

We are starting to use logind in numerous places; I need it in SDDM to track sessions. we have code in ksmserver to track Lock/Unlock signals, as well as in the kworkspace library to list sessions. It's coming into KWin for device hardware access as well as being used in solid.

The need for a library

Often we can simply automatically generate bindings at compile time using qdbusxml2cpp that turns DBus interface annotation into working code.

Unfortunately that doesn't work here for a few reasons.

qdbusxml2cpp and QDBusAbstractInterface are both really outdated; and don't know how to handle org.freedesktop.DBus.Properties.PropertiesChanged. Logind uses this method as the only way to notify of any changes, and in fact even introduced their own new type of changed signal annotation without these change signals it becomes near impossible to use.

To solve this, and a few other minor issues this repository contains a fork of qdbusxml2xpp and QDBusAbstractInterface with property caching and no blocking methods anywhere.

Ideally I want to push my changes upstream, but I always like to prototype code before committing to new API especially with Qt. Also we're going to need these changes before Qt5.5.

There are some other usages for a library, there are some changes needed to make to the annotation to make it compile (logind has a property called "class", funnily enough the c++ compiler does not like this) as well as code to demarshall complex types.

From personal experience having a good wrapper library can make a lot of development easier as we can write a higher level API on top to ease fetching multiple queries asynchronously.


I've tried to make the code as easy to use in an asynchronous way, without the user having to write chains of lambdas.


    PendingSession* ps = Session::sessionFromPid(QCoreApplication::applicationPid());
    QObject::connect(ps, &PendingSession::finished, [=](){
        SessionPtr session = ps->interface();
        if (session->active()) {
            qDebug() << "Session " << session->id(); << "is active";

This code internally both a call to Login1.Manager to find the session path for a PID then requesting Properties.GetAll on the Session object in one handy KJob like API.

Where is the code

Code is availabe at git://anongit.kde.org/scratch/davidedmundson/qlogind.git

Current State

It's not quite finished, I only started this 2 working days ago. It needs namespacing, d-pointers and unit tests.

I wanted to write a blog post to get the people who might need to use this to have a look and give some feedback if there's anything missing.

Display Managers In Plasma 5

The last blog posts about KDM/LightDM/SDDM/WhateverDM left things a bit on an exciting cliffhanger so I've been asked a few times what the current state is.

The short summary is we recommend SDDM as the display manager for Plasma 5.


KDM was dropped from Plasma 5. KDM includes code from XDM dating back to 1988! It had served it's job well. However, we're now at a point where we need the backend to be Wayland ready and we want to use more modern QML in the front end. When you have to replace both the back and front ends, it's a sign to just start from scratch.

There was some work done 2 years ago into sharing code with LightDM. In the meantime a separate project was started, SDDM which is (yet another) display manager.

Although personally I was very happy with what we had with LightDM it definitely doesn't make sense to split resources, so we focussed everything on SDDM and I have been helping work on that transferring knowledge from my old project.

Plasma Integration

SDDM is itself in Github and usage is shared with other desktop enviroments, in particular Maui. This makes it harder to add Plasma integration in the code itself, but we've managed nonetheless.

The visual design group made some mockups of a new display manager, which became the basis for the implementation of our login screen.

This is shipped with plasma-workspace. It is up to distributions to update /etc/sddm.conf to update the default theme on installation as it's not something we can do from our code.

In addition we also provide a configuration module that fits into SystemSettings. This is now back in the KDE repositories and will be included in Plasma 5.2.

Naturally Plasma can still work with any display manager as half of the point of having a display manager is to allow choosing which session to launch.

KDE Telepathy 0.9.0 Released

Today we released the 0.9 series of KDE Telepathy, a multiprotocol instant messaging client for Plasma.

Amongst the many bugfixes the following features are worth highlighting.

OTR Encryption

One of the most recurring feature requests we've seen over the years was OTR encryption. OTR builds an extra level of encryption on top of the existing protocol embedding all data in the mesasges themselves. This prevents any potential sniffing from the server as well as providing perfect forward secrecy and non-deniable authentication

This summer Marcin Ziemski volunteered to step up to the task and implemented full support for OTR3, including shared secret authentication and key management.

A full video can be seen here

Group Chats

All aspects of group chats recieved a massive overhaul, there is a new join chat dialog, one can stay logged into a room when you close the window and we've redesigned the main chat window to be easier when talking to multiple people.

Video Calls Revisited

Video calls have had both a technical and UI overhaul. Diane Trout ported a lot of QtGstreamer and the CallUI to GStreamer 1.0.

This port allowing us to future proof for the new technologies and have more chance of working calls.

In addition Ekaitz Zárraga has rehauled the UI bringing it into the 21st century which can be seen in the screenshot.

We encourage you to try it out. Depending on your and your partner's setup, you might now have a good video chat experience. For best results use a real jabber server (Not Facebook or Google!) the same client and be sure to have all GStreamer codecs installed.

Speed Improvements and Bug Fixing

Naturally the release brings a slew of bug fixes and improvements not listed here. Specificially the contact list has undergone extensive profiling and optimising since 0.8.


You may notice some of the features were highlighted in the report from our previous sprint report. If you like the new features be sure to contribute to our winter fundraiser so we can keep doing sprints in future.

Is Plasma 5 Ready For "Normal Users"?

I keep seeing the same question on a lot of the social media sites so I want to write a blog post covering everything.

When we released Plasma 5.0 we had gone through a lot of large technical changes throughout the stack. It was expected that there are some regressions, either from bugs or simply some minor components not being priorities as being needed in the first release.

I'm a normal user, is it ready for me?

There is no such thing as a "normal" user. Everyone is different and what is rock solid 100% stable to one person may be very problematic for another. This makes it very hard to give a single answer.

A good example of this was translations. Due to some changes in frameworks when we released Plasma 5.0, we made a very poor job of translation loading and a sizeable amount didn't work properly. Most developers tend to run things in English even when they're across the world and it simply fell through the cracks till it was too late (fixed for 5.1).

If you're a user who uses KDE in English, this naturally isn't a problem that would affect you. If you only speak German this would be a complete showstopper that would make you absolutely hate the 5.0 release.

This same philosophy applies screen hotplugging or specific graphics hardware or RTL layouts. It might be a massive problem, you might find everything works perfectly.

To determine if Plasma 5.1 is "ready for you" the only real option is to try it.

It might seem like it would be a good idea to keep the project in beta until there are no regressions but under open development it simply doesn't work.

We don't get the level of developer and user interest we need to catch and fix all regressions without a release. There's a common mantra "release early, release often" for a reason.

It's also worth remembering that whilst we have some regressions, we also fix a lot of things and it's important that users can chose to reap those benefits.

When will it be in distributions?

Everyone is being very conservative with our 5.x release mostly due to historical reasons of other major releases; Kubuntu in a few weeks will release two ISOs one with classic KDE SC 4, and the other with Plasma 5.

When can I get rid of Qt4?

I've seen a few people suggesting that they can't upgrade as there aren't any applications released on Frameworks 5 yet.

We have put a lot of effort into making sure Qt4 applications fit in natively with Plamsa 5. We make sure system setting syncs as many changes as possible and we have even backported the latest theme so that applications fit in natively. It's near impossible to tell the two apart.

The original plan has always been that we will release applications slowly after the workspace is ported.
Trying to remove Qt4 applications immediately is not the plan, nor is it encouraged by us.

Wrap up

Personally I've been using Plasma 5 in development for 9 months, and I am so accustomed to any remaining issues that I massively prefer it over what we had in 4.x.

From 5.1 I would be comfortable recommending upgrading to users who use KDE casually at home.

Making Plasma better

If you want Plasma to be better as soon as possible remember to join us in #plasma on freenode and contribute.

Also we are starting our year end fundraiser more sprints will result in more fixes, faster.

KDE Telepathy 0.9-beta

We have released a beta of KDE Telepathy 0.9, and libkpeople 0.3.0

Features include:

  • OTR
  • Improved group chats
  • Modernised video chats, now based on GStreamer 1.0
  • Lots of fixes and speed improvements

Tarballs are available here and here.

If you're interested in developing and contributing follow our quick start git installation guide

Please report back any bugs so we can make 0.9.0 a great release.

An update on Plasma Addons

Since my last blog post on plasma addons there has been a lot of activity, existing contributors are active on their own plasmoids, and there are many new faces coming on to take up the challenge of maintaining their own small part of Plasma.

What's been happening

All Plasma 5 development has moved to the master branch, ready for the 5.1 release.

Aleix Pol finished porting the quickshare applet which allows uploading text and images to a pastebin server by clicking and dragging. Xuetian Weng completed the Input panel plasmoid, that allows for entering chinese characters and Kai Broulik finished the Fuzzy Clock plasmoid. I started the notes plasmoid, which is close to being ready for review.

The VDG have been active in designing the ported applets, with the help of kver the system load viewer applet changed significantly:

A small bit of polish makes a huge difference to the end result, and Martin Yrjölä has been leading the porting process of that.

Spring cleaning

We are constantly adding new things so it's important to clean out old code at the same rate. We need to remove applets that failed to be maintained, or are simply gathering dust and only invest porting effort in what is useful.

With this I am sad (well, not really) to announce:

We've dropped the bouncy ball!

I know several people liked this applet but when trying to develop a professional experience toys and gimicks aren't a good thing to be shipping by default. The user's desktop is not a showcase for us to experiment with.

That isn't to say we want to police what people make and use, developers are still able to distribute all content through kde-look or other services, we are just making the most of our main distribution channels.

Getting involved

There are still several plasmoids that we want to have available to Plasma 5 users, that are seeking maintainers. Unless people step up to both port and maintain them, it won't happen. So if there's anything you use regularly and miss, please look at the TODO and talk to us on #plasma.

Randa Part 1: Gwenview on Frameworks

In the first few days at Randa as a coding task between meetings I took on porting one of the larger core applications to Qt5 + KF5. Having applications on Qt5 is not only important for when we make the wayland move as they can run natively but it also ups the motivation to add new features into Frameworks and move technology forwards.

I decided to take on Gwenview because the maintainer, Aurélien, is on a break from KDE and requested somebody took over the task. When I started in KDE Aurélien was one of the coders I most looked up to, so I wanted to pay back and make sure his work lived on.

The screenshot below shows Gwenview ported to KDE Frameworks 5.

Everything is now pushed to the master branch. The core loads, but there's quite a lot of warnings where we haven't ported away from the KDE4 support libraries; it's a great opportunity to get involved on some simple code fixes. Message me if you want to help out.

If anyone is else looking at porting make sure to make full use of Montel Laurent's excellent scripts in kde-dev-scripts. They make a massively painful task only slightly inconvenient.

Plasma Addons - Where we are in Plasma5

When we were building towards 5.0, we made the choice to focus all the effort on the core, and not release plasma-addons. It would have been simply too much work and quality of the core would have suffered.

The intention was to start bringing them back from 5.1, which will be in approximately 2 months from now.

The amount of stuff in plasma addons is huge. This screenshot shows only a small sample:

My genuine KDE4 desktop

The Plasma Addons is a very mixed bunch of code, it contains some useful tools that really improve productivity such as quickshare, notes and icontasks. However, it also contains broken code, duplicates, tech demos and a range of toys and gimmicks of questionable value.

These things are fine to have these available as internet downloadable extras, but should they form part of an official addons?

It becomes a tricky question, we want to provide a quality professional experience to a user, but we also don't want to stifle developer creativity and we want to give our devs an even platform to distribute their work.

Due to the nature of the changes we made in Plasma4->Plasma5, in many cases the porting invovles a complete rewrite of the code base. It's therefore a good opportunity to give the repository a spring clean, so we only intent to port things that will be picked up by a dedicated maintainer and not port everything for the sake of porting.

Getting Involved

As each plasmoid is very standalone, it's a good opportunity to get involved in development. If you have a personal attachment to a plasmoid that you use on a regular basis, we would love people to step up to port and maintain it.

We have a tracking board here:

If you want to take any tasks, ping me (d_ed) on #plasma on Freenode or email the plasma-devel mailing list.

A Wallpaper Plugin Demo For Plasma 5.

As part of the core Plasma team I have spent a long time helping in the migration to make everything QtQuick2.0 based, making sure we get the most out of the OpenGL backing.

This weekend I wanted to make some sort of demo which shows the power of this in the form of an interactive wallpaper.

Clicking on the desktop simulates a firework at that location. Frantic clicking will simulate the entirety of November the 5th (or July the 4th for people across the pond). When not active the whole thing only uses as much resources as any regular static wallpaper.


Download the complete zipfile here.

Install with the command line

plasmapkg2 -t wallpaperplugin -i fireworks.zip

Then under "Desktop Settings" change the wallpaper type to "fireworks".

Why on Earth would I want this nonsense on my desktop?

Realistically this isn't something that would ever go in the default desktop installation. However by getting good at silly initiatives, we build and optimise for useful things; smooth subtle animations and shadows where it's actually useful.

I want to make something like that!

The actual source code is fairly straightforward.
The QML Particle system is very much like the particle system found in Blender (The main similarity being that I don't understand how to use the particle system in Blender) with emitters and affectors.

In this case a circular emitter forms the base of the firework emitting a burst of coloured particles in all directions; a trail emitter then follows each coloured particles emitting a spread of small white particles to create a sparkly trail effect.

With the power of particles, sprites and even embedding other OpenGL framebuffers, I encourage more people to write some interesting interactive wallpapers.