PSA: Plasma Mobile forums have moved

For a short while, the Plasma Mobile forums were hosted outside of the official KDE Forums. In our quest to put everything under KDE governance, we have now moved the Plasma Mobile forums under KDE’s forums as well. Enjoy the new Plasma Mobile forums.

As a few users had already registered on the “old” forums, this means a smallish interruption as the threads could not be quickly moved to the new forums. We’re sorry for that inconvenience and would like to ask everyone to move to the new forums.

Thanks for your patience and sorry again for the hassle involved with that.

Embracing Mobile

At Blue Systems, we have been working on making Plasma shine for a while now. We’ve contributed much to the KDE Frameworks 5 and Plasma 5 projects, and helping with the transition to Qt5. Much of this work has been involving porting, stabilizing and improving existing code. With the new architecture in place, we’ve also worked on new topics, such as Plasma on non-desktop (and non-laptop) devices.

Plasma Mobile on an LG Nexus 5
Plasma Mobile on an LG Nexus 5

This work is coming to fruition now, and we feel that it has reached a point where we want to present it to a more general public. Today we unveil the Plasma Mobile project. Its aim is to offer a Free (as in Freedom), user-friendly, privacy-enabling and customizable platform for mobile devices. Plasma Mobile runs on top of Linux, uses Wayland for rendering graphics and offers a device-specific user interface using the KDE Frameworks and Plasma library and tooling. Plasma Mobile is under development, and not usable by end users now. Missing functionality and stability problems are normal in this phase of development and will be ironed out. Plasma Mobile provides basic functionality and an opportunity for developers to jump in now and shape the mobile platform, and how we use our mobile devices.

As is necessary with development on mobile devices, we’ve not stopped at providing source code that “can be made to work”, rather we’re doing a reference implementation of Plasma Mobile that can be used by those who would like to build a product based on Plasma Mobile on their platform. The reference implementation is based on Kubuntu, which we chose because there is a lot of expertise in our team with Kubuntu, and at Blue Systems we already have continuous builds and package creation in place. Much of the last year was spent getting the hardware to work, and getting our code to boot on a phone. With pride, we’re now announcing the general availability of this project for public contribution. In order to make clear that this is not an in-house project, we have moved the project assets to KDE infrastructure and put under Free software licenses (GPL and LGPL according to KDE’s licensing policies). Plasma Mobile’s reference implementation runs on an LG Nexus 5 smartphone, using an Android kernel, Ubuntu user space and provides an integrated Plasma user interface on top of all that. We also have an x86 version, running on an ExoPC, which can be useful for testing.

Plasma Mobile uses the Wayland display protocol to render the user interface. KWin, Plasma’s window manager and compositor plays a central role. For apps that do not support Wayland, we provide X11 support through the XWayland compatibility layer.

Plasma Mobile is a truly converged user interface. More than 90% of its code is shared with the traditional desktop user interface. The mobile workspace is implemented in the form of a shell or workspace suitable for mobile phones. The shell provides an app launcher, a quick settings panel and a task switcher. Other functionality, such as a dialer, settings, etc. is implemented using specialized components that can be mixed and matched to create a specific user experience or to provide additional functionality — some of them already known from Plasma Desktop.

Architecture diagram of Plasma Mobile
Architecture diagram of Plasma Mobile

Plasma Mobile is developed in a public and open development process. Contributions are welcome and encouraged throughout the process. We do not want to create another walled garden, but an inclusive platform for creation of mobile device user experiences. We do not want to create releases behind closed doors and throw them over the wall once in a while, but create a leveled playing field for contributors to work together and share their work. Plasma Mobile’s code is available on git.kde.org, and its development is discussed on the plasma-devel mailinglist. In the course of Akademy, we have a number of sessions planned to flesh out more and more detailed plans for further development.

With the basic workspace and OS integration work done, we have laid a good base for further development, and for others to get their code to run on Plasma Mobile. More work which is already in our pipeline includes support for running Android applications, which potentially brings a great number of mature apps to Plasma Mobile, better integration with other Plasma Devices, such as your desktop or laptop through KDE Connect, an improved SDK making it very easy to get a full-fledged development environment set up in minutes, and of course more applications.

thoughts on being merciful binary gods

“Since when has the world of computer software design been about what people want? This is a simple question of evolution. The day is quickly coming when every knee will bow down to a silicon fist, and you will all beg your binary gods for mercy.” Bill Gates

For the sake of the users, let’s assume Bill was either wrong or (||) sarcastic.

Let’s say that we want to deliver Freedom and privacy to the users and that we want to be more effective at that. We plan to do that through quality software products and communication — that’s how we reach new users and keep them loving our software.

We can’t get away with half-assed software that more or less always shows clear signs of “in progress”, we need to think our software through from a users point of view and then build the software accordingly. We need to present our work at eye-level with commercial software vendors, it needs to be clear that we’re producing software fully reliable on a professional level. Our planning, implementation, quality and deployment processes need to be geared towards this same goal.

We need processes that allow us to deliver fixes to users within days, if not hours. Currently in most end-user scenario, it often takes months and perhaps even a dist-upgrade for a fix for a functional problem with our software.

The fun of all this lies in a more rewarding experience of making successful software, and learning to work together across the whole stack (including communication) to work together on this goal.

So, with these objectives in mind, where do we go from here? The answer is of course that we’re already underway, not at a very fast speed, but many of us have good understanding of many of the above structural goals and found solutions that work well.

Take tighter and more complete quality control, being at the heart of the implementation, as an example. We have adopted better review processes, more unit testing, more real-world testing and better feedback cycles with the community, especially the KDE Frameworks and Plasma stacks are well maintained and stabilized at high speeds. We can clearly say that the Frameworks idea worked very well technically but also from an organizational point of view, we have spread the maintainership over many more shoulders, and have been able to vastly simplify the deployment model (away from x.y.z releases). This works out because we test especially the Frameworks automatically and rather thoroughly through our CI systems. Within one year of Frameworks 5, our core software layer has settled into a nice pace of stable incremental development.

On the user interaction side, the past years have accompanied our interaction designers with visual artists. This is clearly visible when comparing Plasma 4 to Plasma 5. We have help from a very active group of visual designers now for about one and a half year, but have also adopted stricter visual guidelines in our development process and forward-thinking UI and user interaction design. These improvements in our processes have not just popped up, they are the result of a cultural shift towards opening the KDE also to non-coding contributors, and creating an atmosphere where designers feel welcome and where they can work productively in tandem with developers on a common goal. Again, this shows in many big and small usability, workflow and consistency improvements all over our software.

To strengthen the above processes and plug the missing holes in the big picture to make great products, we have to ask ourselves the right questions and then come up with solutions. Many of them will not be rocket science, some may take a lot of effort by many. This should not hold us back, as a commonly shared direction and goal is needed anyway, regardless of ability to move. We need to be more flexible, and we need to be able to move swiftly on different fronts. Long-standing communities such as KDE can sometimes feel to have the momentum of an ocean liner, which may be comfortable but takes ages to move, while it really should have the velocity, speed and navigational capabilities of a zodiak.

By design, Free Culture communities such as ours can operate more efficiently (through sharing and common ownership) than commercial players (who are restricted, but also boosted by market demands), so in principle, we should be able to offer competitive solutions promoting Freedom and privacy.

Our users need merciful binary source code gods and deserve top-notch silicon fists.

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:

[Desktop]
Name=Email
Comment=Fat-client for your email
Exec=kmail
X-KDE-FormFactors=desktop

For the touch-friendly version:

[Desktop]
Name=Email
Comment=Touch-friendly email client
Exec=kmail-touch
X-KDE-FormFactors=handset,tablet

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")) {
        shownAppsList.append(app);
    }
}

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.

Moreover…

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.