Last month in Plasma

We’re nearly a third of our way into the Plasma 5.4 cycle, most of the developers seem to be shy so I wanted to give a summary of just some of the activity.

The focus

With Plasma 5 now hitting major distributions by default our biggest focus is bug fixing. We get roughly 10 new bugs every day, each of which have to triaged, and if appropriate fixed. Somehow we’re managing to stay on top of things.

KCM Rewrites

System Settings is one of the older parts of the Plasma stack

Antonis and Marco have been working on porting some of the modules to use QML with QtQuickControls.

This poses an interesting challenge; QtQuickControls are definitely the future of not only Plasma but for all KDE applications, however, in their current state they are problematic. The desktop theme has various quirks, as it tries to interact with the classic QStyle and we don’t benfit from the same huge sets of KDE libraries that were written for widgets.

We need to find a balance between modernising, progressing with new technology, but also never hampering the user experience for the sake “progress”.

For now these are merged in a development branch of plasma-desktop, KcmQmlPorts. I’d encourage people to check it out and report and fix issues there.

Extra Plasmoid Changes

Bernhard Friedreich has been restoring all the functionality in the timer applet that wasn’t prioritised in the initial rewrite from Plasma 4. It now is in a far better state than it has ever been.

The task manager gained a feature from Yoann Laissus to allow launching a new instance of an application by middle clicking. Hopefully speeding up some people’s workflow.

Wonko Sane ported the Konsole quick launch applet too Plasma 5 allowing users to quickly start various different konsole sessions right from their desktop.

We’re also seeing a lot happen in the “3rd party” world on kde-look. There are now 2 pages worth of additional applets that people are making. Worth checking out.

Helping out

We’ve had a lot of new faces in Plasma
We’ve been updating our build instructions, which walks through building all of frameworks on Plasma into a new directory, in simple instructions that work perfectly on all non-Debian based distributions.

Hidden – copy this to the dot

Plasma Sprint 2015

In February 2015 the Plasma developers met in the Blue Systems office in Barcelona to discuss and plan out where we would take Plasma over the duration of the next year. The sprint consisted of active Plasma develoeprs and visual designers from around the world; from Canada to India.

The meeting consisted of equal parts hacking and group discussions about plans both in the near and far future in breakout sessions throughout the week.

Hacking

Improved Developer Tools

One of the important parts of Plasma is making it as easy for others to contribute as possible. Marco worked on a tool making it easy for designers to explore, edit, create and assess the completeness of Plasma themes. Sebastian introduced “Cuttlefish”, a tool for designers and application developers to examine the current icon set of a system. It can be used to display the icons available on the system, and how they are presented at various sizes. Both of these should make it into the next release of Plasmate.

Enhanced Power Management

Good power management has always been a fundamental part of the Plasma experience, during the sprint we experimented with restoring kinfocenter to life to be a useful central hub of advanced information. This allows us to provide all sorts of extra information without cluttering the main desktop. This will make it possible to visually identify where your battery life is going.

In addition, several tweaks were made to the battery notifications and timeouts.

Plasma Media Center

Plasmashell was modified to allow it to boot directly into media center mode, allowing it to be launched directly from the login screen.

Design work

During the hacking time, designers Jens and Ken began producing and designing additional promotional material for our upcoming marketing needs. This included updated logos, vectorised Konquis, and other assets.

Planning For The Future

Much of the sprint was spent planning out future goals, a new framework for sharing actions and invoking actions across applications, called KPurpose which we should hear more of in upcoming releases. We discussed the future of notifications for not only current instant notifications but calendar based alerts.

Work and initial prototyping went into unifying application header space and making use of window decoration space in applications.

Hopefully over the next years of Plasma we will see these features come to life in future release release announcements. Exciting times lie ahead.

Akademy 2015 Call For Papers Reminder

The call for papers for Akademy 2015 is on the 31st of March, which is scarcely over a week away.

If you want to talk at Akademy it is important to submit your application on time.

We have a large number of short and lightning talks available again this year, which is a fantastic opportunity to give everyone a brief overview of what’s been happening in your project over the past year. I would like to see every active project presenting something.

Don’t leave it too late and miss out.

Instructions on how to submit can be found at https://akademy.kde.org/2015/cfp.

Plasmoid Tutorial 3 – Blending In

Till now we have dealt with basic QtQuick Text items. Whilst they work, they will look out of place on a Plasma desktop. More importantly it’s quite likely that you can get a situation where you can get black text on a black background, or another unreadable combination.

If we run our current applet as soon as we change to another theme we get a problem.

We want to have consistent visual style amongst plasmoids that follows the user’s themes, along with consistent spacing throughout the shell. We want all “third party” plasmoids to follow these rules too.

We provide a set of imports that help make this happen.

The visual Plasma import come under 3 categories:

org.kde.plasma.core

This contain low level shapes; such as varying frames, SVG loading and icons, as well as a utility to get DPI independent sizes to use for spacing and other metrics. Useful for keeping things consistent.

org.kde.plasma.components

This contains the standard set of “widgets”; text boxes, spin boxes and labels and much more.

org.kde.plasma.extras

This is extra utilities that may be useful in your plasmoid.

Best Practices

  • Avoid hardcoding fonts and colours. Use the ones from the user’s theme.
    If you must hardcode, make sure you never hardcode on top of a theme background or parts could end up unreadable.
  • Avoid using the Text element from the QtQuick import, instead use Label from Plasma components, it will set the right fonts and sizes automatically.
  • Do not adjust font sizes and styles. For headings use the Plasma Heading element with the appropriate level set to affect font size.
  • Set all animations to Theme.ShortAnimation or Theme.LongAnimation as appropriate.
  • Don’t use QtQuick.Controls directly from inside the main plasmoid view

Continuing The RSS Viewer example

If we apply that to our current RSS viewer, our main view code should end up looking something like this:

import QtQuick 2.0
import org.kde.plasma.core 2.0 as PlasmaCore
import org.kde.plasma.components 2.0 as PlasmaComponents
import org.kde.plasma.extras 2.0 as PlasmaExtras


Item {
    PlasmaExtras.ScrollArea {
        anchors.fill: parent
        ListView {
            id: mainList
            focus: true
            boundsBehavior: Flickable.StopAtBounds

            model: RssModel {
                id: rssModel
                source: "http://planetkde.org/rss20.xml"
            }

            delegate: PlasmaComponents.ListItem {
                PlasmaComponents.Label {
                    anchors.left: parent.left
                    anchors.right: parent.right
                    height: implicitHeight

                    elide: Text.ElideRight
                    text: model.title

                }
                MouseArea {
                    anchors.fill: parent
                    onClicked: Qt.openUrlExternally(model.link)
                }
            }
        }
    }

    PlasmaComponents.BusyIndicator {
        anchors.centerIn: parent
        //whilst the model is loading, stay visible
        //we use opacity rather than visible to force an animation
        opacity: rssModel.loading ? 1: 0

        Behavior on opacity {
            PropertyAnimation {
                //this comes from PlasmaCore
                duration: units.shortDuration
            }
        }
    }
}

I’ve added a busy indicator (a spinning wheel) whilst we’re fetching the RSS feed, just as a way to show how we use units.ShortAnimation

Finally, we end up with something like this: which looks good on all Plasma themes.

Plasmoid Tutorial 2 – Getting Data

Almost all applets need to interact with external data sources and actions.

This could be showing the current battery state, editing a file or in the case of our example monitoring and fetching an RSS feed.

Within Plasmoids we have a few different ways of getting data. Each have some advantages and disadvantages.

I’m going to loosely touch on them all, hopefully providing links to find out more information on a topic.

In-built javascript

QML is all powered by a javascript engine and as we’ve seen in the web world a lot is powerful with just javascript.

We have access to a full XMLHttpRequest object, which behaves exactly the same as making AJAX calls in any other web page.


    Component.onCompleted: {
        var request = new XMLHttpRequest();
        request.onreadystatechange = function() {
            if (request.readyState == XMLHttpRequest.DONE) {
                var reply = request.responseXML.documentElement
                //do the sort of thing that web developers normally do
            }
        }
        request.open("GET", "http://example.com/something");
        request.send();
    }

It’s simple-ish, particularly if you are coming from a web developer world.

QML Plugins from C++

Sometimes we need to make our own modules if we want to access existing libraries, or do fast processing or interact with hardware.

QML integrates natively with C++ amazingly, every QObject in C++ appears as a javascript object. We can create new instances, all properties, signals and invokable methods or slots are visible to the JS engine as properties and methods.

as an example if I have a QObject with the structure

class MyObject: public QObject
{
    Q_PROPERTY(QString someProperty READ someProperty CONSTANT);
    Q_OBJECT
public:
    QString someProperty() const;
};

qmlRegisterType("MyLibrary", 1, 0 "MyObject");

from QML I can access it as follows.

MyObject {
  id: source
}

Text {
  text: source.someProperty
}

More information on writing plugins can be seen here

As you can see C++ plugins give you maximum integration, anything is possible, including creating new graphical types, models, or enums or anything else you might need to use in QML.
Unfortunately distribution is harder as it needs parts to be compiled.

Note that Qt provide several QML modules a full list of imports can be found here.

Including an XMLListModel that converts an XML feed into a model that can be used QtQuick, which is ideal for our tutorial of making a simple RSS reader.

Dataengines

Dataengines were an abstraction layer for fetching and data and performing actions used in Plasma 4. They provide a lanaguage agnostic method of providing data to a Plasmoid.

Dataengines made sense when we needed to be agnostic between various lanaguages; now QML is here to stay for a long long time this requirement vanishes. Writing a QML Plugin has numerous advantages over dataengines as you remove away a very limiting abstraction layer. QML Plugins allow exporting new types and enums and overall requires a lot less boiler plate code than dataengines.

However, if a dataengine already exists it totally makes sense to re-use it rather than rewriting the code from scratch, they have been honed over years of fixes and many are quite good.

For our RSS case, their is an RSS dataengine backed by libsyndication which is way more powerful than everything here as it handles every type of feed.
Unfortuantely at the time of writing this is blocked on PIM releasing.

plasmaengineexplorer provides a way to browse dataengines and contents.

High DPI Progress

High DPI Revisited

A few weeks ago I talked about high DPI in KDE applications

Abridged Recap

  • By settings QT_DEVICE_PIXEL_RATIO=2 Qt will scale all painting to draw things twice the size
  • By default this will just scale all our images so it slightly defeats the point of buying a fancy new high resolution screen
  • Qt can try and be clever and draw high resolution icons and other images
  • This is liable to break stuff, so requires each and every app to opt-in

Progress

On Monday this week I was loaned a high resolution laptop, and set about trying to make sure everything works perfectly within the KDE world.
We can now set this environment variable from a configuration file, and a user interface is in review to allow the user to manually set their scaling factor.

I then set about trying to enable high resolution image support in various applications and trying to fix all that is broken.

This task is two-fold. The first is fixing any bugs that result in simply enabling the high resolution icons. Second is making sure applications that provide their own images, do so in a way that still look spot on when used on a high resolution monitor.

Progress Screenshots

Here is my screenshot just after installing Kubuntu CI on a high resolution laptop (3800×1800).

We can correct some parts by just boosting the font size, but that doesn’t solve the problems of small checkboxes, buttons and other hit areas. This isn’t just a superficial problem and it becomes a major usability problem especially as these screens become more widespread.

This second screenshot shows the result with the device pixel ratio set and a weeks worth of fixing in a range of apps. (click for full size)

The most obvious thing is that the sizes are bigger, but more importantly this is happening whilst all icons and scrollbars remain crystal clear at the native resolution for that screen.

A zoomed in section looks like this:

Current Status

Every Qt5 app can double up with no work at all, but to look right requires some effort.

For some applications supporting high DPI has been easy. It is a single one line in KWrite, and suddenly all icons look spot on with no regressions. For applications such as Dolphin which do a lot more graphical tasks, this has not been so trivial. There are a lot of images involved, and a lot of complicated code around caching these which conflicts with the high resolution support without some further work.

I am tracking progress on a Kanboard page. Naturally I can’t do every application, but I hope that by checking a few I can make sure all of our frameworks have full support making it easy for every other developer.

We also have a problem that Qt4 applications do not support device independent pixels. There are still many applications without a frameworks release even in the upcoming 15.04 applications release. Even in the next applications release in 15.08 August we are still unlikely to see a released PIM stack.
Is it a good idea to add an option into our UIs that improves some applications at the cost of consistency? It’s not an easy answer.

Help fix up all of System Settings

System Settings is a strange part of Plasma; it composes of umpteen modules gradually written over the last 15 years by a lot of different people.

As each configuration module is generally small and self-contained it doesn’t take a lot of continual maintenance so when a developer becomes inactive we tend not to notice.

Unfortunately over time we’ve seen the number of open tickets on system settings modules increase over time. They get left unsorted as it’s “someone elses problem”.

This leads to things falling between the cracks, particularly for finding the Plasma 5 / Frameworks regressions as we can’t see the real issues through the noise of all the duplicates, outdated bugs and frankly bad ideas.

Whilst I’m doing Plasma this isn’t a trend that is going to continue.

I’ve spent the last week of evenings triaging system settings tickets and fixing up some of the most important bugs.

I need some help on going through the remaining bugs, my personal target is to get the total number of open tickets down to 400 by the end of February.

If you want to help out join us in #kde-quality on Freenode and we can co-ordinate some triage and split out some of fixing, making Plasma a polished experience once again.

A list of bugs split by component can be found here.

How does systemd relate to Plasma?

In some of the comments about the latest Plasma release sometimes someone brings up the topic of systemd. This is normally met with the rebuttal “Why should a desktop environment care about what init sytstem is used?”.

It’s a very sensible question, but it’s also one that’s easily answered. I wanted to explain how different parts of systemd relate to Plasma.

The init system

We don’t care. It doesn’t affect us.

The init system is one part of systemd that doesn’t affect us at all, and any other could be used.

Logind

Logind is a tiny daemon that keeps track of seats and sessions on your machine.

In principle it’s very simple, every login (including autologin) goes via PAM (Pluggable Authentication Modules) modules; a special PAM module signals to a central daemon that a new session is started and tell it when it stops.

This blog series has the most detail on session tracking and why logind solves problems better.

We need knowledge of all active sessions from within Plasma to be able to offer session switching inside the UI and to warn the user if they attempt to shutdown whilst other sessions are still active.

This class kdisplaymanager in plasma-workspace shows our abstraction layer growing since 2004; it currently has Logind support but as we have been adding to a constantly broken abstraction layer it’s used very badly. It has tracking code for over 5 different systems (KDM, old GDM, new GDM (which is now old), consolekit, org.freedesktop.DisplayManager, and now logind) and is probably one of the ugliest pieces of code in Plasma.

Logind does seem to solve these problems better, particularly with regards to multi-seat and the other features it provides.

We need to tidy this area, having an abstraction layer only leaves us with a lowest common denominator, and it isn’t pretty.

When people reference standards, someone will cite XKCD, I think more of it like this:

Device Management

Logind allows the session leader to open input devices which are otherwise only available to root.
This allows kwin to monitor key and mouse events whilst blocking other applications from sniffing your keystrokes.

Martin Graesslin’s blog explains this in more detail.

Inhibitor Locks

One other feature logind provides that we are making use of is inhibition locks.

Upower will notify us when the system is about to be suspended. Which sounds ideal, we should be able to react to that and perform pre-suspend tasks. Unfortunately it’s not very useful as the system is shutdown before it finishes.

When logind is asked to suspend, it will inform all applications which have requested a delay. It will then wait for up to 30s for all apps to respond that they have finished their pre suspend tasks.

This allows us to make sure the lock screen is completely up and running before we suspend the system; so you don’t have that jarring and insecure moment where you open your laptop and it is still showing the original contents before the lock screen finally loads.

We even use this feature from Telepathy, the instant messaging system. In order to save bandwidth most IM protocols aren’t constantly sending data The problem is when we disconnect it will take a long time for the server to notice and update your status. We have an inhibition delay that gives us a very small window to shout to all the servers “we’re going offline now”.

Timedated and Friends

Systemd also comes with a set of utilities for performing some system administration utilities, such as changing the hostname, timezone, locale and such.

What makes these interesting is that the components are split into two parts; a small command line client but more importantly a defined DBus interface to a small DBus activated daemon that uses polkit for authorisation and does the actual changes.

This approach is similar to what we do in our date and time config module; we have our GUI and we also have a small helper app that’s DBus activated and runs as root which we are shipping ourselves. Our helper app then runs one of 6 different ntp programs; almost all of which are now outdated.

We don’t want to be writing code that runs as root and as a user you really don’t want us to be doing so.

By using a defined DBus interface we are able to share this code between desktops and share safe audited code for all root access.

Naturally this not only applies for timedated, but also hostnamed, machined and whatever else might come in the future.

Change Monitoring

In addition timedated, the systemd interface for changing the time, emits signals whenever it changes the timezone.

Currently in order to achieve the same effect we have a constantly running daemon that monitors /etc/localtime for file changes and then emits DBus signals for all the other apps.

If we could rely on everyone setting the timezone through timedated we can remove this watch which will free some resources for everyone.

What else could we make use of?

There are a few other places where embracing systemd adds functionality or makes code simpler; our system guard can show which seat and which container an application is running on. I already wrote a patch for this, but got bored #ifdef-ing everything.

Using a common storage for log files means ksystemlog could be restored to a working product again.

User Units

Last but not least we have user units.

Currently init is handled by a rather cumbersome shell script. It’s as simple as starting the KDE services in order in a list.

User Units allow Plasma services to use the same features as available to system daemons.

Most obviously we get the faster bootup as we are able to parallelise component startup, but there are more benefits.

Systemd provides services to restart crashing applications with finer control, a watchdog can detect a hung application or if a process gets out of control using too much resources and restart it automatically. Logging will also be greatly improved; faster to run and easier to supply developers with relevant information instead of a giant .xsession-errors file.

A trial has been started here providing user units; which when ready will work their way into the main plasma-workspace.

Longer term, we can investigate replacing parts of kded, the KDE daemon with systemd directly, providing a single common way to manage all services.

Conclusions

Hopefully it clears up what we mean when we talk about systemd and desktop environments, and where we could use different parts of systemd.

It should be apparent that as developers there are parts we want to embrace as it. In many cases it allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it as an optional extra defeats the main benefit.

As maintainers we have a duty to balance what will provide the best experience for the majority of our Plasma users without leaving anyone with a broken system. Projects like this bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features.

Plasmoid Tutorial 1

With Plasma 5.2 out I wanted to update the tutorials on how to write a Plasmoid. Going through all of the steps from hello world, to using Plasma Components to configuration through to differing form factors.

It made sense to publish them as blog posts before I copy them to the wiki.

Behold, the first rather wordy blog post in a series of 7.

Intro

With Plasma5 we have embraced QML as our technology of choice. It is the only method of writing the UI for plasmoids.

Whilst Plasma4 offered a range of language, QML is the only way of interacting with QtQuick, the technology that powers the Plasma Shell. By using this we we get to provide a better developer experience as there is a wealth of existing QML resources. Some of the best links are:

  • http://doc.qt.io/qt-5/qml-tutorial1.html
  • http://qmlbook.org/

Before you get started with writing plasmoids, it is recommended to read through the basics of these and have a bit of playing to get used to the language.

Writing plasmoids is effectively the same as writing any other QtQuick QML, with a few extensions:

  • We have a specific folder structure with metadata for our plasmashell to be able to load the files.
  • We provide a massive collection of libraries that extend the QtQuick library both with functionality and widgets that blend in with the Plasma theme.
  • Special API exists to interact with the shell, allowing you to save configurations or set default sizes.

In this series of tutorials we’ll go through the steps of writing a real plasmoid from scratch, using some of the plasma libraries.

By the end we should have a completely working, deployable RSS reader.

Hello world

Initial Folder Structure

Plasmoids follow the simple KPackage structure. In the top-most folder there should be a file titled metadata.desktop and a single folder called “contents”.

Inside the contents folder we place all our QML, assets and other additional files. We split the contents into subdirectories: config, data and ui to make things easier.

In our tutorial we will be making an RSS reader so everything is named appropriately to that.

The basic directory structure should be as follows:

myrssplasmoid/metadata.desktop
myrssplasmoid/contents/ui/main.qml

metadata.desktop

[Desktop Entry]
Name=RSS Plasmoid
Comment=Shows RSS Feeds
Encoding=UTF-8
Icon=applications-rss
ServiceTypes=Plasma/Applet
Type=Service
X-KDE-PluginInfo-Author=David Edmundson
X-KDE-PluginInfo-Email=davidedmundson@kde.org
X-KDE-PluginInfo-Name=org.example.rssplasmoid
X-KDE-PluginInfo-License=LGPL
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://techbase.kde.org
X-Plasma-API=declarativeappletscript
X-Plasma-MainScript=ui/main.qml

Most of the fields here should be fairly self explanatory.
If in doubt, copy this and change the relevant fields.

main.qml

import QtQuick 2.0

Item {
    Text {
        anchors.centerIn: parent
        text: "Hello World!";
    }
}

Providing you have followed the recommended reading this should be fairly self-explanatory, we have a text item in the middle of the plasmoid which will say “Hello World”.

Over the next few tutorials this will get somewhat larger, we will also see some of the problems with this example; here translations aren’t implemented and the text won’t match the Plasma theme colour.

Installation

From the directory above run

plasmapkg2 –install myrssplasmoid

It should now be visible in the plasmashell in the “Add widgets” option along with every other plasmoid.

We can then it to our desktop or panel like any other installed plasmoid.

Next

Next tutorial, we will cover getting data from external sources.