The Evolution of Plasma Mobile

Plasma Mobile
Plasma Mobile

Back around 2006, when the Plasma project was started by Aaron Seigo and a group of brave hackers (among which, yours truly) we wanted to create a user interface that is future-proof. We didn’t want to create something that would only run on desktop devices (or laptops), but a code-base that grows with us into whatever the future would bring. Mobile devices were already getting more powerful, but would usually run entirely different software than desktop devices. We wondered why. The Linux kernel served as a wonderful example. Linux runs on a wide range of devices, from super computers to embedded systems, you would set it up for the target system and it would run largely without code changes. Linux architecture is in fact convergent. Could we do something similar at the user interface level?

Plasma Netbook

In 2007, Asus introduced the Eee PC, a small, inexpensive laptop. Netbooks proved to be all the rage at that point, so around 2009, we created Plasma Netbook, proving for the first time that we could actually serve different device user interfaces from the same code-base. There was a decent amount of code-sharing, but Plasma Netbook also helped us identifying areas in which we wanted to do better.

Plasma Mobile (I)

Come 2010, we got our hands on an N900 by Nokia, running Maemo, a mobile version of Linux. Within a week, during a sprint, we worked on a proof-of-concept mobile interface of Plasma:

Well, Nokia-as-we-knew-it is dead now, and Plasma never materialized on Nokia devices.

Plasma Active

Plasma Active was built as a successor to the early prototypes, and our first attempt at creating something for end-users. Conceived in 2011, the idea was not just to produce a simple Plasma user interface for a tablet device, but also deliver on a range of novel ideas for interaction with the device, closely related to the semantic desktop. Interlinked documents, contacts, sharing built right into the core, not just a “dumb” platform to run apps on, but a holistic system that allows users to manage their digital life on the fly. While Plasma Active had great promise and a lot of innovative potential, it never materialized for end-users in part due to lack of interest from both, the KDE community itself, but also from people on the outside. This doesn’t mean that the work put into it was lost, but thanks to a convergent code-base, many improvements made primarily with Plasma Active in mind have improved Plasma for all its users and continue to do so today. In many ways, Active proved valuable as a playground, as a clean slate where we want to take the technology, and how we can improve our developemnt process. It’s not a surprise that Plasma 5 today is developed in a process very similar to how we approached Plasma Active back then.

Plasma Mobile (II)

Learning from the Plasma Active project, in 2015 we regrouped and started to build a rather simple smartphone user interface, along with a reference software stack that would allow us not only to develop Plasma Mobile further, but to allow us to run on a growing number of devices. Plasma Mobile (II)’s goal wasn’t to get the most innovative of interfaces out, but to create a bread-and-butter platform, a base to develop applications on. From a technology point of view, Plasma is actually very small. It shares approximately 95% of the code with its desktop companion, widgets, and increasingly applications are interchangeable between the two.

Plasma Mobile (in any shape or form) has never been this close to actually making it into the hands and pockets of end users. A collaboration project with Purism, a company bringing privacy and software freedom to end-users, we may create the first Plasma phone for end users and have it on the market as soon as januari 2019. If you want to support this project, the crowdfunding campaign has just passed the 40% mark, and you can be part of it — either by joining the development crew, or by pre-ordering a device and thereby funding the development.

Convergence through Divergence

It’s that time of the year again, it seems: I’m working on KPluginMetaData improvements.

In this article, I am describing a new feature that allows developers to filter applications and plugins depending on the target device they are used on. The article targets developers and device integrators and is of a very technical nature.

Different apps per device

This time around, I’m adding a mechanism that allows us to list plugins, applications (and the general “service”) specific for a given form factor. In normal-people-language, that means that I want to make it possible to specify whether an application or plugin should be shown in the user interface of a given device. Let’s look at an example: KMail. KMail has two user interfaces, the desktop version, a traditional fat client offering all the features that an email client could possibly have, and a touch-friendly version that works well on devices such as smart phones and tablets. If both are installed, which should be shown in the user interface, for example the launcher? The answer is, unfortunately: we can’t really tell as there currently is no scheme to derive this information from in a reliable way. With the current functionality that is offered by KDE Frameworks and Plasma, we’d simply list both applications, they’re both installed and there is no metadata that could possibly tell us the difference.

Now the same problem applies to not only applications, but also, for example to settings modules. A settings module (in Frameworks terms “KCM”) can be useful on the desktop, but ignored for a media center. There may also be modules which provide similar functionality, but for a different use case. We don’t want to create a mess of overlapping modules, however, so again, we need some kind of filtering.

Metadata to the rescue

Enter KPluginMetaData. KPluginMetaData gives information about an application, a plugin or something like this. It lists name, icon, author, license and a whole bunch of other things, and it lies at the base of things such as the Kickoff application launcher, KWin’s desktop effects listing, and basically everything that’s extensible or uses plugins.

I have just merged a change to KPluginMetaData that allows all these things to specify what form factor it’s relevant and useful for. This means that you can install for example KDevelop on a system that can be either a laptop or a mediacenter, and an application listing can be adapted to only show KDevelop when in desktop mode, and skipping it in media center mode. This is of great value when you want to unclutter the UI by filtering out irrelevant “stuff”. As this mechanism is implemented at the base level, KPluginMetaData, it’s available everywhere, using the exact same mechanism. When listing or loading “something”, you simply check if your current formfactor is among the suggested useful ones for an app or plugin, and based on that you make a decision whether to list it or skip it.

With increasing convergence between user interfaces, this mechanism allows us to adapt the user interface and its functionality in a fully dynamic way, and reduces clutter.

Getting down and dirty

So, how does this look exactly? Let’s take KMail as example, and assume for the sake of this example that we have two executables, kmail and kmail-touch. Two desktop files are installed, which I’ll list here in short form.

For the desktop fat client:

Comment=Fat-client for your email

For the touch-friendly version:

Comment=Touch-friendly email client

Note that that “FormFactors” key does not just take one fixed value, but allows specifying a list of values — an application may support more than one form-factor. This is reflected throughout the API with the plural form being used. Now the only thing the application launcher has to do is to check if the current form-factor is among the supplied ones, for example like this:

foreach (const KPluginMetaData &app, allApps) {
    if (app.formFactors().count() == 0 || app->formFactors().contains("desktop")) {

In this example, we check if the plugin metadata does specify the form-factor by counting the elements, and if it does, we check whether “desktop” is among them. For the above mentioned example files, it would mean that the fat client will be added to the list, and the touch-friendly one won’t. I’ll leave it as an exercise to the reader how one could filter only applications that are specifically suitable for example for a tablet device.

What devices are supported?

KPluginMetaData does not itself check if any of the values make sense. This is done by design because we want to allow for a wide range of form-factors, and we simply don’t know yet which devices this mechanism will be used on in the future. As such, the values are free-form and part of the contract between the “reader” (for example a launcher or a plugin listing) and the plugins themselves. There are a few commonly used values already (desktop, mediacenter, tablet, handset), but in principle, adding new form-factors (such as smartwatches, toasters, spaceships or frobulators) is possible, and part of its design.

For application developers

Application developers are encouraged to add this metadata to their .desktop files. Simply adding a line like the FormFactors one in the above examples will help to offer the application on different devices. If your application is desktop-only, this is not really urgent, as in the case of the desktop launchers (Kickoff, Kicker, KRunner and friends), we’ll likely use a mechanism like the above: No formfactors specified means: list it. For devices where most of the applications to be found will likely not work, marking your app with a specific FormFactor will increase the chances of it being found. As applications are being adopted to respect the form-factor’s metadata, its usefulness will increase. So if you know your app will work well with a remote control, add “mediacenter”, if you know it works well on touch devices with a reasonably sized display, add “tablet”, and so on.


We now have basic API, but nobody uses it (a chicken-and-egg situation, really). I expect that one of the first users of this will be Plasma Mediacenter. Bhushan is currently working on the integration of Plasma widgets into its user interface, and he has already expressed interest in using this exact mechanism. As KDE software moves onto a wider range of devices, this functionality will be one of the cornerstones of the device-adaptable user interface. If we want to use device UIs to their full potential, we do not just need converging code, we also need to add divergence features to allow benefiting from the difference of devices.

Plasma 5 Ingredients

Plasma 5.0 is out!

Plasma 5.0 is out. I’ve compiled a (non-exhaustive) list of ingredients and that have been put into this release to give the reader an estimate of the dimensions of the project and the achievement of this milestone:

  • 46 kilo of espresso (pure arabica)
  • The milk of 3 cows
  • a Swiss mountain of chocolate
  • 140 sleepless nights mulling over code
  • 354 liters of pressurized air breathed during scuba dives
  • One encounter with a Mantis shrimp
  • The total length of 43 bathtubs full of tiger tails fixed in pixel-alignment problems
  • 817 hours spent in front of webcams
  • 189MB of irc lines written (compressed)
  • 80.000 automated builds to keep us in check
  • 2403 bugs in the code that had to die
  • A swimming-pool full of tears cried over graphics driver problems and crashers buried deep down in scripting engines, scenegraphs and (the pool allegedly was previously used for skateboarding by Greg KH)
  • 5 magic wands
  • 800 million pixels
  • 37843200000 frames rendered
  • Too many puppies
  • 7 virtual goats sacrificed during a total of 28 full moon ceremonies
  • 450 ml of holy water
  • 76 rock bands
  • 119 beats per minute
  • 8 bits alpha channels
  • 52 WTFs
  • The equivalent of 3 dead trees in recycled paper
  • 2 small branches of cederwood for pencils
  • 1 box of crayons

Nothing like entirely made-up statistics.


Plasma == ♥

… but also some really hard work, made possible by the sacrifices (see above) of many great people.

Next means Focus on the Core

The metaphor of a home make-over crossed my mind today, and I think it implies a few ideas that connect to Plasma Next quite well.
Plasma Next
Plasma Next is a new iteration of the Plasma workspaces. This is the first time, that KDE’s workspace is released independently from its underlying libraries and the applications accompanying it. It is built upon KDE Frameworks 5 and Qt5. “Plasma Next” is our name for the development version of Plasma, the final product will not be called “Next”. The planned release does not include the applications that are shipped today as part of the KDE Software Compilation. Applications, just like the Frameworks follow a different release schedule. Of course it’s entirely possible to run KDE SC 4 Applications on a Plasma Next desktop, and vice versa.

We have now settled on a release schedule for Plasma Next, which plans for the first stable release in June. It’s a good time to talk about what’s to expect in this first release. I think we’ve got some pretty exciting improved technology in the works. As our new baby shapes up, let’s take a look at what’s old and what’s new in more detail.

Frameworks 5

Plasma Next bases on KDE Frameworks 5, which is a modularized version of the venerable KDE development platform, kdelibs and friends, so to say. This results in a reduced footprint in terms of dependencies. The Plasma libraries and runtime components are one of those Frameworks itself, providing the tools to build applications and workspaces. Plasma has been one of the early adopters of Frameworks 5, mainly for the reason that we had to do some development in parallel. While building on an unstable base wasn’t always easy, it certainly has its benefits: We could check the viability of the Frameworks goals, and catch regressions early on. A good test harness only goes so far, actually building a real world application with the libraries makes sure they’re stable and functioning. These days, the issues are gone, KDE Frameworks has stabilised enough that applications can be ported quite easily.
With the move to Frameworks 5 come some architectural changes that allow us to cut out some “runtime fat”, we can get rid of some separate processes with the new architecture, which results in a leaner system for the user.

QtQuick for the UI

Plasma Next wallpaper selection
Plasma Next wallpaper selection

The transition to QtQuick reaches a very significant milestone in Plasma Next: the whole UI is written in QML. This concludes a transition process which we’ve started in Plasma 4.x, as a side-effect it solves a whole class of long-standing quality and maintenance problem in the code, it means a higher quality for many users. The transition to QtQuick-based UI has been fairly smooth so far, so we are not jumping onto something entirely new here, which means that we have been able to port much of the existing and matured functionality from Plasma 4.x over to Plasma Next. Our QML APIs have not changed radically, so porting existing code written in QML to Plasma Next is not a huge amount of work. For add-ons written in other languages (UIs written in C++, Python and other languages are currently not supported, this is a conscious design decision, and unless there are QML bindings for these languages (which seems like a weird idea), this is unlikely to be supported in the future. Instead we’ve improved and matured the QML API to a level where it’s very easy to create almost anything you can dream of in QML.

New Graphics Stack

Plasma’s graphical stack reaches a new state-of-the-art this year. We are now able to fully offload the rendering of the UI into threads, and other processes, making the UI responsive by default. We also offload visual effects almost entirely onto the graphics card. This means that it’s faster, so you get better framerates out of it, it frees up CPU time for the user and it’s also more energy-efficient, so saves some battery life.
In case the system falls back to software rendering, we can now centrally disable animations, so even on systems that paint slowly, or we can reduce repaints drastically to give a snappy feel. This means that the visual effects in the UI degrade gracefully with available graphics features on the system. For the vast majority of users, this isn’t an issue anyway, their systems run a fully hardware-accelerated desktop with complete ease. On these systems we can improve the user experience by using the graphics card’s capability — and not only that: The transition to QtQuick 2, which is part of Qt5 means that all the work at UI level can be offloaded onto the GPU as well.

Another hot topic these days is Wayland readiness. This is currently work in progress, Martin Gräßlin’s blog shows some impressive progress on running KDE applications on Wayland. This is one of many important milestones. The most complex case is running a full Wayland session with Plasma and KDE applications, and we are not there yet. Wayland support is continuously improved.

Polished Interaction

Let's try a dark theme
Let’s try a dark theme

Next to these architectural changes, we’ve also put some work into the actual UI visuals and interaction. We are in the process of establishing a Visual Design Group in KDE. Which already participates in the development of Plasma Next. The first results of this will be visible this summer, and the group is currently hashing out plans for the future. There is some serious design love appearing. You can follow the progress of it on the wheeldesign blog.

One of my favourite new features that has recently landed is Marco’s work on contrast behind translucent dialogs, which hugely improves readability in many cases, and make “the old Plasma” almost look bland in comparison. We’ve cleaned up quite a lot of workflows, not by making them any different, but by removing visual noise in between. The idea is to polish common elements to feel fresh and like an upgrade to users, but not entirely different. In the UI, known behavioral patterns are kept in place, with more pronounced core functions, and less fuzz around them. We’re aiming at keeping all the functionality and adaptability in place. To the user, the migration to Plasma Next should feel like an upgrade, not something completely new, but trusted after a bigger step in its evolution, yet recognizably true to its values.

We want to achieve this by concentrating on the core values, on what makes us good, and what users love us for. But we also do not want to pass the opportunity to fix what nags us and our users. Improvements in details mean that we listen to our users, a large portion of which do not want to be the subject of UI experiments, but who require a reliable system that supports and improves the personal workflows they have almost brought to perfection.

Of course, all of these workflows rely on many details behaving as they do, and these things are different for everyone. A small difference in behavior, or a missing seemingly minor feature might make or break any given workflow, there is no guarantee to be made, just a promise of best effort.
Many, but not all parts are co-installable, and it will be possible to use KDE SC 4 applications in a Plasma Next environment, and vice versa.

Beyond Devices

Plasma Next runs on top of a device-independent shell. The whole UI is structured into logical blocks that can be exchanged at runtime, this allows for dynamic switching the user interface to suit a different form factor. A target device will typically have the plasma-shell (and runtime bits) installed, and one or more device-specific shells. We are now readying the first of these “workspace user experiences”, Plasma Desktop. Others, such as the tablet-oriented Plasma Active UX will join in subsequent releases.

When will it be good enough for me?

While no .0 will ever be perfect, I expect that Plasma Next.0 will feel very much like an evolutionary step to the user, and certainly miles away compared to the impact of Plasma in KDE 4.0. For those that still remember the transition from KDE 2.2 to KDE 3.0, this seems rather comparable. While KDE 2 was almost a complete rewrite of KDE 1, the 2 to 3 transition was much less radical and far-reaching. We saw the same pattern between KDE 3 and 4, which again was quite radical, especially in and kdelibs and even more so for the workspace — Plasma which was completely new in 4.0.

In the first stable release of Plasma Next we want to provide a stable and fully functional core desktop. We concentrate on making the most important default functionality available, and are polishing this first and foremost. I expect that most users can be just happy with this first release, but as I said, there’s no guarantee, and maybe you’re missing something. For those that want to make the switch later, we have of course our long-term maintained current Plasma stable, so there’s no rush.
This concentration on the core also means that not every single feature will be available immediately. We are, however aiming at feature parity, so in most cases, a missing feature in .0 will be brought back in a later release. The kdeplasma-addons module, which contains additional functionality will likely not be ported by summer.

Ultimately, the way to make a good Plasma Next happen is to lend us a hand and take part. Even better, you don’t have to wait with this until summer. Take the plunge, build KDE Frameworks 5 and Plasma Next, try it and help us completing the core functionality and to fix bugs. That is exactly what we will be doing in the next months leading up to the release this summer, and we hope the experience will be delightful one for our users.

Reasonable DPI in Plasma Next

We are currently looking into how we can improve Plasma (but in extension also other applications, including QWidget-based ones) on hardware that sports unusually high DPI (also called “reasonable DPI”). In this article, I’ll outline the problem space and explain our tools to improve support for high DPI devices in Plasma.

First, let’s take a step back, however, to explain the problem space to those who haven’t yet spent that much thinking on this. Most of today’s desktops and laptops have have roughly the same amount of pixels per square inch of screen space. The amount of pixels per inch is measured in DPI (dots per inch) or PPI (pixels per inch). This value is around 100 DPI for laptops. Tablets and smartphones are already available with much higher DPI screens, making for sharper fonts and overall higher fidelity graphics. A while ago, Apple has started producing laptops with high DPI displays as well, these are the so-called Retina screens. There are Macbooks on the market with 220 DPI.

Test Plasmoid showing a scaled UI
Test Plasmoid showing a scaled UI

Some people have complained for years about the low DPI value of screens available on the market (and I am one of them), higher DPI simply allows for nicer looks, and reduces the need for “dirty tricks” such as subpixel rendering algorithms (which come with their own set of problems). Graphics chips also have become fast enough (and with enough memory) to not have a problem with high resolutions (think 4K on your laptop, for example).

I’ve done some research (Well, lazy-webbing, mostly), and it seems that higher DPI screens for desktop systems, but also for laptops are still quite rare, and when you find one, they’re often really, really expensive. I believe this is caused by two reasons: production-line quality is not always good enough to produce high DPI screens, one could say that the more pixels there are on a given device, the higher the chance that one or more of them are dead, making the display unsellable, and thus increasing the price of the ones that are pixel-perfect. Also, tablets and smartphones, which often already sport high DPI screens are currently taking up almost all of the production capacity. The obvious result is scarcity and a high price. I believe it’s only a matter of time until high DPI displays become more common, however. A few friends of mine already have high DPI displays, so there is a real need to support this kind of screen well.

Battery Widget without icon scaling
Battery Widget without icon scaling

So what’s the problem? Many applications assume a fixed DPI size, or at least that the DPI value of the screen is within a certain range, so that when you render an icon at 22 pixels, it will look like a small icon, compared to text, and that its details are visible. Also, icons and sizing of fonts are loosely related, so an icon that is way smaller than the size of the text as rendered will look weird and cause layouting problems. (Imagine huge letters and cut off text, for example.)
For graphical elements, this is a real problem, but less so for text. Today’s text rendering engines (Freetype, for example) take the DPI value of the screen into account. This means that this at least partly solves our problem. Luckily, it solves the problem for very complex cases, so at least this is not of great concern. It’s only a partial solution, however, so this at best eases finding a complete solution. We need to fix these problems in different areas, and all need to have well-thought out solutions.

Limitations in X11

The bad news is that this problem is only partly solvable in an X11 world. X11 has no real concept of different DPI values per screen. This is not so much a problem for single screen systems — we just use the DPI of the only screen. As soon as you attach a second screen that has a different DPI, this is going to be a problem, and it’s not possible to solve this completely in an X11 world. We’re planning to first make it work in a single DPI environment, and then work towards supporting different DPI values per screen. (Of course we’ll keep multi-DPI-screens in mind, so that we don’t have to take too many steps back once we are actually in a position to be able to support this. This means Wayland, basically.)

Battery Widget using icon scaling
Battery Widget using icon scaling

Cheating with fonts

A pretty easy, yet neat solution is to use font metrics to compute sensible dimensions for graphical elements on the screen. The very short version is to stop thinking in numbers of pixels, and to start thinking in lines of text and with of characters as they end up on the screen. This is not a pure solution to the DPI problem, which in many cases is actually an advantage. The size (for example height) of a given letter rendered on the screen depends on a number of properties:

  • The DPI value of the screen which is used to render the text
  • The font size setting
  • The size of the font itself, as it is designed (this is usually more relevant for the aspect ratio between width and height)

This means that taking the font height as rendered, we actually can compute values for sizing elements that not only take the low-level technical properties of the hardware into account, but also user preferences (or system presets). In Plasma 2, we started using this mechanism in a number of places, and so far we’re pretty happy with the results. Some examples which where we use this is the sizing of popups coming out of the panel (for the notification area and the calendar for example), but also the sizing of the icons in the notification area (or system tray). This means instead of hardcoding pixel sizes, these UI elements grow and shrink depending on your settings. This solves a part of the problem, but is obviously not a complete solution. If you would like to implement this mechanism, here’s two snippets of code, which, with some necessary adaption, you can use to make your app work well on High DPI devices.

in Qt C++ code:

const int fontHeight = QFontMetrics(QApplication::font()).boundingRect("M").size().height();

This gives you the height of the letter “M” as it would be rendered on the screen. It’s a useful mechanism to get you a pixelsize that is dependent on the DPI value of the screen. Note that you want to use an int here, in order to not end up aligning UI elements at half pixels, as this leads to blurriness in your UI.)

We’ve bridged this API in the Plasma Theme class, which is available from QML applications by importing org.kde.plasma.core (the global property theme will be automatically set, which allows you easy access to Plasma::Theme from everywhere, in case you’re wondering where the “theme” variable is coming from).

import org.kde.plasma.core 2.0 as PlasmaCore

/* Paint an orange rectangle on the screen that scales with DPI 
   This example makes the rect big enough to paint about 8 rows
   of text (minus spacing), and allows for a column with of about 
   60 characters. Mileage varies on fonts used, and the text 
   itself, so this is an approximation.
Rectangle {
    width: theme.mSize(theme.defaultFont).height * 8
    height: theme.mSize(theme.defaultFont).width * 60
    anchors.margins: units.largeSpacing

    Item {
        anchors.fill: parent
        /* ... more stuff ... */

In the second example, you see that we’re using another property, “units.largeSpacing” for the margins. This is another piece of DPI-dependent UI which you can use to apply margins and spacing that take DPI (actually font-as-rendered-settings) into account.
To get the size of a piece of text on the screen, in QtQuick code, you can use the paintedWidth property of a Text elements, but not that this can be tricky due to text elision, line breaks, etc., so this is to be dealt with with care.

Icons and other graphical elements

Another interesting case which affects the usability of our graphcal interfaces on high-DPI screens is the sizing of icons. We are using standard sizes there, which you access via properties “units.iconSizes.small”, “units.iconSizes.large”, etc.. In Plasma, these sizes now get interpolated with the DPI value of the screen, while making sure the icons are still getting rendered correctly. The sizing is done in steps, and not linearly to avoid getting washed-out icons. This mechanism works well and automatically solves another piece of the puzzle. The result of doing this is a more balanced look and better alignment and spacing across some widgets (notably the battery gains quite a bit of beauty with this treatment).
In other UI elements, especially the toolkitty widgets we provide in PlasmaComponents, we often already scale with the text, which works just fine for reasonably-but-not-excessively high DPI values. We have done some experiments with scaling up the graphical elements that are used to, for example, render a button. As we are using SVG graphics throughout the user interface, we don’t have to resolve to dirty tricks such as doubling pixels, and we can get quite neat results. This needs some more work, and it hasn’t been merged into master yet.

The Higher-Level Picture

Now, having discussed lots of technical details, how does the user-facing side of this look and work? The changes we’ve done right now only affect the user in one way: More UI elements scale with the DPI of the screen, this means no change for displays around 100 DPI. On my laptop (which has a 180 DPI screen), this gives a more balanced picture.
As Plasma is making its way onto a wider range of target devices (think tablets, media centers, as well as high-dpi laptops or monitors), this topic becomes increasinly important. I have good hopes that we will be able to solve this problem in a way that really leverages the power of this kind of hardware. In Plasma Next, we’re now providing some of the basic tools to make UIs work well on high-DPI displays, and we’ll continue this route further on. The user will notice that in Plasma Next, most of the problems that could be seen on high DPI screen are gone, and that the whole behaves much better without many tricks.

Responsible Evolution

Plasma Desktop running on top of Qt 5 and KDE Frameworks 5
Plasma Desktop running on top of Qt 5 and KDE Frameworks 5

Exciting times. I am working on the lower-right corner of the desktop right now, and thought I could give a quick visual update of progress there, as well as some sense of direction where we’re heading, how the user interface evolves, Plasma’s new architecture, and underlying software stack and the device spectrum. A whole mouthful, so grab a cup of tea.

Two areas in particular are catching my attention these days, the notification area (“system tray”, that row of icons which show you the status of all kinds of things), and the clock with its calendar popup. The calendar shows quite nicely some things we want to pay attention to in Plasma 2: consistency and elegance. We are making more use of pronounced typography, are fixing alignment problems, and are looking for a generally more elegant way of presenting the common functionality. In that, the plan is not to make a lot of changes to the functionality itself, not cutting down the UI, but polishing what is already there. By reducing the workspace’s mental friction for the user makes the tools take a step back and give more room to the content and interaction that is presented. Doing that, the workspace should be functional, yet elegant. The migration should feel like an upgrade of something familiar. We want to make it functionality-wise equivalent, but more polished. On top of that, we’re readying the technology for future use cases, and evolution of the underlying technology stack.

Calender popping up from the Plasma panel
Calender popping up from the Plasma panel

QtQuick 2 actually makes these things a lot easier, as it is much more correct in terms of calculating font metrics reliably, which we need to (sub-)pixel-perfectly align text and other UI elements. Trying to make this exact in Qt4 and on top of QGraphicsView was a shortcut into madness. Ever so slightly off font metrics, and wonky layouts get you to tear your hair out pretty quicky. This is much better now, (though certainly not perfect in all areas), so it allows us to finally fix these jarring little mis-alignments that nag the eye. The calendar already does it pretty well, and serves as a nice example. This implementation takes the physical size of the pixel on the screen into account by correcting for DPI in the whole layout, so it works nicely on all resolutions and pixel densities. With higher pixel-density displays, the rendering gets more details, fonts look neater, but the size of interaction areas, and the effective size on the screen don’t change much. The screenshots have been taken on a 170 DPI display, so if the fonts seem huge on your display (or small, as I hope for you), this would be the reason for that.

Battery Monitor
Battery Monitor

In the notification area, you might notice that the widgets that have been living in there are now contained in the same popup. This results in less window management and layering of small popups in the notification area, clearer navigation and a cleaner look. The currently active icon has slightly pronounced visuals compared to the others.
The calendar will of course show information about tasks and agenda (this part doesn’t work yet). One neat thing which the new architecture allowed use to do very easily is lazy-loading the calendar. As just loading the calendar can result in quite a bit of loading underneath, delaying to loading it on-demand speeds up start-up time and lowers memory consumption in a lot of cases.

Below the surface, the changes are more radical. Qt5 and with it the move to QtQuick 2, the scenegraph-based successor to QtQuick 1, a new QML and javascript engine which is smaller and more optimized for Qt data types and conventions than V8, new sandboxing features, being able to render and composite pretty much entirely on the graphics card, share textures between compositor and workspace shell, addition of Wayland as a fully supported target platform, and along with all that new input and security features.

Network ManagementNetwork Management in the notification area
Network Management in the notification area

Plasma 2 is a converging user interface. It allows to control the Look and Feel at different levels. On the lower level / higher detail side of the scale, we look at adjusting input areas, sizing of ui elements, and interaction schemes by swapping out and “overriding” parts of the UI toolkit with, for example, touch friendly versions of widgets. On a higher level, we support laying out the furniture of the workspace (think of alt+tab window switcher, log in, lock, etc. features) by more code sharing and a different logic to how they’re loaded (and swapped out). Plasma shell allows dynamic switching of shell layouts at run-time. The shell is equipped to morph between workspace presentations, so should your tablet suddenly get a keyboard and mouse plugged in, it changes its disguise to a traditional (actually your own customized) desktop layout. While this is cool, in reverse, it allows us to isolate changes that are done to suit other devices from the “Desktop Experience”. Just because the workspace support multiple devices, the user doesn’t get the lowest common denominator, but specialization. Different devices are different for a reason, and so should the UI be. “Mobile-friendly” shouldn’t mean “misses features”, but “responsibly designed” (excuse the pun).

Our tricks allow to use the same system on a range of devices, with the user interface adopting to specialties of hardware it runs on, such as input, display, but also usage scenarios specific that device. Much like the Linux kernel, which “mostly figures out how to run properly in a device it’s booted on”, and which can be configured as small and as big as one wants, the user-interface uses “UI plugins” at different layers, and detects changes and adopts to the form factor. You use a media center “driver” if you want to use it on the TV in your living room, you use a tablet “driver” on your tablet on the go, you use desktop driver on the laptop, and you can switch the device’s UI when needed. Laptop or tablet + HDMI cable ~= media center, isn’t it?

Klipper manager showing the clipboard's content
Clipboard interaction

You see, many different construction sites. We’re working a lot on all these things and you should definitely consider joining. Nothing is set in stone yet, and you should consider the imagery functional mock-ups, rather than the final thing. It’s not perfect and lacking in all kinds of places, it even crashes in some and what is presented is just a snapshot of work in progress. Many details remain to be hashed out. Still, I’m running Plasma 2 about half of the time on my laptop now. It’s just about to be becoming usable and almost dogfoodable for more than just a very small handful of people with an elevated pain threshold and a debugger at hand.

“When?”, I hear you ask. We’re aiming at a stable, end-user ready release of the new Desktop shell in summer 2014, at the end of Q2. On of the next milestones will be a tech-preview, which is planned for mid-December, so just about a month away from today. From December, where we’ll reach the point of having the basic functionality in place, we’ll spend time on filling in the missing bits, making sure everything runs on Wayland, and on polishing and quality improvements. Integrating additional workspaces, such as Plasma Active and Plasma MediaCenter are also next year’s roadmap. These will become the tablet, resp. media center drivers.

Plasma Next: What’s changing?

In the past week, we hit something that really feels like a milestone in Plasma development. Plasma 2 has become somewhat usable, at least if your pain level is high enough. It occurred to me after I realized after a few hours of using it that the workspace shell running on my laptop was not actually the current stable release of Plasma, but the development version. Great thing, I thought, went ahead and fixed a sizing bug in the systemtray widget, then changed the default layout to include Kickoff, Taskmanager and Systemtray in the panel, as these elements are the most important ones to have in the panel — exposure even to just our development team surely won’t hurt. This experience also marks a point where we have to take a step back and look at our general direction. Sure, we could do a “minimal port” and just make everything build and work on top of Qt5.

I can hack on Plasma2 using Plasma2!
I can hack on Plasma2 using Plasma2!

One of the technologies we’ve been using more and more in the Plasma workspaces is QtQuick, a declarative language that allows you to very easily write stunning UIs, without the need to use C++ for these parts. Our experience is that it makes developing, improving and maintaining applications a lot easier, and generally leads to much nicer user interfaces. QtQuick, being a very young technology in Qt4, has matured since then, and received a major technology update in Qt5. It moved from a traditional painter-based mechanism to a scenegraph model, and much closer onto the graphics hardware. That means that we usually get much better performance out of it, and that it allows a whole bunch of neat tricks on top of that. In Qt 5.2 (which is the Qt release we’re basing our work on), it received another big upgrade. The scenegraph renderer has been replaced, with huge performance gain as the result. (Read Gunnar’s article about it, it’s really impressive!) QtQuick also received a new QML engine, which brings major improvements to its internal data handling, but also to important topics such as maintainability. The new v4 engine uses Qt types internally, so a lot less marshalling is needed between runtime objects, and some architectural barriers have also been removed. Lars has written an excellent article about the new QML engine.

So on a technological level, we have decided to not do this. We want a more modular software stack underneath, so we decided to rework the KDE Development Platform into something that is more useful in its pieces. The result of that (the process isn’t finished yet, but rapture lines are becoming very visible) is KDE Frameworks 5, a modular set of Qt-based libraries with well-defined dependencies which separately are all very useful to 3rd party developers, and combined give you all the functionality to build highly integrated complex applications on top. Plasma next builds on Frameworks 5. In the past 1.5 years, we have spent a lot of time on reworking the build system and removing interdependencies between various “sublibraries” that made up kdelibs. This has progressed really well, we are in fact able to build and use many of our libraries standalone already. We’re currently restructuring the last libraries to accommodate a split, and will then “physically” split the libs into separate repositories. In order to not make the effort to build a KDE application or workspace explode, we have developed tooling that can build sets of modules for you. You get to choose the granularity we work with. In order to make it easier for third parties to find and use our libraries, we have set up, which has information about these (and other) libraries. This is very much work in progress, but it does already give a good picture of what’s to come.

For the user, we want to keep this whole process as smooth as possible. Porting applications to Frameworks 5 is rather easy, as regarding kdelibs, it mostly involves changes to the build system, some mild Qt5 porting, and only a few API changes. It is nowhere nearly as disruptive as the move from KDE3 to KDE4 (yes, our software was still called KDE${N} back then!).
In Plasma, it’s a little more complicated, as much more changed under the hood (a completely new way to get graphics onto the screen, deprecation of larger parts of our API, more device-independence reflected in our architecture). Our goal for the first release is to not introduce functional regressions however. We want to keep the basic usecases of a Desktop fully working, preferably noticeably improved. In the past years, we have already moved a lot of the individual components (such as the task manager, widgets for battery, network management, etc.) that make up our workspace to QML, this pays off now as those things are rather easy to port, and give a very mature impression right off the bat. We do realize that we have some cleaning up to do, and now is a good time to do this. We want to introduce a greater degree of consistency across the workspace experience. Technically, this can be achieved by more and smarter sharing of code, so common UI patterns become more, well, common. Plasma’s design language will be more pronounced, and at the same time, easier to change to your liking. More on that in another article, however.

As it currently looks like, we will release a first technology preview of both, Frameworks 5 libraries and Plasma Next in December. This won’t be a complete thing by any means, but a way to check on and gauge progress. At the same time, you’ll get to have a good look at Plasma Next, which, while building on the new technology stack, will resemble our current offering quite a bit still. It is much more a technology preview, than a user experience preview. So don’t judge too early, rather, get your hacking shoes on and join the fun. :)

What’s going on in Plasma Workspaces 2?

While moving its codebase to Qt5, the KDE Development Platform is undergoing a number of changes that lead to a more modular codebase (called KDE Framework 5) on top of a hardware-accelerated graphics stack. In this post, you’ll learn a bit about the status of Frameworks 5 and porting especially Plasma — that will be known as Plasma Workspaces 2, paying credit to its more convergent architecture.

Let’s start with something visual, before we get to the nitty-gritty:

Video showing a basic port of a Plasma Desktop Containment to Plasma 2

Frameworks 5

A whole bunch of libraries can now be built, installed and packaged separately. Those include (in tier1) Solid, Threadweaver, kdecore, karchive, kwindowsystem, and more, and in tier2 kauth and kconfig. Plasma has already moved into its own repository, and can of course also be built separately.

Kevin has been plugging away at removing problematic interdependencies between those libs, and recently could ditch (i.e. move to kde4support) a few classes that make it easier to just use Qt machinery (QApplication & friends) to bring up “KDE applications”. KAction has gone, KAboutData, so KDE Applications are now less “special” in the Qt world — a good thing for portability.
Splitting and untangling kdeui from kdelibs proves to be a bit more work- intensive than initially hoped. Fracture lines are becoming visible. The problem here is that this task is holding up the parallelization of development, so this has a high priority right now.

We’re also using a continuous integration system now to keep us on our toes with respect to “buildability” (which can be a bit daunting with so heavily shifting ground in kdelibs, this will calm down at some point though).

Video showing a Plasma 2 OpenGL shader demo widget

Plasma & KWin

Good progress, especially in the last month, in three areas:

API reviews: we’ve been doing weekly sessions for libplasma2 API reviews, where we’re going through the entire API and think about improvements for the Plasma 2, post-graphicsview world. As a result, libplasma2 has shrunk to about 1/3 in (compiled) size in its current state. We don’t expect it to grow much, since, in the scenegraph world, it plays another role than previously (although developers used to QML won’t really notice). (Join in the Hangout, if you like, we usually start on Monday morning around 10.00 UTC, just pop up in the #plasma channel and ask Marco to invite you). Our mutual status updates and Cool New Development is recorded and made available on Youtube for interested people, Last Monday’s session can be found here, but today we skipped it — you get this more detailed blog post in return. :)

Imports: Basically our QML runtime, it consists of Plasma Components, extras, bindings for things like dialog, framesvg and dataengines, drag and drop, krunner models, and a bunch of other stuff. I’m working on this right now, and have about 95% of the imports originating from kde-runtime working in Plasma2. We’ll be able to offer almost the same API to Plasma2 QML users, as in Plasma1, so porting of your QML code will be very easy.

Shell: In Plasma2, instead of having specific plasma-desktop, plasma-netbook, plasma-device shells, we will use one “generic” shell that loads containments (which then load applets), wallpaper, toolbox, etc. The shell can dynamically replace these components (change wallpaper, for example).

A few things are new here: in Plasma2, plasmoids provide their config ui via QML files, that are part of the package. That solves the problem that we could not really influence the behaviour of the configuration UIs from QML in Plasma1. It will also allow to transparantly switch between instant apply and “OK/Apply/Cancel” buttons, depending on what fits the usecase. Marco is on this.

Martin has been pushing the removal of the direct X dependency further through porting to XCB. He’s also recently started on a Qt5 port. One problem with KWin is that Martin needs a bunch of changes to have QtQuick and KWin run in the same process, that means making sure that KWin and Plasma (or QtQuick2 really) properly share and interact in the same OpenGL context. There’s a chicken-and-egg situation for kwin, since it needs to load for example window decorations and task switchers (both from QML) to be useful, but it can’t right now. The X11-based windecos won’t make it into Plasma2, so we’d rather avoid porting them just for the time being. Martin is on that though, and he earns our gratitude for going through this painful period in the porting procedure.

Desktop Containment moving to Plasma Quick

As many other components of the Plasma Workspaces, Plasma Desktop’s default Containment is being ported to QML. A technology preview of the containment is being demoed and can be tested by a wider audience now. While the port is mainly replicating the current desktop containment in QML, its interaction scheme to position and manipulate widgets on the desktop has been improved.

First of all, a note: The code presented in this article is not part of the upcoming Plasma Desktop 4.10. It can easily be installed on top of it, it might see inclusion in the summer 2013 release, however

In our Roadmap, you learn that KDE is currently porting many aspects of its workspaces to QML, with the goal to create a more modern user experience on top of state-of-the-art technologies such as Qt5, OpenGL scenegraph and Wayland. The move to QML is a gradual process, made possible by the componentized architecture of Plasma. Widgets and other components that make up the workspace are replaced with QML ports one by one. The premise is to not introduce regressions by shipping each component “when it’s ready”. Ultimately, we need a complete set of QML components to run the whole desktop (and at some point also apps) directly on top of the graphics hardware, leading to higher graphics performance and more available resources on the CPU.
One of the important pieces is the Desktop containment. This is the component in Plasma that is responsible for managing and laying out widgets on the desktop and creating the toolbox (which makes some “workspace actions” available to the user. In general, a “Containment” is an area on the screen (a panel, the desktop background, the dashboard, …), and it takes care of managing widgets, their position and sizing within. It also offers access to action specific to widgets, or the containment or workspace.
The currently shipped (also in 4.10) default Desktop containment is written in C++, using QGraphicsWidgets and offers free placing of widgets on the desktop, with a bit of edge and overlap detection and repositioning poured in.

Demo movie of the new QML Desktop containment

User interaction improvements

Most of the new containment is exactly the same as in the current default — this is done by design, we do not want to introduce radical changes to the workspace (and the users’ workflows), but rather improve gradually and in an iterative process. There are two areas (which in fact are closely related) where we did change a few things: positioning/sizing and visual cleanliness. These are expressed in two changes: integration of applet handle and positioning aids.
In order to reduce visual clutter, we integrated the applet handle into the applet’s background frame. Previously, it would be its own frame, and shift out as separate element from under the widget. Merging handle and background frame reduces the number of distinct elements on the screen and allows less intrusive transitions when the widget handle becomes visible.
The second important change is that we now provide helpers when the user moves and resizes a widget. When moving, we show a halo at the position the applet will snap to when dragged. This makes widget placement more predictable and allows the user to get it right in one go. We also align the widgets to an invisible grid, so applets automatically end up being aligned pixel-perfectly with each other, which leads to a more ergonomic workflow, cleaner appearance of the workspace, and again to less visual clutter.

Platform improvements: Bindings and Toolbox

An important aspect of the work on the QML containment, was to improve the bindings which load declarative code (QML) into Plasma shells, these improvements are included in Plasma 4.10, due to be released in early february. This includes the necessary platform features to allow running fully-featured QML containments, something which we have done in Plasma Active for a while, but within a more confined context.

As a result of this work, Plasma can now also load toolboxes written in QML. The Plasma Toolbox is the little widget with the Plasma icon you can see on top of many containments, and which gives access to actions such as add widgets, settings, shortcuts, etc.. The toolbox used with the containment shown is a 1:1 port of its counterpart in the current default (C++) toolbox. The name of the toolbox package is currently hard-coded in the bindings (it loads it from the org.kde.toolbox package and silently falls back to the C++ implementation if that isn’t found — a 4.10 feature), but it also opens up this part of the workspace to QtQuick goodness. The toolbox is basically a translucent layer on top of the desktop, so much freedom is given to other implementations).

A template and a bridge

The code is not only there to replace the current containment, it also serves as a template for new developments. With the new containment bindings in place, it is now very easy to create your own containment, modify someone else’s and publish them to share them. The containment shown is just one example for what we can do with the QML integration features in Plasma. As Plasmoid packages are architecture independent, this of course works across devices and different workspaces.

The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors. Some of its code has been introduced in Plasma Active, and is now available in a more generic fashion also for Plasma Desktop (and Netbook). This brings us closer to one of our goals, having only one shell that dynamically loads a suitable interface (Containment, Widgets) for a given formfactor, use case, output device, etc.

Give it a spin

If you’re interested and would like to try it (we appreciate feedback, it’s especially valuable in this phase!), there are two ways to get this containment. The minimal requirement for it is Plasma 4.10-beta1.
If you’re using git, you will find the code in the branch called “plasma/sebas/desktop-qml”, just check it out and build it, install it, run kbuildsycoca4, and you’re done.
If you are using the packages, you can easily install the following two Plasmoid packages to your system:

If your system is using a version prior to KDE SC 4.10-beta1, the packages will install, but not work.

The following commands install the necessary Plasma packages into your home KDE install directory.

# create the package directory and go there
mkdir -p `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
cd `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
# unpack the plasmoid package
unzip ~/path/to/toolbox-git28012013.plasmoid
# check if it's installed correctly, 
# this should list metadata.desktop and contents/
ls -la `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox

[Edit: changes –localprefix to –prefix, as we’ve found a bug in –localprefix code.]
Then install the desktop containment package (If you’re updating the containment at a later stage, use plasmapkg -u.):

plasmapkg -i desktop-git28012013.plasmoid

You can now choose the new containment from Layout dropdown in the Desktop Settings, pick “Default Desktop (QML)” there.

I would like to thank Blue Systems for supporting my work on the above topics.

An ownCloud Client for KDE Plasma

Preface — The Synchronization Problem

ownCloud offers a Free software solution to synchronize your files across different devices. I’ve been working on a KDE Plasma client for this server technology. In this article, after giving a bit of background of the problem, I explain the design concepts behind the new ownCloud Plasma client and demonstrate how it works and integrates with different Plasma workspaces.

I’ve been looking for a good solution to synchronize my data across different devices I use forever. The need arose when I got my first laptop (next to my desktop machine): I wanted to be able to work on my projects on both devices without having to manually copy files between the machines. It turned out to be actually quite a hard problem: Sure, you can work on your stuff on a remote machine, and thereby always work on one version of a certain file. But what happens when you’re offline? I needed files to be synched, and was looking for a more or less automated that worked both offline and online. I took a look at the Coda Filesystem, which seemed to solve this problem well, for others at least. It was a bit of a pain to set up (and understand how it exactly worked), but after a bit of fiddling, I had copies of my stuff on different machines. It seemed to work initially, but later turned out to be a little bit too brittle for my use cases (I don’t quite recall the details, but eventually, I gave up on it because it meant more or less constant maintenance, and still it wasn’t quite as bullet proof as I had hoped it would be.
At university (where I both studied and worked for quite a while), we often used SVN for collaboration. There’s value to using the same tools in more places, so I put all my files into an SVN repository and used that for synchronization. Eventually, I moved these private data repositories to Git, as I grew more comfortable with this tool and it allowed useful things like offline commits and synching between “client devices”, not just between client and server. Not an automatic process, also not the most beautiful solution to the problem as it wasn’t quite as automated as I’d have liked it to be. Also, as computing became more portable, I needed something that would also blend in well with with all the devices that produce, collect and are supposed to carry my data.

Enter ownCloud

ownCloud widget sitting in the panelMy problem is of course not unique to me: File synchronization plays an ever more important role, Internet connections become faster and more ubiquitous, the device spectrum expands. Where people have been using one computer for all their electronic communication and computing needs, it now spreads across different devices, desktops, laptops, tablets, smartphones, media centers, and likely many more form factors we can only dream of today (or maybe not even that!). Devices jumping between network infrastructures doesn’t make it easier, and the most flexible solution seems to a central server – multiple clients model. ownCloud offers exactly that, it’s Free software (licensed under the AGPL), is easy to setup and runs on bog standard LAMP setups. Its server side performs well enough to be able to run it on even woefully underpowered hardware such as NAS systems or other embedded devices. More importantly, it gives you full control over your data, which is nice and important for private use, and often a hard requirement for institutional use cases, such as document management and sharing in a company.

I’ve been keeping a keen eye on ownCloud for a while, and, somewhere in its 3.x cycle, I decided to set up owncloud on my private server and started experimenting with it. Installation was quite easy, and the desktop client Mirall seemed to work well initially.

My own Plasma Cloud

After using it for a bit, I ran into a few problems, some of them simple bugs (most of which seem to have been fixed), some UI issues, and also a lack of integration. Mirall’s UI is a “standard systray application”, it always sits there in the system tray, shows its status and allows you to set up directories (“Folders”) for synchronization with the ownCloud server. Mirall’s UI, however bears all the traits of a “traditional” desktop application: It’s unsuitable for touch interfaces, abuses the system tray as task switcher and overall not quite up to modern UI standards we use in Plasma. As Mirall is geared towards portability (it’s the official desktop client for Linux, Mac and Windows), it lacked good integration into Plasma — the usual lowest common denominator problem). What crossed my mind was redoing the UI using Plasma technologies, thereby updating its Look & Feel and at the same time making it suitable for touch interfaces, such as Plasma Active, KDE’s device-independent user experience.

Collaboration for a new design

ownCloud settings moduleAt Akademy this summer, Klaas (who works for ownCloud Inc. on Mirall), me and a few others sat down to talk about better integration of ownCloud into the Plasma Desktop. ownCloud being a project very close to KDE (it sprang from the KDE community, had developer meetings and travel expenses funded by the KDE e.V., partly runs on KDE infrastructure, and some KDE developers are also working on ownCloud), that seemed like the right thing to do. In a BoF session, we sat down, talked about what we’d like to see improved and started designing a KDE Plasma client for ownCloud, based on the Mirall code base. What we came up with can be explained as follows:

  • The UI bits and synchronization code from Mirall will be split, and the sync mechanism will be split out into a shared library
  • The shared library is used by a daemon, which on the one hand takes care of keeping files in sync, and one other side exports a DBus control interface
  • A Plasma widget shows synchronization status and allows basic control like disabling syncing
  • A System Settings module allows to setup synchronization of the ownCloud client
  • A Plasma Active Settings module allows to set up the ownCloud client from your mobile device

With this solution, we can cover a range of devices, providing a consistent operation and Look & Feel and share code to keep development costs down. Doing the UI components in Plasma Quick (Plasma and KDE technologies + Qt Quick’s QML), we can the maximum amount of code across different devices, and create a modern UI that adapts itself to form factors and input methods (meaning it will work well on both, mouse/keyboard driven target devices, as well as touch screens). As a bonus, doing the UI in Plasma Quick means it’s easy to hack, easy to contribute for others.


Having a clear idea how we want to go forward, and an agreed-upon plan de campagne, we sat down to implement all the designed goodness. Klaas was quick to split out the synchronization mechanism from ownCloud into its own shared library, and I started working on the bits needed for the Plasma client: The sync daemon, the UI components used by the configuration modules and the Plasmoid, and of course those UIs themselves. Progress has been quite good, I quickly got the synchronization daemon up and running, and could move to implementing the various pieces of user interface needed.In the process, I’ve created a bunch of patches to Mirall, some of them merged, others still in the review queue. They’re mostly fairly trivial, splitting out a bit of QWidget-based remainders from the daemon (and thereby cutting down its size considerably), and extending the API (in a backwards compatible way) to allow better status display and control from the user interface “satellites”.

Current Status

File synchronization is of course the main feature here. This already works reasonably well, including setting up of server and folders. The UI has a few problems here and there, but the important pieces are in place. The plan is to ship a first stable version with the release of Plasma Active 4 in March, which will also mark the availability of the desktop client.

How to make it all happen faster?

I’d be most grateful if distro packagers would pick the new ownCloud Plasma client up at this point, package it and allow users to test it (with the necessary warning signs of eating pet and firstborns attached, of course). There’s still quite a lot of work to do, but the basics work, and getting feedback helps me prioritize what to work on first to get this into the hands of our dear users.
Of course if you’re interested in contributing to the client directly (in the form of code, UI design, bug fixing, polishing, performance, etc, you’re also most welcome to do so. The code is currently hosted on Github (like other ownCloud subprojects, if you prefer a Free software solution, we can clone it on KDE infrastructure as well, and sync our upstream changes as needed to Github). In order to build it, check out and build the “plasmaclient” branch. This will install the various components to your system. After running “kbuildsycoca4” (or relogging in), you can enable the Plasma widget through your notification area configuration.