KDE on Android: Cross-Compiling Docker Image

This is a short heads-up about our new Docker image for Android cross compiling. The Dockerfile can be found in the following repository:


For people never worked with Docker, I probably have to add slightly more information: Frankly, the Dockerfile is a recipe how Docker generates a system image that can be run as a virtual machine (for details, please use your favorite search machine). The virtual machine built by our Docker script provides a pre-configured cross-building environment for Qt applications on Android. Especially, our setup is very well suited to compile CMake-based Android projects, which use the cross-building toolchain from Extra-CMake-Modules. Using only 3 commands (see documentation at community.kde.org/Android), the virtual machine gets set up and one can directly start working.

At last, let me try to answer the question about why we are creating Docker images, which I actually got from various people. For me, there are at least three different answers:

  • Especially for starters it is not that simple to get their first cross-compiling infrastructure working (yeah, it is quit simple if you know what you have to do).
  • If we are looking ahead into the future, we will need a proper CI for Android builds and having a Docker image that can used for this is an important step.
  • For binary releases I would like to have a clean system and not generate the binaries on someones messy system that is patched together by numerous workarounds.

PS: many thanks to Ovidiu, who worked the last days on making this script use all the cool Docker functionality!

PPS: there is a new mailing list kde-android@kde.org for people interested in KDE on Android

Progress of KDE on Android Infrastructure

We have 2015 and Android is a very important platform for (mobile) applications and developers. — This somehow could also have been written a year ago, and actually it was stated then by several people. Those people also started porting some first applications from the KDE/Linux world to the Android platform. Yet, when looking at what happened the last year, as of now, we only have KAlgebra, GCompris and (since recent) Marble Maps that are available on Android.

The interesting question is, what holds back the many KDE applications that would also fit on an Android platform? During this year’s Randa sprint we took the opportunity and sat together to exchange what we learned during the last year. Looking at the different approaches of porting applications to Android,  we learned that already setting up a build system is a by far non-trivial job and probably one of the main points that holds people back from playing around with Android. Still, also the availability of KDE Framework libraries was not really tested in details yet, and without having availability guarantees it raises an uncertainty about how easy a port to Android might be.

To overcome these problems, we start with some simple approaches:

  1. Provide a simple and easy to use build environment.
    From the several existing toolchains for building Android applications, we started to reduce the number of different ones within the KDE projects to one. The new general toolchain (provided since some time via extra-cmake-modules) gained a new tutorial for how to use it. Further, by providing a build script for frameworks libraries, we make it easy to setup a whoel build environment that can directly be used for porting KDE applications that use KF5.
  2. Make development easy for new people.
    Initial work was started to create a docker image as a simple to use SDK. The goal is: run one command and get a fully setup build environment. With this approach we follow the way as it was started for Plasma Mobile.
  3. Availability of KDE Frameworks 5.
    We started to look into which frameworks currently can be built for Android. The list is already notably: kconfig, kcompletion, kitemmodelsm kitemviews, kcodecs, karchive, kguiaddons, kwidgetsaddons, attica, kdnssd, kapidox, kimageformats, and kplotting. For getting more frameworks build, the current two major blockers are building ki18n and kcoreaddons, which both need actual changes to the code to support the Android platform with its stripped down libc.

Looking at what was already achieved, the sprint itself was essential to get all people together to really work on this topic. As always, you can support this wok by donating for KDE’s sprints.
Though the work is not yet done, the basement is set to post some interesting news in the next weeks.

Artikulate Plans for Randa

Language learning is often considered as the task of memorizing new vocabulary and understanding the new grammar rules. Yet for most, the most challenging part is to actually get used to speak the new language. This is a problem that Artikulate approaches with a simple idea: to learn the correct pronunciation of a word or even a longer phrase, the learner listens to a native speaker recording, repeats and recordings it, and finally compares both recordings to improve herself/himself with the next try.

Since a while, Artikulate is shipped in the KDE Education module. Yet it is one of the few still Qt4-based applications. Actually, this is something that should change:) Most parts of the application is already ported to Qt5/KF5, yet the whole UI is still in an experimental porting stage, due to the invasive porting changes to QtQuick2. The next step is to finally complete this porting and even to go a step further. Since some time there are already quite promising mockups for a new UI around that were discussed here.

An excellent opportunity to work in this is the upcoming sprint in Randa. But since mere coding is maybe not enough to justify, why one should travel in the middle of the alps, the plans for that week are more ambitious:

  • finish the UI port and apply the new UI layout: see above
  • prepare a first touch prototype: this is an excellent opportunity, since all the mobile experts are there
  • record some very basic course sets: currently we only have many recordings for Bengali and Polish, but many contributors with different tongths around in Randa; my goal is to have some mini-courses for the languages I need most often when traveling through Europe, and particularly tailored to the basic words needed on such trips.

Your help is Needed
Sprints like the upcoming sprint in Randa are essential to keep developers busy developing, to provide them with opportunities to discuss their projects’ next steps, and give them the chance to exchange wisdom/experience/ideas. And probably not less important, to keep the community feeling alife that KDE is all about. You can help with even a small donation. How exactly, is explained here:

Randa Fundraiser-Banner-2015

The QML State Machine

The Qt 5.4 release is coming closer and it brings a whole lot of nice things: high DPI support, Qt WebChannel, and much more. One of these very cool, yet maybe slightly inconspicuous, new features is the QML State Machine. It brings a fully featured state machine to the QML world, which is a finite automaton consisting of states, transitions that define on which event to transit from one state to another, and event handlers that are called when a stated is left or entered.

Despite its simplicity, a state machines features a very powerful tool to ease the creation and maintenance of complex QtQuick UIs. In a former post I very briefly talked about the rewrite of Rocs’ visual graph editor in QtQuick. A major problem of this rewrite was that it became (even with only basic functionality) a very complex beast to handle. To give a little bit of context first, the visual graph editor currently consists of four mutual exclusive actions that can be performed at a scene: select some and/or move the selected nodes, connect two nodes by an edge, create a new node, delete scene elements by clicking at them.

Now, I played around with rewriting this functionality by using state machines, mostly to figure out how effective state machines are for this use case. For my experiment I ported the first two of these actions, whereas activating an action simply starts a corresponding state machine. For the select-move action the state machine code looks something like this (compared to the original code that lives in the editorStateMachine branch in the Rocs repository for now, functionality is simplified a little bit to improve readability):

import QtQml.StateMachine 1.0 as DSM
DSM.StateMachine {
    id: dsmSelectMove
    initialState: smStateIdle
    running: true
    DSM.State {
        id: smStateIdle
        DSM.SignalTransition {
            targetState: smStateMoving
            signal: scene.onMousePressed
            guard: scene.mousePressPerformedAtNode
        DSM.SignalTransition {
            targetState: smStateSelecting
            signal: scene.onMousePressed
            guard: !scene.mousePressPerformedAtNode
        DSM.SignalTransition {
            signal: scene.onMouseClicked
            onTriggered: {
    DSM.State {
        id: smStateSelecting
        DSM.SignalTransition {
            signal: scene.onMousePositionChanged
            onTriggered: {
                selectionRect.visible = true
                selectionRect.to = scene.currentMousePosition
        DSM.SignalTransition {
            targetState: smStateIdle
            signal: sceneAction.onMouseReleased
        onEntered: {
            selectionRect.from = scene.lastMousePressedPosition
        onExited: {
            selectionRect.visible = false
    DSM.State {
        id: smStateMoving
        DSM.SignalTransition {
            targetState: smStateIdle
            signal: scene.onMouseReleased
        onEntered: {
        onExited: {

The code itself probably can live without further comments, except that scene is the component containing all elements and that the scene re-transmits all mouse events which happen there. Furthermore, the selectionRect element is a rectangle that is displayed whenever the mouse is pressed at the scene and moved in some direction (hence, a selection rectangle:) ). If you know some QtQuick you probably can estimate how this functionality is implemented in a typical way: you have to create a lot of bindings, properties that store state information, and maybe actually some QtQuick states — with the result of having the logic distributed over the whole QML file.

This problem mostly vanishes when using state machines, and furthermore, by using state transitions one can drastically improve readability. Try it yourself! And thanks to the devs who implemented this cool tool!

Rocs KF5 Progress

Main message: The Rocs frameworks branch is finally merged into the master branch (but too late for Applications 14.12 release). It has tons of changes, not only porting ones but rather refactorings and technology changes.

And now in Details: The work on the Rocs frameworks port was quite a bumpy road. Back in early spring this year, I started with an initial porting afford to KF5/Qt5, but soon it turned out that there was a chance of combining this porting with a long outstanding code refactoring of the application’s core. Before I am going into details, here some numbers of this port:

  • 835 files changed
  • 36924 insertions(+), 62342 deletions(-)
  • 379 commits

Having these numbers in mind, I also made the decision to take some more time for stabilizing the code base until the spring release and not to rush into the Applications 14.12 release. However, most work is already switched to polishing the remaining glitches and fixing the bugs that were undoubtedly introduced with these big changes. And for my personal usage, I can say, that the current master branch version is already quite usable on a daily base.

Rocs Qt5/KF5 Port

The big refactorings in a nutshell:

  1. Proper project support.
    We have a long history of at first only operating on a loose set of graph and script files, then introduced projects to (optionally) organize these files. Now the core of each Rocs session is a project, which on the one hand makes the workflow much simpler and on the other hand simplifies the code base quite a lot (now there is only one place in code that cares about project files and sessions).
  2. A scene graph based visual graph editor.
    Rocs in the 1.x versions used a graphics view for providing a visual editor for graphs. But this part in particular was a “grown” code base, containing some of the oldest code in Rocs (~7 years). With having QtQuick as a kind of successor technology for our use case, I started a complete rewrite of the editor in QtQuick. The graph editor is already usable but still contains many glitches and some features are missing, compared to the old one. This will probably be the main area of work until the spring release in 2015.
  3. A leaner graph model with better scripting API.
    One part of Rocs that is of most importance to me, as someone who uses the application to actually do research and test graph algorithms, is the graph model. Rocs has an internal representation of a graph theoretical graph, consisting of nodes, edges, dynamic properties at these elements, and a set of basic graph operations. Due to history, the graph model was never completely covered by unit tests and further, over the years, gained many (and some of them hacky) extensions: elements received types, graphs gained the option to represent different data structures, several versions of different scripting APIs were introduced… So, during this port, the graph model was completely rewritten from scratch, but with all the lessons learned over the years. And as a plus, following a test driven approach, every operation is unit tested! Having the experience of working on the model for some years, it was also possible to make it much leaner and only provide API and functionality that is actually used somewhere in the application. Together with the visual editor the graph model forms the new (but internal for now) graphtheory library.

During the next month, I will try to talk in more details about each of these points, as I think for each of them there are interesting things to tell, and that not only for Rocs developers:)

Randa report: Artikulate KF5 port (almost) done

It is the Randa-Sprint week again. If you never heard about this, then imagine a lot of KDE developers, meeting somewhere in the mid of the Swiss Alps, in a deep valley with a rather slow internet connection. These people are coming from all over the world and are here for exactly one week, to work, to discuss, and to create the future of KDE. To name only a few of the current meeting’s topics, there are people working on a KDE SDK, porting to KF5, writing the KF5 book (aka putting documentation to the KF5), reaching out for new platforms, and many more exciting things are happening here. If you want to know more about all the goods that the Randa meeting brings, you should probably have an eye on the planetkde.org posts for the next days.

My own small contribution during the last few days was working on the KF5 porting efforts in KDE Edu. And finally, the Artikulate port is mainly done: It compiles. It runs. And the core functionality is working. Nevertheless, there are still a lot of glitches, which have to be ironed out. (Especially, since I did a very bumpy porting from QtQuick1/PlasmaComponents to QtQuick2/QtQuick.Controls…) Yet, they still have to wait a little bit, since currently there is work ongoing on getting a new freshed-up layout… Interested? Then, have a look at the Forum.

Artikulate on KF5

KDE Edu speaks AppData

Just in time before the KDE SC 4.14 string freeze applies, I merged my last AppData patches and as of now: all KDE Edu applications provide AppData meta information. This means, they will be better visible in software centers like Apper or GNOME-Software.

Well, this is only a very short announcement, if you want to read more about the benefits of and ideas behind AppData and AppStream, please have a look at Ximion’s blog.

Just a personal experience note after touching those > 20 files: The auto generated files are quite helpful and provide a good start. But effectively, every file had to be adjusted by hand. This does not come from the generation scripts but from the fact that we have a multitude of application descriptions, webpages, and screenshots that are not all in sync (yet). The most common things that had to be updated in the pre-generated files were:

  • The homepage address was missing or pointing to an outdated page.
  • The screenshot URLs were broken, missing, or we provided an awfully old version somewhere at our websites (will be fixed soon or is already fixed😉
  • The description texts were often quite out of date.

So the next step after having this up-to-date AppData files is to backport the updates to the websites. In particular, I am looking forward to re-use the AppData files to have an easier way to generate the static application data on our websites. But more to that in a later blog post…

By the way: There is currently happening a lot in KDE Edu and you can help all those people who create free and open educational software for you by supporting the upcoming sprint in Randa:

Donations can be done HERE.


Get every new post delivered to your Inbox.