March 02, 2019

KDE Project:

Dirk Hohndel talked about his experiences with QML and Kirigami at LCA 2019:
Producing an application for both desktop and mobile

I think that's quite useful for us as feedback from somebody who is not directly part of the KDE community.

February 28, 2019

My last post shows how to create a stub Python/Kirigami app that doesn’t do anything. Time to change that! In this post we’re filling the screen with some controls.

Kirigami Pages

Kirigami apps are typically organized in Pages. Those are the different ‘Screens’ of an app. If you come from the Android world you can think of them as the view part of activities. In our case we want to have an initial page that offers to enter a stop or a destination and opens a new page that shows a list of possible routes. Clicking on one of the list items opens a new page with a detailed view about the connections.

Pages are organized in a pagestack where pages can be pushed and popped. On a phone only the topmost page is shown, whereas on a larger screen (desktop or tablet) multiple pages can be shown next to each other.

A single page on the phone
Two pages next to each other on the desktop

So let’s create some pages! I’m going put each page in its own .qml file and let the name end with Page. Our first version of StartPage.qml looks like this:

import QtQuick 2.2
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.4
import org.kde.kirigami 2.0 as Kirigami

    title: "Start journey"

It produces an empty page with a title. Before we can actually see it we need to add it to the pageStack. Replace the Label {} declaration in main.qml with

pageStack.initialPage: Qt.resolvedUrl("StartPage.qml")

pageStack.initialPage is, well, setting the initial Page of the Page stack. Qt.resolveUrl is converting the relative URL of the QML file into an absolute one. Starting the app gives us an empty page

Time to fill it with some content.

Basic controls

On the start page we need need a way to enter start and destination of our journey as well as the date and time of our travel. For start and destination we are using simple TextFields from QtQuick Controls 2. Note that the older version 1 of QtQuick Controls is still around for the foreseable future, but we want to avoid using that. We’re extending StartPage.qml with our controls

ColumnLayout {
    width: parent.width

    Label {
        text: "From:"
    TextField {
        Layout.fillWidth: true
        placeholderText: "Würzburg..."
    Label {
        text: "To:"
    TextField {
        Layout.fillWidth: true
        placeholderText: "Berlin..."

A ColumnLayout is a component that positions its children vertically. We set it to be as wide as its parent, the page. The TextFields shall span the whole width as well. Instead of using the same ‘width: parent.width’ we are using ‘Layout.fillWidth: true’. This property is only available to children of a Layout. The difference to the first way is that all the width that is not already occupied by other elements in the layout is filled.

Next we need some way to enter a departure date and time. Unfortunately I’m not aware of any ready-to-use date and time pickers in QtQuick and Kirigami, so I’ll leave this open for a future post. For the time being two simple placeholder buttons shall be enough. Let’s add them to our ColumnLayout

RowLayout {
    width: parent.width
    Button {
        text: "Pick date"
        Layout.fillWidth: true
    Button {
        text: "Pick time"
        Layout.fillWidth: true

Now our app looks like this. Both buttons have the “Layout.fillWidth” property set to true, resulting in each one getting 50% of the space.

The buttons look a bit weird, don’t they? That’s because they are using the built-in QtQuick Controls style. If you are using Plasma you are probably used to the org.kde.desktop style which emulates the active Qt Widgets style. We can force our app to use the org.kde.desktop style by running ‘QT_QUICK_CONTROLS_STYLE=”org.kde.desktop” ./’

Looks closer to what we have on the desktop, doesn’t it? Qt also offers a ‘material’ style that follows Android’s material guidelines

Next we need a way to press “Search”. We could solve that with yet another button, but Kirigami offers another way. Pages in Kirigami can have Actions associated with them. The presentation differes from the phone to the desktop. On the phone actions are displayed on the bottom where they are easily reachable while on the desktop they are displayed in form of a toolbar at the top of the page. Let’s add an action to our page

    id: root

    title: "Start journey"

    actions.main: Kirigami.Action { "search"
        text: "Search"
        onTriggered: pageStack.push(Qt.resolvedUrl("ConnectionsPage.qml"))

    ColumnLayout {

On the phone we get this

while on the desktop we get that

You can force the mobile view on the desktop by setting the QT_QUICK_CONTROLS_MOBILE variable to 1.

Triggering the action pushes ConnectionsPage.qml on the pageStack. Of cource we need to create that one now:

import QtQuick 2.2
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.4
import org.kde.kirigami 2.4 as Kirigami

    title: "Connections"

Right now it’s just an empty page, we’re going to fill it with life in the next post.

You can find the full source code for all posts on Git.

Happy hacking!

KDE is happy to announce that we will be part of Google Summer of Code 2019. GSoC is a program where students recieve stipends to work on free software for 3 months. Getting paid for open source work, that’s the dream, right?

KDE Connect is participating with 3 interesting projects that also involve other areas of KDE

1. Improving KDE Connect on Windows

KDE Connect builds and runs on Windows, but there are a lot of things that can be improved. This mostly involves the functionality that makes use of notifications. A large part of this task is about improving KNotifications on Windows.

2. An SMS app for Plasma Mobile

Plasma Mobile does not have a functional SMS app yet. We believe that the best way to create one is to reuse the SMS UI we’ve been developing for KDE Connect. We verified that the Plasma Mobile SMS stack is functional on the Nexus 5 (I have no information about other devices). The UI is already running on a phone, what’s missing is a backend that talks to ofono

3. Barcode scanning infrastructure

Scanning a barcode is one of those tasks that comes up in various different apps but the developers don’t want to implement it themselves. For those kind of tasks we have the Purpose framework in KDE. It allows the developer to specify a desired action and let the user choose from available services to fulfil them. E.g. the Share feature in Dolphin is implemented via Purpose. This task is about adding a new action type to Purpose that allows to scan a barcode. Possible implementations could use the local camera or the camera of a device connected via KDE Connect.

If you are interested in doing one of those tasks and have some basic understanding of C++ please contact us on #kdeconnect on Freenode or on Telegram.

The deadline for student applications is April 9th and composing a good application takes some time, so please contact us rather soon.

Please note that we require students to have done some minor work (e.g bug fixes) before starting GSoC. Don’t worry if you don’t have done anything yet, there is still time for it ��

Happy hacking!

KDE and open source in general has used IRC since the 90s but times change and these days people expect more than text with lots of internals exposed to the user.  So KDE has set up a Matrix server which talks to other Matrix server and importantly also talks to IRC servers and their channels because some people will never change.  The bridging to IRC isn’t perfect but it works much neater than on e.g. Telegram where the IRC user is one bot, here the IRC user is an individual user and you can set it up to use the same nickname you’ve been using since 1995.  Unless you use square brackets in your nickname in which case I’ve no sympathy ��

But it still requires a bit of understanding and setup.  For one thing you need an app to talk to it, and the more common apps seem to be Riot web and Riot Android. KDE has its own setup of Riot web called and you can get the Android client from F-Droid or Google Play.  Once you make an account you also need to tick some boxes (including one saying you are over 16 which vexes somewhat but it doesn’t be beyond the ability of most 15 year old to work out how to work around it).

Channels are called rooms and you can then search for them on the server or on the server.   Or, once you work out the syntax, you can join channels on Freenode IRC or OFTC IRC.  You can also bridge IRC channels to Matrix Rooms and make it mostly transparent which works.

There’s voice and video calling too using Jitsu and important features like emojis and stickerpacks, although the Konqi sticker pack is still to be added.

I had some faff getting my nick from Freenode recovered but managed that before long.  Remember to set a nice pic so people can recognise you.

I’ve now stopped using my IRC app and don’t tend to look at Telegram unless someone pings me.  It’s great that KDE now has modern and open communications.  Thanks to the sysadmins and Matrix team and others who worked on this.

Next step: getting forums and mailing lists moving onto Discourse ��

More docs on the KDE Matrix wiki page.

Facebooktwitterlinkedinby feather

Every summer Google puts on a program that helps university developers get involved with the open source community. This is known as Google Summer of Code (GSoC). Krita has always participated in GSoC through the KDE community, and plans to do it again in 2019!

If you, or someone you know, is in university and wants to work on Krita, you have come to the right place.


Submitting a resumé or CV isn’t how this program works. For you to be picked, you need to be involved with the Krita community early and show you have some capacity to do programming.

The summer program involves focusing on one project. You will have a mentor assigned to help learn the ropes. Here are some potential project ideas.

If there is another project that you want to see, you can also propose your own. Use these guidelines to help formulate ideas: Student Proposal Guidelines.

So, hang out with our community on Krita’s chat channel, build Krita, start hacking on some bugs or feature requests and discuss what you would like to do with us.

Knowledge required

There are a lot of programming languages and technologies out there. These are some of the main technologies that Krita uses:

  • Qt 5 Framework
  • C++, Python and QML
  • GIT
  • IRC — how developers do most of their communication

Deadline and Contact Us

You can find the timeline for the whole GSoC program here. Student application begin March 25, but you should *really* start being involved earlier if you want to have a shot. Ohh, did we mention this is a paid position?

If these rules haven’t scared you off, get in contact with us if you have any questions. Drop by the forum or talk with us on the chat room (IRC)

I'm glad to announce KStars first release of 2019: v3.1.0 for MacOS, Linux, and Windows. This release focuses on improvements to stability & performance of KStars. In 3.0.0, we introduced quite a few features which resulted in a few regressions that we worked hard to iron out in this release.

Ekos Scheduler

Eric Dejouhanet fixed a few bugs with the Ekos Scheduler along with making steady improvements to cover all corner cases for multi-object multi-night scheduling which can become quite complex.

Ring-Field Focusing

Eric also added a new feature to the Focus module: Ring-field focusing. This method limits the area which stars are detected between an inner and an outer ring. This can be useful in images where
galaxies or nebulaes can be mistaken as stellar object which often lead to erroneous HFR reporting.

This can only be used for full-field focusing.

Meridian Flip

Wolfgang Reissenberger migrated the Meridian Flip handling code to the Ekos Mount tab. This makes meridian flip possible even if there is no capture process going. If the mount is tracking and passes the meridian, it can be triggered to flip now in the Mount Module.

Ekos Documentation

Yuri Chornoivan migrated online Ekos documentation to KStars official documentation. This was a tremendous effort due to the volume of the documentation data involved. Now Ekos documentation are properly managed by us in KDE and should get translations like the rest of the official documentation.

Ekos PAA for Non-GOTO mounts

Sebastian Neubert introduced manual workflow for users who would like to use Ekos Polar Alignment Assistant Tool with manual non-GOTO mounts. Now the users are prompted to rotate the mount when it is required to do so until the process is complete. This is Sebastian's first code contribution to KStars, welcome to the team!

MacOS Build Script

Robert Lancaster developed a comprehensive script along with detailed documentation for building KStars with Craft on MacOS. This enables users to wish to either develop for KStars or use the latest bleeding edge versions from trying it out with a single script that pulls all the sources and compile them accordingly with the aid of KDE's spectacular Craft technology.

DSLR LiveView

The LiveView window received a few enhancement to enable zooming and panning for supported DSLR cameras.

February 26, 2019

Previously I have been writing about how topics in messages can have a significant impact on the amount of data for publishing via MQTT. Since then the MQTT version 5 standard has been released and first implementations are available. Naturally, Qt MQTT follows along and this post will reflect how new features in the standard are available in our Qt for Automation module.

In this post, we will not go into every detail of the updated specification, but rather showcase some highlights and benefits for upgrading to the latest versions.

Also, before we forget, make sure to sign up for my upcoming webinar on the same topic. Tune in and discuss!

Topic Alias

As a reminder, the topic of a message is always sent uncompressed in clear text as part of the byte stream. For example, a sensor network reporting temperature values could have a topic hierarchy designed as


Consequently, the byte layout of a message has this shape:


This sums up to 71 bytes for each message, with 4 bytes containing the requested information.

In the previous post, we talked about methods like

  • Reducing the topic length
  • Combining multiple sensor values to enhance the overhead-information ratio.

MQTT5 introduces Topic Aliases which allow assigning IDs to a specific topic.

During the connection handshake, the client and the server agree on whether topic aliases are available and what the maximum number of topic aliases is. While ids are available, they can be assigned to topics. This assignment is done during a publish message. The new layout to send a message and concurrently set a topic alias looks like this:


For the first message, the data size is 74 bytes, three more than for a conventional publish. However, the second publication already benefits from this concept


The message size has been reduced to 11 bytes, simply by exchanging the topic with an ID and keeping the topic string empty. Starting from the second message this is a major improvement to reduce the required bandwidth.

It is important to note that topic alias assignments are only set for one connection. Other subscribers on this topic, especially ones that do not use topic aliases, will receive messages including the full topic. Alternatively, those connections can create their own topic alias matching. It is the responsibility of the server to forward topics with either the full topic, or a different alias.

Furthermore, topic aliases are not static. An alias can always be re-assigned to another topic.


Let’s move on by showcasing how to use this feature with Qt MQTT. Support for MQTT v5 has been added for Qt MQTT with Qt for Automation 5.12.

  • Connect with topic aliases

To set topic alias support for a connecting client, the QMqttClient needs to be updated before connecting to the server

const int userMaxTopicAlias = 9;

QMqttConnectionProperties userProperties;





  • Verify that the server supports aliases

When a server connected, query that the server also supports topic aliases

const auto serverProperties = client.serverConnectionProperties();

const quint16 serverMaxAlias = serverProperties.maximumTopicAlias(); // Returns the number of available aliases

A connection can use up to the minimum of client and server topic aliases.


  • Publish a message while setting topic alias
const QMqttTopicName topic(QLatin1String("sensors/Europe/2af89b42-d2a6-11e8-a8d5-f2801f1b9fd1/Temperature"));

QMqttPublishProperties aliasProperties;


client.publish(topic, aliasProperties, msgContent, 1);

Internally, Qt MQTT stores the assignment to simplify follow up publications.


  • Publish follow up messages
client.publish(topic, msgContent, 1);

There is no need to add the properties for subsequent calls unless the purpose is to reassign an ID.

Qt MQTT tries to use topic aliases automatically unless a user specifies them. After a connection has been established and Qt MQTT recognizes support for using topic alias, it “converts” classic publish messages to use topic aliases until all available aliases have been assigned. It uses an internal cache for this purpose, which can be controlled by using above QMqttPublishProperties.

There is no heuristics included in that cache, thus we still recommend using topic aliases manually. It depends on the project to identify which topics are frequently used and which topics can create the biggest benefit by using aliases.

As a closing note, Qt MQTT also takes care of the subscribing end about topic aliases. The process is the same, with the server specifying the topic and alias match. Qt MQTT then tracks this relationship and passes the full topic string inside a QMqttMessage to not require user specific code for this.

If a user wants to know, whether a topic has an assigned alias, the publish properties of a QMqttMessage contain this information.

Properties everywhere

You might have recognized the usage of a publish property class above. This reveals a new concept introduced with MQTT 5. While staying a lean and simple to use protocol, efforts have been made to allow for more dynamic setups.

Properties can be embedded into the existing commands, but it is not a must to include them. Default values cover the most used scenarios or ensure a compatible behavior with MQTT 3.1.1. Providing a zero byte indicates no properties to be set.

All available properties and their matching commands are listed below:


For each command, a new property class has been introduced with version 5.12. Please check the documentation on how to precisely use them.


Authentication has been updated in a major fashion within MQTT 5.0, to the extent that a new command AUTH has been introduced. After sending a connection request from a client to a server, the server might ask for further authentication information. This happens via sending an AUTH command including a Continue reason code. The client then needs to provide authentication data, which either leads to successful connection, the server asking for even more data or the connection being closed due to a failed authentication. There is no limit on the number of authentication steps.

The actual method used for authentication is decided on the server side. This can be for instance OAuth, or any other functionality integrated on the server side.

In Qt MQTT the QMqttClient has an authenticationRequested and authenticationFinished signal to reflect a notification from the server. Furthermore, the authenticate function has been introduced to send authentication data to a server.

What’s more?

Descriptive arguments can be used to provide more details on the content of messages. And even more, it is now possible to allow servers to provide error messages to a client. This can be of big help when implementing a communication protocol between a client and a server. The standard used to demand a disconnect in case of invalid behavior. It still does, but now a server can include either error codes or even error strings as guidance for the client or the developer.

Naturally, all these things are reflected in Qt MQTT.

We would like to understand more about your usage of this module and which features would be required most to make your project succeed faster. If you have any comments, feel free to get in touch with us either via the comment section, directly via email or catch me live during the upcoming webinar.

The post MQTT version 5 updates and how they apply to Qt MQTT appeared first on Qt Blog.

February 24, 2019

This is week 59 for KDE’s Usability & Productivity initiative, we’ve got lots of juicy improvements for our apps! In addition to lots of nice improvements for Plasma and Frameworks, the KDE Applications 19.04.0 release comes out in a little under two months and we’ve been working hard to add awesome new features. Check it out:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a donation to the KDE e.V. foundation.

February 21, 2019

The KDE Community has just announced the wider integration of Matrix instant messaging into its communications infrastructure. There are instructions on the KDE Community Wiki as well.

So what’s the state of modern chat with KDE-FreeBSD?

The web client works pretty well in Falkon, the default browser in a KDE Plasma session on FreeBSD. I don’t like leaving browsers open for long periods of time, so I looked at the available desktop clients. Porting Quaternion to FreeBSD was dead simple. No compile warnings, nothing, just an hour of doing some boilerplate-ish things, figuring out which Qt components are needed, and doing a bunch of test builds. So that client is now available from official FreeBSD ports. The GTK-based client Fractal was already ported, so there’s choices available for native-desktop applications over the browser or Electron experience.

Screenshot of two Matrix IM clients

Fractal and Quaternion side-by-side

For about twenty years, irssi in screen, accessed via ssh, was my preferred chat method. (Well, irssi didn’t exist on SunOS in the mid-90s, so I must have used something else originally). Quassel has replaced it on my desktop, and has a nice phone client (QuasselDroid) too if I need to check IRC while on a train. But now there’s Matrix clients as well.

Here in the screenshot, Fractal (on the left, background) looks pretty slick, like a phone-based chat application would. Quaternion reminds me a lot more of .. well, of Quassel. It even has little brutalist buttons to pop up the raw JSON content of messages, I don’t know why. I haven’t gotten around to porting other Qt-based Matrix clients; it’s hard to tell what would be worthwhile to try. For now I’ll go back to plain IRC, because for me the lack of stickers is a feature, not a bug. #GetOffMyLawn

If you followed Kdenlive’s activity these last years, you know that we dedicated all our energy into a major code refactoring. During this period, which is not the most exciting since our first goal was to simply restore all the stable version’s features, we were extremely lucky to see new people joining the core team, and investing a lot of time in the project.

We are now considering to release the updated  version in April, with KDE Applications 19.04. There are still a few rough edges and missing features (with many new ones added as well), but we think it now reached the point where it is possible to start working with it.

Testing day tomorrow

This is why we are organizing a test day event tomorrow, 22nd of February 2019, from 17:00 to 22:00 CET, so you can try it, report the problems you encounter and help us shape the future.

How to join ?

  • Download the latest AppImage
  • Make it executable (in a terminal: chmod +x ) or from your file manager
  • Test it!

More tech-savy users can alternatively compile it with debug flags following this guide and send backtraces

Give us your feedback

During the event, some team members will be reachable on our #kdenlive channel on irc/freenode or via the kdenlive telegram group, and you can also leave your feedback in this Phabricator task.

Known issues

There are a couple of known problems that will be solved before release:

  • Audio thumbnails in timeline eat up lots of memory, and can cause a freeze if large audio files are used, you can disable them as a workaround in larger projects
  • Motion tracker not usable yet


We are happy to announce the release of Qt Creator 4.9 Beta!

There are many improvements and fixes included in Qt Creator 4.9. I’ll just mention some highlights in this blog post. Please refer to our change log for a more thorough overview.

Generic Programming Language Support

In Qt Creator 4.8 we introduced experimental support for the language server protocol. This enables editing support for a wide range of programming languages through a common protocol. In 4.9 we add support for the document outline, find usages, and also for code actions, which allow the language server to suggest fixes or refactoring actions at a specified place in the code. If the language server of your favorite programming language supports these features, they are now available in Qt Creator as well. Enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS) and configure your server in Tools > Options > Language Client to check it out.

Highlighting is still provided by the generic highlighter in these cases. We changed our highlighter to be based on the KSyntaxHighlighting library, which is the library used in KDE for this purpose. Many thanks to the maintainers of KSyntaxHighlighting for making it available to a wide range of uses.

C++ Support

The UI for diagnostics from the Clang analyzer tools got many improvements. They are grouped by file now. Diagnostics from the project’s headers files are now also included.
Fix-its show details on what they do when applied. We also added a guard against applying Fix-its to files that have changed in the meantime. In the Clazy configuration you can enable or disable individual checks.

If you enabled a diagnostic to be shown inline in the code editor, you can disable individual checks via a button in the diagnostic’s tool tip.

QML Support

We updated our QML parser to Qt 5.12, adding support for ECMAScript 7.


Perf is a powerful performance profiling tool for software running on a Linux system. Profile your application via perf with Analyze > Performance Analyzer, after enabling the plugin in Help > About Plugins. The integration in Qt Creator is available for applications running on a local Linux system, and also for applications running on a remote Linux system from a Linux or Windows host.

Generic Projects

Similar to our support for deploying files to a remote system for CMake-based projects, you can now add a QtCreatorDeployment.txt file to your generic project, to specify the necessary information about where to deploy which files.

If your project needs some special compiler flags to be correctly handled by the code model, you can now specify these in a .cxxflags or .cflags file.

Other Improvements

For Windows, we added support for MSVC 2019. On macOS we added a Touch Bar if you run Qt Creator on a MacBook.

For remote Linux targets, we exchanged our Botan-based SSH backend by use of OpenSSH tools. You need to install the tools separately (if you have not already) to be able to benefit from a wide range of encryption and authentication features in Qt Creator. We also added a rsync-based deployment method, as well as support for Run in Terminal.

Version control support has also received many fixes and improvements. The Git Branches view has a new Push action and Git tracks detached HEADs.

Get Qt Creator 4.9 Beta

The opensource version is available on the Qt download page under “Pre-releases”, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.9 Beta is also available under Preview > Qt Creator 4.9.0-beta1 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on, and on the Qt Creator mailing list.

The post Qt Creator 4.9 Beta released appeared first on Qt Blog.

QMacTouchBar has landed

Recent Apple MacBook Pro models contain an entirely new hardware feature, the touchbar. The touchbar is a touch-sensitive OLED strip sitting above the standard keyboard, where the function keys used to be. macOS uses it for some of the physical buttons that used to be located there, such as volume controls, but it is also possible to use the touchbar yourself, both as a graphical output device, and to trigger various activities.

Not a lot of packaged software makes use of it yet, but of course Apple’s own applications as well as recent versions of Microsoft Office and various Adobe packages use this to the fullest.

Support for Qt Developers

Qt developers were left out up until now, since there was no support in Qt for this. This has now changed, however, since KDAB just contributed QMacTouchBar, a widget in the QtMacExtras module that was written by KDABian Christoph Schleifenbaum, and that is already being used in some of KDAB’s own internal tools.

This is a welcome addition since Apple is not making interfacing with its system components from C++ particularly easy. This requires code written in Objective-C, one of Apple’s favorite programming languages, to interface with the built-in Cocoa libraries, as well as the necessary glue code written in C++ to make the touchbar appear as a perfectly ordinary Qt widget to Qt applications.

Currently supported are QTabBar, QMessageBox, QDialogButtonBox (Apple is using the touchbar a lot to show the buttons that close a dialog, such as “OK” and “Cancel”), and QWidgetAction, and it is possible to mark a QAction as the principal action as well as the escape action. Action icons are already supported, and further additions are planned.

Until QMacTouchBar has been merged upstream, you can find it here.

The post QMacTouchBar has landed appeared first on KDAB.

February 20, 2019

From February 4th until February 9th I attended a Plasma Mobile sprint in Berlin, Germany. I met a lot of people that share the vision of an open, privacy-friendly mobile platform. However, we all agree that such a platform can only succeed if there are enough people sharing that vision creating suitable apps for it. There already is a nice amount of mobile-friendly Linux apps, many of them created by the KDE Community, but of course we need more ��

One app that is essential for my use case is an app that allows me to check departures and routes for public transport. Since I’m not aware of any existing one I decided to do my own and share my road here. The purpose of this is to be educating for both me and you and to inspire you to create your own mobile-friendly Linux apps.

Like the other KDE mobile apps I’m going to use QML/QtQuick and Kirigami. QML is the declarative UI language from the Qt project. Unlike the older QWidgets it is designed with (embedded) touch systems in mind and thus is ideal for mobile apps. Kirigami is a set of QtQuick components designed for creating convergent mobile/desktop apps.

Unlike other KDE projects I’m not going to use C++ for the business logic. Instead I’m going to use Python, which is now officially supported by Qt. Since my Python skills are fairly basic this will be a fun challenge for me. Therefore take everything I write with a grain of salt and feel free to point out anything that is wrong or can be improved.

This won’t be a 100% complete reference for developing for Plasma Mobile, but I’ll try to cover as many different aspects as fit into the concept of this app. I’ll also try to focus on one aspect/feature/goal per post. Also most of this will not be specific to Plasma Mobile but will work on any desktop or mobile Linux.

So lets get started ��

Part 0: Basic application

Before getting started we need to install a few things. First of all we need Python (obviously) and Qt for Python. Qt for Python was formerly known as PySide2. You can install it via ‘pip install pyside2’. Next there is Kirigami. On Ubuntu you can install it via ‘sudo apt install qml-module-org-kde-kirigami2’.

After that we can start coding. The following file is creating an app and loading the UI from a .qml file. The exact details are not too important at this point.

#!/usr/bin/env python3

from PySide2.QtGui import QGuiApplication
from PySide2.QtQml import QQmlApplicationEngine

if __name__ == "__main__":
    app = QGuiApplication()
    engine = QQmlApplicationEngine()

    context = engine.rootContext()

    if len(engine.rootObjects()) == 0:

Next we need to define our UI in a QML file. To keep things organized we are going to put our QML files in a qml/ subfolder. Our first main.qml is rather simple

import QtQuick 2.2
import QtQuick.Controls 2.4
import org.kde.kirigami 2.0 as Kirigami

    width: 480
    height: 720

    Label {
        text: "Hello world!"
        anchors.centerIn: parent

width and height are a bit arbitrary since the window will always be maximized on the phone, but this way we get a somewhat realistic window on the desktop. Executing the python file should result in something like this

In the next post we are going to fill this window with more life using QtQuick and Kirigami components. Stay tuned ��

The source code will be available at

I've finally decided to delete my Facebook account. I've been pondering this decision for several years now; my previous choice on the matter was to just use it as little as possible, in write-only mode, just to spread political propaganda and generally make it a horrible place for everybody else too. My reasoning was the following: if I had a huge following, then I'd definitely leave and make a big noise (and impact); but since I'm mostly connected with real acquaintances only, my only way to make a (albeit minimal) impact is to stay there and “save” my friends by convincing them of my opinions and/or by being so annoying that they'd decide to leave first.

There's life out there, too

However, the more time passes, the more I start doubting this position. What I really want is for people to leave Facebook; but as long as I'm there, as everybody else is there, no matter how grumpy or destructive we might be, we are still part of Facebook's business and not challenging the status quo in any meaningful way. We are not going to convince anyone to migrate to alternative platforms (or just leave all social media for good) while we continue to maintain a presence in there. Also, I know too well that it's nearly impossible to change someone's mind via social media, and my plan to make the place horrible for everybody is not going to work either: if people get annoyed, they'll just mute me and that's it.

On the other hand, if I leave Facebook for good, there's still a high chance that nobody will care, but at least I've quit. I'll no longer be a resource for Facebook. On the grand scheme, this is very little, a tiny drop in the ocean, but I believe it's the best I can do. Will I suffer it? Personally, not at all: I've not been consuming Facebook for a couple of years by now. But certainly, it's possible that the number of visits to my blog or YouTube channel (we'll talk about this other monster some other time) will decrease; not many people know how to use browser bookmarks (let alone an RSS feed) nowadays but, honestly, there's not much I can do about it.

The tech giants of the internet are certainly making our lives easier: it has become easier to stay in touch, to find information, to consolidate a mainstream opinion. It's so convenient, that it is making us not only lazier, but also dumber, to the point that we'd feel lost and powerless without their services. We are not talking only about a psychological addiction anymore: they are becoming a practical necessity. This, in turn, makes us weak, easy to manipulate and, ultimately, slaves.

I believe in the internet as the inter net: a distributed, interconnected place, with no owner. My hosting provider decides to censor me and shuts down my site? Fine, I open a new one in another hosting. If Facebook kicks you out, you immediately lose access to your friends, the groups you followed, the marketplace, local events, your daily news, your identity, your history.

And me, I want to live in a world where I'm the owner of my life.

We are pleased to announce that the 1st bugfix release of Plasma 5.15, 5.15.1, is now available in our backports PPA for Cosmic 18.10.

The release announcement detailing the new features and improvements in Plasma 5.15 can be found here, while the full 5.15.1 bugfix changelog can be found here.

Released along with this new version of Plasma is an update to KDE Frameworks 5.54. (5.55 is currently in testing in Disco 19.04 and may follow in the next few weeks.)

To upgrade:

Add the following repository to your software sources list:


or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade


Please note that more bugfix releases are scheduled by KDE for Plasma 5.15, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.13.5 as included in the original 18.10 Cosmic release.

Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list:
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on
3. Kubuntu ppa bugs:

KDE is adopting non-proprietary and decentralized instant messaging services and is now running its own community-managed instance of Matrix.

Matrix works fine on mobile as well.

KDE has been looking for a better way of chatting and live-sharing information for several years now. IRC has been a good solution for a long time, but our channels are currently on servers KDE cannot control. It also lacks features users have come to expect from more modern IM services. Other alternatives, such as Telegram, Slack and Discord, although feature-rich, are centralized and built around closed-source technologies and offer even less control than IRC. This flies in the face of KDE's principles that require we use and support technologies based on Free software.

However, our search for a better solution has finally come to an end: as of today we are officially using Matrix for collaboration within KDE! Matrix is an open protocol and network for decentralised communication, backed by an open standard and open source reference implementations for servers, clients, client SDKs, bridges, bots and more. It provides all the features you’d expect from a modern chat system: infinite scrollback, file transfer, typing notifications, read receipts, presence, search, push notifications, stickers, VoIP calling and conferencing, etc. It even provides end-to-end encryption (based on Signal’s double ratchet algorithm) for when you want some privacy.

All the existing rooms on Matrix (and their counterparts on IRC, Telegram and elsewhere) continue to exist. The new service provides a dedicated server for KDE users to access them using names like

For more information go visit our wiki page which contains details and instructions on how to get started.

You can also try KDE's Matrix service right now by checking in to KDE's webchat or by installing a Matrix client like Riot and connecting to the server!

February 19, 2019

Two months ago a small group of KDE enthusiasts, namely Adriaan, Roman, and me traveled to Berlin to attend Qt World Summit 2018.

Me posing at the KDE booth at Qt World Summit

At our little booth we showcased Plasma running on a variety of devices, ranging from a Nexus 5X running Plasma Mobile through two ARM laptops to the powerful KDE Slimbook. Plasma was praised for its performance and reliability and since the focus of the event was mostly on embedded systems, we could easily demonstrate with our selection of devices that Plasma and the KDE Frameworks are a viable option for an endeavor in this area, too.

It was very interesting to see the diverse set of people presenting their products and roaming the stalls, to see where Qt is in use today without you even realizing. We were approached by several companies evaluating using KDE Frameworks in their products and also tried to lay a foundation for an eventual partnership. And then there was Daimler who just parked an A-Class in the hallway, whose MBUX infotainment system is also powered by Qt.

Give Milian, author of hotspot (a profiler GUI we use a lot for Plasma), any device and he immediately starts profiling!
What’s inside? The large box isn’t a 5¼” HDD but the battery

The star of our stand, however, was the MNT Reform DIY Laptop which is a retro-style ARM laptop running Plasma with a mechanical keyboard and even a real trackball! Its case was 3D-printed just the day before, including a rubber band to hold the screen shut, and for educational purposes sported a transparent bottom cover so you could look inside. What got us very excited was the fact that it ran mainline Debian and a super recent kernel version, something that’s quite uncommon when it comes to ARM devices. Even better: its i.MX 6 SoC let Plasma fly and we didn’t even do any adjustments for the device. It really shows that our hard performance work and focus on polishing the stack over the past years is paying off.

We are happy to announce the release of Qt Design Studio 1.1 !

Qt Design Studio is a UI design and development tool that enables designers and developers to rapidly prototype and develop complex UIs. Both designers and developers use Qt Design Studio and this makes collaboration between the two a lot simpler and more streamlined. To get an impression, you should watch this video.

Since the Qt Design Studio 1.0 release last year we worked hard on bug fixes and new features.

The most notable addition to Qt Design Studio 1.1 is the availability of Linux packages and merging when using the Qt Photoshop Bridge.
To learn more about the improvements and fixes, you can check out the change log.

Qt Design Studio 1.1 is available for Linux

Qt Design Studio 1.1 is available for Linux

This means that developers using Linux e.g. for embedded development can use Qt Design Studio 1.1 directly on their development system.

Qt Photoshop Bridge and updating to Qt Design Studio 1.1

The Qt Photoshop bride allows sanitizing documents

The Qt Photoshop bridge allows sanitizing documents

We updated the Qt Photoshop Bridge for Qt Design Studio 1.1 and we fixed many issues.

Unfortunately, the format for the annotations by the Qt Photoshop Bridge in the PSD and the custom .metainfo file format have changed.

We will try to avoid such breakages in future, but we had to work around some limitations of Photoshop.

PSD files that already contain annotations from the Qt Photoshop Bridge 1.0, require to be sanitized.

Annotations are added whenever you export from a PSD file using the Qt Photoshop Bridge and when you explicitly use the UI of the Qt Photoshop Bridge to annotate a layer.

To remove such annotations you have to use Sanitize document in the Qt Photoshop Bridge.
After doing this you can export the PSD file and use it with Qt Design Studio 1.1.


Qt Photoshop Bridge and merging when importing

When re-importing from Photoshop to an existing Qt Design Studio project it is now possible to merge the existing QML files with the newly re-imported QML. This is very useful when the user made changes to the exported .ui.qml files using Design Studio.
Added StatesTimelinesMouseAreasAnchorsAlias Properties or Connections can now be preserved when re-importing from Photoshop and generating the new .ui.qml files.

By default, merging is not active and the importer will simply overwrite the .ui.qml file. You can enable merging using a checkbox in the import dialog.

You can find more information on the Qt Photoshop Bridge in the documentation.

The Photoshop bridge now supports merging when importing into Qt Design Studio

The Photoshop Bridge now supports merging when importing into Qt Design Studio

Update projects from Qt Design Studio 1.0 to Qt Design Studio 1.1

If you have used Qt Design Studio before, you should update projects that you created with the wizards of Qt Design Studio 1.0 since the custom controls like shapes and effects are part of the project.

You have to update the project itself, to get the latest controls and effects.
This is possible by copying the controls from a newly created Qt Design Studio 1.1 project into the existing project from Qt Design Studio 1.0.
The folder you have to replace is “imports/QtQuick”. Replacing this folder will update the Qt Design Studio specific components that are used in your project.

Download and try out Qt Design Studio 1.1

The commercially licensed packages are available on the Qt Account Portal. You can try out and evaluate Qt Design Studio by registering for an evaluation license. We are also working on an open source version of Qt Design Studio and our target is have it out with the 1.2 release (May 2019).

Qt Design Studio 1.1 comes with new examples and updated documentation

Qt Design Studio 1.1 comes with new examples and updated documentation

Getting Started

You can find the latest online documentation for Qt Design Studio 1.1 here. The documentation is also available from inside Qt Design Studio.

The welcome page of Qt Design Studio contains examples and links to video tutorials to help you get started.

Please post issues you find or suggestions you have in our bug tracker.

The post Qt Design Studio 1.1 released appeared first on Qt Blog.

Last year I wrote about Plasma Pass, a Plasma applet for the Pass password manager. Over the couple last months I got some emails from packagers from various distributions asking for a proper release so they can package it…so here it is, proudly announcing Plasma Pass 1.0.0.

Here’s a video of how it works:



SHA-256: 9821c5ad80e4370dce002855bd0300d234feec249258b01fafd9e3a9241cbc66
SHA-1:   8d877b4d4bbbbf12890ba77c03c5cdd62b8279d6
MD-5:    69928b6df32ba82d0436a6d0abf73a8a


0ABDFA55A4E6BEA99A83EA974D69557AECB13683 Daniel Vrátil <>

Feel free to report any issues or feature requests to KDE Bugzila.

There are only a few things more fun in this world than doing template meta-programming (TMP) and reading all those long poems that the compiler writes out when we make even the smallest mistake.

While we don’t usually welcome these messages, there are ways to make them useful.

One of the main causes of errors in TMP code are unexpected types – types that the compiler is deducing instead of the types that we expect it to deduce.

This results in error messages occurring in seemingly random places in our code.

printf debugging

Just like it is sometimes useful to printf values in our program while debugging a problem, it can be useful to print types while debugging the problems in TMP code.

For this, here is one of my favourite meta-functions for C++:

template <typename... Ts>
struct print_types;

It is a meta-function that takes several arguments, but has no implementation. Which means that every time we try to use it, the compiler will report an error along with some additional information like which Ts... we passed to the meta-function.

For example, if we wanted to know what are the exact types of std::vector<bool>::reference and friends, we could do this:


And the compiler will print out an error message along these lines:

invalid use of incomplete type 'class print_types<

The compiler printed out all three types that we requested it to print.

This can be used in conjunction with some compiler output post-processing – shortening some type names like std::basic_string<char> to string etc, replacing < and > with ( and ) and putting the output through clang-format to get a pretty readable and nice formatted output for complex types.

For example, this is the output generated for one expression template in my codebase:

                   expression(PRODUCER, ping_process,
                              transform("(λ tests_multiprocess.cpp:91:26)")),
                   transform("(λ tests_multiprocess.cpp:82:38)"))),
                              expression(TRAFO, identity_fn,
                                         transform("(λ tests_multiprocess.cpp:99:26)")),


Printing types several times

The problem with the previous approach is that you can call print_types only once – as soon as the compiler encounters it, it will report an error and stop.

Instead of triggering an error, we might want to try something else – something that the compiler reports without stopping the compilation – we could trigger a warning instead.

One of the easiest warnings to trigger is the deprecation warning – we just need to mark the print_types class as [[deprecated]].

template <typename... Ts>
struct [[deprecated]] print_types {};

This way, we can use it multiple times and the compiler will generate a warning for each of the usages. Now, this works well with clang because it reports the whole type that triggered the warning. Other compilers might not be that detailed when reporting warnings so your mileage might vary.

Assertions on types

When you write TMP code, it is useful to assert that the types you’re getting have some desired property.

For example, it is a sane default (just like const is a sane default for everything) to expect all template parameters to be value types. For this, you could create an assertion macro and sprinkle it all over your codebase:

#define assert_value_type(T)                            \
    static_assert(                                      \
        std::is_same_v<T, std::remove_cvref_t<T>>,      \
        "Not a value type")

Having the habit of adding assertions like these can make your life much easier down the road.

Tests on types

Just like the original print_types we defined stops the compilation when called, static_assert stops compilation as soon as the first one fails.

What if we wanted just to get notified that a test failed, without it stopping the compilation.

We can use the same trick we used to allow print_types to be called several times. We can use the [[deprecated]] annotation to get a warning instead of getting an error with static_assert.

This can be implemented in several ways. The main gist of all the solutions is to create a class template which is then specialized for false or std::false_type and that specialization is marked as deprecated.

Here is one of the more fun implementations:

template <typename T>
struct static_test {
    static_test(std::true_type) {}

template <>
struct [[deprecated]] static_test<std::false_type> {
    static_test(std::false_type) {}

template <typename T>
static_test(T x) -> static_test<T>;

And the usage is quite simple:

static_test int_is_int { std::is_same<int, int>::type{} };

Whenever a test returns std::false_type, we are going to get a deprecation warning.


Working with templates allows us to do awesome things but it can be quite tedious. Small tricks like these can make working with templates a breeze.

You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing.

February 18, 2019

Cutelyst a Qt/C++ Web Framework just got a new version. This time bringing back proper async support.

Perl Catalyst Framework was conceived as a sync/blocking framework, due that the Mojolicious framework was created, NodeJS and a few other web frameworks have pushed the async programming to the web. Performance wise being async doesn’t mean you get faster response times, rather the opposite, the need to unroll stack and make extra calls makes a CPU bound application slower.

But depending on the problem to solve it allows you to serve more users at the same time, using the same CPU cores. A typical modern application might receive a request from a Phone App then do a REST API call to an external API which might take 2ms or 200ms for the reply. While waiting for the response, typical sync/blocking applications can’t process more requests, or have to spawn more threads increasing RAM consumption and leveraging concurrency to the OS scheduler. On an Async web application, you can process another request while you wait for the previous request, thus possibly making the first request reply to be sent back to the user at a later time than if there was a dedicated process just waiting for his reply.

So, both ways have pros and cons and IMHO I’d like to support them both. When I started Cutelyst I thought that if I ever need async I could have a local QEventLoop to wait for the reply and would be able to deal with async requests, not recently I found out that supporting QEventLoop was causing stack overflow due it being used in pipelined scenarios, after that I removed it’s usage and performance improved in PlainText tests of TechEmpower, so I advised against using it and marked Cutelyst as not async.

Recently I got the need to call a few APIs from a REST API I did with Cutelyst, QNeworkAccessManager is an async only API, so either I create a thread for it to mimic sync behavior or allow Cutelyst to be used in async mode, of course I did the latter. The Context class has now detachAsync() and attachAsync() methods.

When you c->detachAsync(), you tell the engine to not send the headers and body immediately to the client, this will also break the action chain, meaning an end() method won’t be called, then when you get your async reply you call c->attachAsync().

Once c->attachAsync() is called the action chain is resumed so the end() method that possibly would render the HTML can perform it’s job.

It’s important to always be child ( QObject->setParent(…) ) of the Context pointer as if the client closes the connection it might be deleted.

This release was not only made of async:

  • A helper UserAgent singleton was added so that you have a thread_local QNetworkAccessManager with static methods to do more common REST tasks like sending a QJsonObject (yes, eventually I find time to write a patch for QNAM)
  • A new Sql::Transaction class gives you a scoped SQL transaction, preventing the mistake of not rolling back when you leave the scope in case of an error.
  • A few Headers helpers like ETag and If-Match comparison
  • Sebastian Held added support for dealing with Front-End Proxy Headers
  • Improved Stats precision using QElapsedTimer::nsecsElapsed()

And finally Cutelyst is not “half modern” CMake anymore, if that can even exist. The include directories of the exported Targets are now properly exported, so that you can remove:


Have fun

Could you tell us something about yourself?

Hi! I’m a European Krita user.

Do you paint professionally, as a hobby artist, or both?

I’m kind of in-between. I finished art school not too long ago, and I’m hoping to find a job or commissions so I could keep painting and actually earn money from it. I also do 3D and programming, but I’d love to keep doing all three without having to abandon any.

What genre(s) do you work in?

I like to try out different things, but for my main style, I’d say… illustrative? One thing’s for sure, though: my favorite theme is animals.

Whose work inspires you most — who are your role models as an artist?

I don’t really have one artist that I look up to, but more like a series of temporary stylistic crushes. Right now I’d say oddsbod, the video game Transistor by supergiant games, illustrator and video games 3D artist Heather Penn  I also read a lot of webcomics, and I admire the style of paranatural, vainglorious, inhibit (that are all three really expressive and energetic), stand still stay silent (beautiful), and barbarous (a bit of both).

How and when did you get to try digital painting for the first time?

That was more than ten years ago. I was something like ten, maybe twelve at most. A friend of mine had a photographer father, so I went to their house and could try his drawing tablet, and it was really cool; some time later my parents got me one (one of those small A6 ones), and my brother downloaded Gimp, probably for a birthday (he was -still is- really into open source).

What makes you choose digital over traditional painting?

At first it was the novelty, and the ease with which you could have really vivid colours; then, it was the lack of waste when you drew something you didn’t like and the immateriality of what you spent to draw: no heavy expensive paper wasted, no limited supply of colours – I never finished a gouache tube or a pastel stick, but I could see the point where there would be no more. No so with digital art. And now I’m just more used to it.

I haven’t left traditional forever though, I still go to the zoo to draw in a sketchbook, and every so often I include painted textures to my digital stuff. I’d like to experiment more with traditional techniques at some point.

How did you find out about Krita?

I didn’t actually need another drawing software, so I wasn’t looking, but then my brother told me “look at that awesome new (open source) drawing software, they actually ask their artists what they want/need”. I didn’t change right away (switching softwares is always a bit of an investment), but I did eventually try it out and I loved the brushes and I stayed. I remember it was the year of the sheep, probably around February (Chinese New Year), so the first drawing I ever made in Krita was a sheep head with one of the sketch brushes.

What was your first impression?

I loved the brushes. I didn’t use the sketch ones so much, though they definitely were a fun introduction to Krita, but I fell in love with the soft kind of blur of the wet ones. There actually was the same thing in TVPaint (an animation software), which I used in my animation school, but I felt like krita had more options painting-wise.

What do you love about Krita?

The brush engines, definitely. They have incredible diversity. Also I learnt how the assistant tool worked a few weeks ago (it was one of those  things you know exist but never got around to actually check), and it looks really cool (it can be used for drawing perspective, geometric patterns in your image, and more). And the animation system is nice, and way better than photoshop’s (which I deeply hate). It still needs some tweaks to actually be efficient in short films (most of all a way to colour that would be semi-automated over the timeline instead of by frame) but I’ve read somewhere it’s on the todo list. And I recently started doing repeating patterns, and the wrap-around mode is very useful, as instead of offsetting and copying the image every time you’re finished with one step you can just… draw… without worrying about seams.

The way people are always there to help, on reddit, the Ask Krita website, or the IRC channel (even developers!).

Also the fact that since it’s open source, if I want to I can just add the functionalities I need, and then if it’s a good addition it’ll get added to the software and made available to everybody.

What do you think needs improvement in Krita? Is there anything that really annoys you?

Like I said, the animation system needs improvement. The bases are solid, but since it’s still very young, it has room to grow.

What sets Krita apart from the other tools that you use?

Well, I do use it as my main art program, so I use no other (2D) programs to compare it to.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

This one [tern.jpg]. I did it as a birthday gift to someone I was missing, so I’m emotionally attached to it. I also like the format and the feeling of
space it gives.

What techniques and brushes did you use in it?

I used a round wet brush (it gives better gradients than the gradient tool if you’re going for a painted look and have large surfaces to fill), and the
shape tool as an eraser. For the mountains, and the sea, I drew them on separate layers, locked the alpha, and used wide brush sweeps over the opaque parts.

You’re a Krita contributor; how did you get into that?

Short version: stuff needed doing (to be used in my workflow), I was able to do it, and nobody else was currently doing it.

Long version: Something like one year ago, I was doing a pixel art animation in krita, and I needed to export an animation into a spritesheet for a game. At first I did it manually, then pretty quickly when I grew bored of it I looked on the internet and found a plugin that did it for gimp. So I exported all my images, imported them into gimp and exported them again, through this plugin, as a spritesheet. It was pretty unwieldy, plus the plugin only exported as a single line so I had to actually change the code every time I wanted to change the options, and every time I changed the animation I had to do it all over again. But I knew there was to be the python plugin interface for krita, so I waited.

Then a few weeks back I actually had some time, so I checked nobody had done it in the meantime and I made the export to spritesheet python plugin. Then there was one part of it that was actually already included in krita, but lacked a small option to be completely functional, so I built krita and changed it.

And now that I worked on this very small change of krita’s source code, I actually feel confident enough to imagine doing bigger contributions.

Where can people see more of your work?

I have stuff all over the place.

For a bit of everything I do, finished and sorted, go there:
For finished art, sorted, go there:
For art (including sketches and WIPS) posted on a semi-regular schedule:
For (digital) art you can buy, and also games:
For tumblr-is-dying-and-instagram-is-more-fashionable-those-days:

February 17, 2019

Week 58 for KDE’s Usability & Productivity initiative is here! Hot on the heels of last week’s update, we’ve got lots of nice goodies to share:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a donation to the KDE e.V. foundation.

February 16, 2019

A few months ago while I was scratching Latte Dock limits an idea came and haunted my thoughts. How Latte could give the colors freedom for panels and windows that an Android phone already provides? Questions like this arose and solutions appeared suddenly in many different places, but an important and concrete dream prevail in the end.

“Lets have panels and docks that understand their environment and adjust their colors and settings accordingly”

- youtube presentation -

How far would we like this dream to go, what are the limits?

An initial effort was landed at v0.8 through the Dynamic Background options but of course it was very limited. Step by step with patience the following goals appeared after version 0.8

Panels that:
  • can understand the underlying background independent of screen
  • color themselves according to the underlying background in order to provide the best contrast when they are transparent
  • can understand busy backgrounds (elementary style) in order to provide enough contrast
  • solidify themselves at some circumstances
  • understand when a window is touching them and paint themselves based on that window colors
  • can choose to be light or dark but at the same time to be based on the current plasma theme
  • provide an easy and elegant way to support the above features

Someone could ask, What nice features to have in my system but how long do you think it will be needed to provide them? one, two years?  who knows maybe never…

Well the thing is that this article does not describe the future but rather the PRESENT… All the above are currently supported from Latte git version. With their limits of course that arose from the current technology but nonetheless they are here…

What is needed in my system?

(advanced settings)
How can I enable these features in Latte git version?

After you install above requirements you can find these features at Latte Appearance settings. Latte Advanced settings has been reorganized and improved in order to provide you with a full screen height window at the edge of the screen. The new settings moto is:

“easy to find, simple to understand”

the settings work has not ended yet so more improvements will be presented in the future.

How can Latte understand which is the underlying background?

Latte tracks the plasma config files and discovers for each screen what is the current background used. It can understand only background image files or single colors. For each one it produces a brightness value for each different edge and at the same time if the background in that edge is busy. That means that a bottom dock can be light and a top panel can be dark in order for both to be presented correctly to the user. The same of course applies to different screens because screens can have backgrounds with different brightness.

In case you are using a gif animator or video playing for your background and the brightness is not identified correctly you could try the following. Make a representing screenshot from the mentioned video and assign that image as a background. You can afterwards reenable your background video because Latte will use that screenshot to identify the different brightness values for the edges.

Can a plasma theme choose to be dark or light dynamically?

Materia dark theme
in Latte Reversed Colors mode
Well the answer is by default it can not. Each plasma theme can be either light or dark and that is an important decision from its designer. Latte did not want to break the designer style so in order to solve this is trying the following.

Latte understands if a plasma theme is dark or light and independent of that it creates a reversed color palette. For example the background color will become the text color and the text color will become the background color. This way the colors used do not look too different.

At the same time in order for Latte to paint correctly a reversed colored background the plasma theme panel roundness needs to be known (how rounded are the panels in the corners). Latte already provides a file that describes the panels roundness for the most known plasma themes but if the theme does not exist in the file or the user just wants to bypass it he can adjust the plasma roundness in pixels through the Latte Preferences window.

How Latte can know what is the color scheme for each window?

The earlier mentioned KWin script sends through dbus the color schemes for windows that do not use the default applied color scheme. When these messages reach Latte are filed and thus Latte whenever needs to, can provide a proper color palette to be consumed by panels and applets.

What are the limits?

The new coloring mechanism needs to be supported from applets in order to be painted correctly at all cases. Currently there are four applets supporting it, Latte taskmanager, Window Title, Window AppMenu and Window Buttons . For the rest the user must choose whether the colorize effect should be applied or not. For example the plasma analog clock that is not monochromatic it should not be painted at all cases. The new option to disable the painting can be found at applet tooltip in edit mode.

left: analog clock with no painting / center: analog clock with painting / right: tooltip to disable painting


That is all for now, I hope you enjoy these new features, personally I love them...


You can find Latte at Liberapay if you want to support,     Donate using Liberapay

or you can split your donation between my active projects in kde store.

Latte Dock v0.8.6   has been released containing important fixes and improvements!

Go get  v0.8.6   from, download.kde.orgor*

* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E

  • fix previews that broke after kde frameworks 5.55 update
  • fix shortcuts behavior from plasma applets when using "Multiple" layouts


You can find Latte at Liberapay if you want to support,     Donate using Liberapay

or you can split your donation between my active projects in kde store.

After addressing Android support in KF5Notifications another fairly generic task that so far required Android specific code is next: opening files. Due to the security isolation of apps and the way the native “file dialog” works on Android this is quite different from other platforms, which makes application code a bit ugly. This can be fixed in Qt though.

Qt 5.12 and before

On most platforms, allowing the user to open a file in an application works like this:

  • Request the native file dialog via the corresponding widget or QML API, both of which go through the same internal platform integration plugin in Qt.
  • Retrieve a file path from the file dialog.
  • Open that path with QFile.

On Android so far we had to do the following:

  • Request the native “file dialog” (it’s essentially the file brower app) via an Intent.
  • Retrieve a content: URL from that Intent.
  • Use the Java ContentResolver API to open a file descriptor for that content: URL.
  • Pass that file descriptor to C++ and read it via QFile.

While the Intent details could be hidden behind the native file dialog abstraction in Qt, the problem then is still that the returned URL isn’t pointing to a local file that subsequent code might expect. There’s a good reason why Android does it that way though, as this allows applications to only access files that the user explicitly selected, without the need of full file system access permissions.

Qt 5.13 and beyond

A way to address this is a QAbstractFileEngine implementation to add support for content: URLs to QFile. This is the same approach taken already for e.g. asset: URLs. It’s actually not particularly complicated as all we need to do is obtain a file descriptor for a content: URL, and then hand over to the existing regualr file system backend, which implements everything else we need already.

KDE Itinerary is already using this approach as a testing ground, and this week this also landed upstream in Qt, to be included in the 5.13 release.

At the same time Nicolas added support for native file dialogs on Android, as well as content URL support in QML. With all that combined opening a file should (almost) work with identical code on all platforms.

One small caveat remains, the fact that you have to deal with URLs correctly throughout your file handling code. If you at some point convert to a local file path, this is going to break when encountering a content: URL.

February 15, 2019

If there is one thing you can learn from creative writing school, it is that you have to give your characters at least three good reasons before they should consider doing anything.

KDE Promo contributors recently completed drafting and editing a document that lays out the long-term goals for the Promo workgroup. This has proven a complex and tedious task, but we were compelled because we had those three good reasons:

  1. Having long-term goals laid out in front of us gives a clear direction in which to work.
  2. Concrete goals also help us differentiate between what is important and what is secondary; between what we can do with the resources we have, and what we may have to put on hold or even forget about completely.
  3. Goals help clarify to others why we do what we do. When our peers understand what we intend to achieve, it saves time because we don’t have to lay out every step of every process every single time to justify your actions.

But… what does “Long Term” mean to you?

After several back-and-forths on Phabricator, we ended up defining “long term” as “5 years”. We have also associated concrete numbers with each goal, things like “Promo intends to help increase the number of desktop end users by 2% over the next 5 years“, to provide specific baseline for each overarching action. This will help us assess the degree of success for each goal…

…or adjust our expectations to reality the next time we have to write something similar. Many of the numbers in the goals are dictated solely by what we currently feel is right. Since many of the goals have never been attempted, we can only speculate as to what they will take. Many of the baselines will probably have to change over time as we get more data that helps us make more realistic predictions.

How are you going to do it?

When you read through the list, you will see a pattern emerge: there is a lot of going to events, hoping to talk to head-honchos, sending emails into the void, getting in touch with people we have never met; lots of knocking on doors not knowing if we will have them slammed back in our faces.

Achieving goals through these means may sound like taking very long shots, but we do have a massive community on our side. For one, there’s the fact that, despite some exaggerated reports to the contrary, KDE is a force to be considered. I would not say that claiming you come on behalf of KDE will open every door, but it has helped us in the past, even when cold-calling, and it will continue to help us in the future.

Then there is the the friend-of-a-friend resource: in a community as large and with members in such far-flung places, from Korea to Kentucky, and from Norway to Nigeria, we want to be able to use members of our community as ambassadors to our cause. Thanks to our community, there will always be somebody who knows someone who can get us into meetings with the people we need to talk to.

And who are these people? Well, they are those who can help us reach ever larger audiences, while at the same time consolidating and helping us grow our community. We are talking about journalists, “influencers” (yes, I hate that word too), bloggers, vloggers, podcasters and so on. We also want to talk to businesses that may benefit from developing with our tools and frameworks.

The idea is to gradually expand our area of influence among users and companies beyond those that are already convinced of KDE’s virtues, even beyond those that are diehard Free software advocates and users. We want to reach more mainstream users, users and developers that may not even have heard of KDE.

This is where you can help: if you know a “celebrity”, influencer, or talented writer, a Youtuber, blogger, or good podcaster – introduce us! We want as much coverage as we can decently get, and content creators are often looking for topics they can talk about. We may be able to provide them with some juicy stories and get the word out to people we otherwise wouldn’t be able to reach. The same goes for journalists in mainstream or specialised publications, politicians, and decisions-makers in companies big, medium or small.

It may seem like the number of things we can do (tweeting, going to events, putting out press releases and blog posts, contacting journalists, talking to managers) is limited and very unexciting. This is true: there are no clever shortcuts or breakthrough techniques you can apply here. However, the fun is in the twists and turns you apply to these things.

You may have noticed we always try to a post an attractive picture with everything we send on to social media or publish on the Dot. We make meme jokes, jump on trending bandwagons, and often ask members from other workgroups and projects to let us look at what they want to submit to social media so we can give it a whirl. We believe you can always write and engineer a message in a way it can entice more people.

This sounds terribly conceited. How do you know you are right about this?

TL;DR: We don’t.

It is always hard to prove anything we do has a positive effect on KDE’s popularity and adoption. It stands to reason it be so, but there is no hard way to say for sure. The only thing we can do is look at the numbers over time and try to discover a correlation between actions and effects.

We monitor most social media platforms, regularly taking data from LinkedIn, Twitter, Mastodon, Facebook and so on. We also monitor Debian’s popcons (popularity contests) every week and store all the data in a folder on

This is where you can help: a lot of the data collection and processing is done by hand. There are services that could help us, but very often they are proprietary, tie us to their online storage services, and/or don’t cover all the bases, leaving out things like Mastodon, PeerTube or Diaspora.

We are also aware of how inadequate the sources we mine are. We really don’t have a good way of knowing, for example, how many times KDE software gets installed in distributions, so it is nearly impossible to figure out how many silent users are out there.

Point us to solutions and tell us about sources we can mine. This helps us get a better idea of how things are going for us on a global scale. It will also contribute to figuring out if what we are doing is helping or not.

We also need to know where we stand within our own community. Because of this, we are creating a survey that will help us understand better who our peers are. While the survey may confirm things we already suspect, it will also tell us about the big absences.

A good way to grow a community is by looking further afield, into audiences different from what we already have. As different people respond to different things, knowing who we are missing can help us shape activities to attract them.

This is where you can help: please answer our surveys! All information is anonymised and you obviously can ignore questions that you don’t want to answer. But even incomplete information will help us learn what sort of people we click with, and put us on the road to answering the question of why some people just don’t get bitten by the KDE bu–… er… dragon.

Notwithstanding, market research is far from a hard science, and it is frustrating not being able to confirm without a shadow of a doubt that we are doing a good job.

That must be annoying…

Talking of annoying, it is important to remember that most things in business fall through. Most meetings lead to nothing, most agreements end up producing nothing useful, most promises are broken. This is not because businesspeople are unreliable. The problem is priorities shift, other more urgent or more auspicious things pop up, and businesspeople are obliged to implement a better strategy for their companies if the opportunity arises, even if it means ditching an agreement with certain Free software communities.

But even a 90% failure rate is nothing to be disillusioned about. Quite the contrary: if you give up after a couple of let-downs, you are guaranteed not to succeed ever. Promo casts its nets wide and latches onto as many plausible-sounding agreements it can. We try to follow through until it is either clear it is going nowhere, it is not going to work in our favour, or it is no longer our business and we need to pass it on to someone who can sign on the dotted line — Promo does not have a say in the conditions of final agreements.

In fact, Promo has very little say in anything. If you read through the list of goals and how we intend to carry them out, it should be clear that Promo doesn’t dictate or even want to dictate what the rest of the community should do. We won’t even tell you to re-design your project’s website to make it more attractive and useful to your visitors. We will probably tell you that you _should_ re-design your site, and even help you do it, but we won’t tell you you have to.

We work with the things we have. We try to tell the rest of the world how KDE and our projects are attractive. We try and improve our hand by advising on wording in announcements, layouts on web pages, and communication at events. In short, we aspire to be the community’s PR firm.

This where you can help… Or, more precisely: we can help you. Come and visit us in our IRC channel, Telegram group or mailing list, and we can start working together to improve your online presence, get your project into the media, and grow your userbase.

We are already working consistently with Krita, Kdenlive, Atelier, Kontact, Plasma, Plasma Mobile and many others. As it is difficult to keep track of all the projects within KDE and the people behind them (this community is big), we often need you to come and tell us.

The point is, we are here for you… even if we don’t know who you are yet!

So the best way to get a handle on Promo is to read through the goals. And if things are still not clear or you need more details, come and talk to us. We at KDE Promo are a welcoming lot!

February 14, 2019

No, this is not a tutorial, unfortunately. The main reason being that, while I strive to do my best, I don't consider myself to be an excellent member of the Free Software community, let alone be able to teach others about it. But this morning I got an email from the FSF about a campaign for St. Valentine's day, which reminded me of something I've been planning to do since a long time ago, but never got to it.


I want to publicly send huge thanks to Robin Mills from the Exiv2 project, and not only because I've been fruitfully using his work in three (!) projects of mine (PhotoTeleport, Mappero Geotagger and Imaginario), but also, and especially, for being an extremely pleasant interlocutor. On the web, yes. Whereas most people tend to be more thorny and touchy in their interactions over the internet, Robin has always been friendly and coversational, trying to form a bond with some complete foreigner who just happened to report a bug on Exiv2.

Just adding some bits of information about one's personal events (such as travels) can make an enormous difference on how one's attitude is perceived. Mentioning that you visited the place that is familiar to the bug reporter almost makes one forget of being sitting in front of a computer on the internet, because your mind flies to that place. Considering that even on this personal blog of mine I'm kind of reticent about speaking of my private life, I cannot help appreciating the friendly attitude that Robin reserves for people writing on a bug tracker.

You are a wonderful netizen, Robin. A happy Valentine Day to you and your family. Thank you.

I was last week in Berlin at the Plasma Mobile sprint, graciously hosted by Endocode, almost exactly 9 years after the first Plasma Mobile sprint in which we first started to explore Plasma and other software by KDE on mobile phones, which at the time were just starting to become powerful enough to run a full Linux stack (Hi N900!)

Now the project got a wide breath of fresh air: the thing that impressed me the most was how many new faces came at the sprint and are now part of the project.

Compared to 9 years ago, we have a way saner and more robust ecosystem to play on. Instead of a single (and quite underpowered) phone, which was the N900, now we can hack on a wide variety of phones, thanks to ARM being slightly less painful to work with compared to back then (even tough still a long way to go to be considered an open hackable system from nay point of view) Some devices are starting to get upstream mainline kernel support, and for those (unfortunately, most) who don’t there is the Halium project to the rescue, which provides an abstraction layer between the Android kernel and the “proper Linux” userland, making possible to use its graphjics drivers to drive a Wayland session, access audio and connectivity and so on.

We have a Neon version which supports a reference device (the old Nexus-5x) which can be easily adapted to other devices, and PostmarketOS, which is a distribution which supports many different phones and several user interfaces, Plasma Mobile being one of the official ones. At the sprint there were also some people from the PostmarketOS project: one of the things i love most of open source is when different projects collaborate so closely.

We had also some new toys to play with: people from Purism were also present, bringing development kits for their upcoming Librem5 phone, which will support mainline kernel and no need for closed Android drivers. Even tough a lot of work is stil lto do, Plasma Mobile already boots on the device.

Plasma Mobile running on a Librem 5 devkit.

As for Plasma Mobile software in itself, we did many bugfixes on the main shell/homescreen to have a better first impact, and a significant improvement came in KWin about high DPI scaling when running on an Halium system.

Also, many improvoements were done in the Kirigami framework, which is the main toolkit recommended to be used to build applications for Plasma Mobile: as developers of several applications that use Kirigami were present there, we could do very fast feedback and debug sessions.

Older blog entries



Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.