For more than 20 years, I’ve been part of the KDE community, one of the largest and most impactful Free and Open Source software community world-wide. Yesterday, KDE turned 30 and this went accompanied with the premiere of the KDE documentary. As former release manager, Plasma core developer and KDE e.V. board member, I’ve also been interviewed. A fairly prominent NPC role went out to Skippie, my cat.
Lately, I have been back into Free Software development, working on two apps that are closely related to hobbies of mine. Watch this space for news! Something nice has been cooking!
Recently, I’ve worked on making certain “less obvious” system settings more accessible for Plasma Mobile users. The modules I’ve worked on fall just outside the typical mobile phone use-case, but can be important to users of other types of devices. Specifically, users that plug in or connect a keyboard once in a while and need to change its layout or language, or devices that are connected using an ethernet cable, as often is the case with embedded industrial devices.
Mobile keyboard settings
Wired network settings
These two settings module offer a subset of their “desktop companions'” settings and cater to simpler use-cases while sporting a leaner and more focused user interface. Most of the business logic and the more complex UI components are also shared with the desktop versions.
Reviewers needed!
The merge requests for both are currently under review and I’d appreciate if people could help ironing out issues so we can go ahead and merge the code:
After I took a longer break from KDE development, I’ve been back in action for a few months now. It’s really nice to be back among friends, hacking on what I like most: Plasma. My focus has been on Plasma Mobile with some work naturally bleeding over into other areas.
Plasma on more Devices
I’d like to share some bits and pieces that I’ve worked on in the past months. Most of my efforts have revolved around making Plasma Mobile suitable for a wider range of devices and use-cases. The purpose of this work is that I want to make Plasma Mobile a more viable base for all kinds of products, not just mobile phones. We have a really mature software stack and great tools and applications which make it relatively easy for companies to create amazing products without having to hire large teams and many years to get the product ready for their market. This is I think a very interesting and worthwhile niche for Plasma to get into and I’m sure that Valve is not the only company that understands this.
Convergence Improvements
Convergence, or rather being able to support and switch between formfactors and usage patterns has always been a pet-peeve of mine and still is. One area was improving using the available screen real estate use landscape displays (Plasma Mobile has quite naturally been rather “portrait-focused”, though a few smaller patches go a long way.)
Configurable number of columns in the Quicksettings drawer
I also improve usability with different pixel densities in the mobile shell by making the size of the top panel configurable. Also, when plugging in a second monitor, Plasma Mobile now switches from “all apps are maximized” to normal window management. (I’m currently working on KWin supporting more fine-grained window management. Currently, we just maximize all windows which has problems especially with modal dialogs.)
One changeset I worked on earlier this year makes it possible to ship multiple user interfaces for settings modules (“kcms”). An example is the “remote desktop” kcm which now shows a mobile-focused UI in Plasma Mobile. What happens here is that we load a main_phone.qml file in Plasma Mobile (where “phone” is picked from a list of form factors set in the environment of the session, so basically the “main” QML file gets picked based on the device. This mechanism allows us to share components quite easily, reducing the delta between different device UIs.
Mobile and Desktop RDP settings
This actually builds on top of work that I’ve done ten years ago which added support for form factors to our plugin metadata system. I’ve also made the “Display & Monitor” kcm usable on mobile, this is a pretty important thing to have working when you want to be able to plug in an external monitor into your device. I have a mobile version of the keyboard KCM in the pipeline, too, but this will need a bit more work before it’s ready for prime-time.
More Features
There’s a new page in the mobile Wi-fi settings module, showing connection details and tranfer speeds. The code for this was amazingly simple since I could lift most of the functionality from the desktop panel widget. A shared code-base across devices really speeds up development.
Connection details for the mobile wifi settings
Adding useful features here and there, such as having the list of available bluetooth devices now filtered by default and only showing devices which actually make sense to pair (with an option to “Show all devices” in good Plasma manner). This feature isn’t mobile-specific, so desktop and laptop users will benefit.
Welcome to Okular Mobile
Not all my work goes into infrastructural and “shell” bits. The mobile okular version has now kind of caught up with the desktop version since it got a nice welcome screen when opened. This allows the user to easily open a document either from the “Documents” directory on disk (this is actually configurable) or one of the recent files viewed.
Okular Mobile Welcome Screen
Going to Akademy ’25
After having missed our yearly world conference for a number of years, this year I will be at Akademy again. I’m really looking forward to seeing everybody in person again!
Lots of KDE hacking these days, and that comes with compiling large amounts of code. Right now, I am installing, well building from source Plasma Mobile on an “old” laptop so I can test some patches natively on a touchscreen device. The machine has just two cores (hyperthreaded), so builds take rather long, especially if you build Qt and all that 80+ packages that are needed for a fully working Plasma system. One of the tools that do an incredible job while being super flexible to use is icecream. Icecream (or “icecc“) allows you to distribute your build over multiple machines, it basically ships compile-jobs with all that’s needed to other machines on a local network, meaning you can parallelize your builds.
Icecream has this nice visualization tool, called icecream-monitor which you can stare at while your builds are running (in case you don’t have anyone handy for a sword-fight). In the screenshot you can see manta, the underpowered laptop doing a 32 parallel job build over the network. miro is my heavy workstation, 8 cores and 128GB of RAM, it duely gets the bulk of the work assigned, frame is my (Framework) laptop, which is also quite beefy, gets something to do too, but not taxed as heavily as that build monster in my basement office. Icecream can be used with most environments that have you run your compiler locally. Different distros are no problem! Just a matching CPU architecture is needed. Icecream does its job by providing its own g++ and gcc binaries, which will relay the build jobs transparently to either your local machine or across the network. So you basically install it, adjust your PATH variable to make sure icecc’s g++ is found before your system’s compiler and start your build. Other machines you want to join in for the fun just need to run icecc-scheduler and they will be automatically discovered as build slaves on your network. If you want to further speed up builds, it works with ccache as well.
Please note that you only want to do this in a trusted environment, we’re shipping executables around the network without authorization!
This morning, while browsing the web, I wanted to listen to a Podcast from my laptop, and thought “Hey, can I stream this to our stereo?”. As it turns out, that’s rather easy to achieve, so I thought I’d share it here. The media devices in our home are connected using Chromecasts, which are small dongles that allow playing media on them, meaning you can play for example a video from your phone on the projector in the living room: very convenient.
I didn’t know if that was easily achievable with audio from my Plasma/Linux laptop and a quick search turned up “pulseaudio-dlna” which adds Chromecast devices on the local networks as output devices.
On my KDE Neon laptop, it’s as easy as installing pulseaudio-dlna from the standard repositories and then starting “pulseaudio-dlna” from the commandline. Then, I can pick an output device from the panel popup and the audio stream changed to my stereo.
For my hacking, I love to use the KDevelop IDE. Once in a while, I find myself working on a project that has different indentation styles depending on the filetype — in this case, C++ files, Makefiles, etc. use tabs, JavaScript and HTML files use 2 spaces. I haven’t found this to be straight-forward from KDevelop’s configuration dialog (though I just learnt that it does seem to be possible). I did find myself having to fix indentation before committing (annoying!) and even having to fix up the indentation of code committed by myself (embarrassing!). As that’s both stupid and repetitive work, it’s something I wanted to avoid. Here’s how it’s done using EditorConfig files:
put a file called .editorconfig in the project’s root directory
specify a default style and then a specialization for certain filetypes
restart KDevelop
Here’s what my .editorconfig file looks like:
# EditorConfig is awesome: https://EditorConfig.org
# for the top-most EditorConfig file, set...
# root = true
# In general, tabs shown 2 spaces wide
[*]
indent_style = tab
indent_size = 2
# Matches multiple files with brace expansion notation
[*.{js,html}]
indent_style = space
indent_size = 2
This does the job nicely and has the following advantages:
It doesn’t affect my other projects, so I don’t have to run around in the configuration to switch when task-switching. (Editorconfigs cascade, so will be looked up up in the filesystem tree for fallback styles.
It works across different editors supporting the editorconfig standards, so not just KWrite, Kate, KDevelop, but also for entirely different products.
It allows me to spend less time on formalities and more time on actual coding (or diving).
Plasma’s new screen layout selection dialogThis week, Dan Vratil and me have merged a new feature in KScreen, Plasma’s screen configuration tool. Up until now, when plugging in a new display (a monitor, beamer or TV, for example), Plasma would automatically extend the desktop area to include this screen. In many cases, this is expected behavior, but it’s not necessarily clear to the user what just happened. Perhaps the user would rather want the new screen on the other side of the current, clone the existing screen, switch over to it or perhaps not use it at all at this point.
The new behavior is to now pop up a selection on-screen display (OSD) on the primary screen or laptop panel allowing the user to pick the new configuration and thereby make it clear what’s happening. When the same display hardware is plugged in again at a later point, this configuration is remembered and applied again (no OSD is shown in that case).
Another change-set which we’re about to merge is to pop up the same selection dialog when the user presses the display button which can be found on many laptops. This has been nagging me for quite a while since the display button switched screen configuration but provided very little in the way of visual feedback to the user what’s happening, so it wasn’t very user-friendly. This new feature will be part of Plasma 5.13 to be released in June 2018.
In the past weeks, we have noticed an increased interest in Plasma Mobile from different sides. Slowly, but surely, hardware vendors have discovered that Plasma Mobile is an entirely different software platform to build products on top of. For people or companies who want to work or invest into Plasma Mobile, it’s always useful to know where upstream is heading, so let me give an overview of what our plans are, what areas of work we’re planning to tackle in the coming months and years, where our focus will be and how it will shift. Let’s talk about Plasma Mobile’s roadmap.
Our development strategy is to build a basic system and platform around our core values first and then extend this. Having a stable base of essentials allows us to focus on an achievable subset first and then extend functionality for more and more possible target groups. It avoids pie-in-the-sky system engineering something that will never be useful and designed for a unicorn market that never existed. Get the basics right first, then take it to the next levels. These levels are:
Prototype (already finished)
Feature Phone
Basic Smartphone
Featured Smartphone
Plasma Mobile Roadmap
Let’s look at these steps in detail.
Prototype and Product Vision
The first public release of Plasma Mobile was this prototype. It showed a very basic and incomplete-for-daily-use system on actual, modern smartphone hardware. You could make phone calls, start and manage apps, and manipulate some basic system functionality. It showed a smartphone system based on Plasma could be done, and more importantly, it taught us a lot about where we want to take things on a technical level.
Along with the prototype, we developed a product vision for Plasma Mobile, a direction where we want to take it (emphasis added by yours truly):
“Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.”
Feature Phone
The feature phone milestone is what we’re working on right now. This involves taking the prototype and fixing all the basic things to turn it into something usable. Usable doesn’t mean “usable for everyone”, but it should at least be workable for a subset of people that only rely on basic features — “simple” things.
Core features should work flawlessly once this milestone is achieved. With core features, we’re thinking along the lines of making phone calls, using the address book, manage hardware functions such as network connectivity, volume, screen, time, language, etc.. Aside from these very core things for a phone, we want to provide decent integration with a webbrowser (or provide our own), app store integration likely using store.kde.org, so you can get apps on and off the device, taking photos, recording videos and watching these media. Finally, we want to settle for an SDK which allows third party developers to build apps to run on Plasma Mobile devices.
Getting this to work is no small feat, but it allows us to receive real-world feedback and provide a stable base for third-party products. It makes Plasma Mobile a viable target for future product development.
Basic Smartphone
The basic smartphone extends the feature set of Plasma Mobile to a wider group of target users. The plan is to add personal information management features, such as reading and sending emails, calendaring and reminders. We also want to add file management capabilities in this milestone, because we think that the user should be able to deal with the data in her phone in the most transparant way, and file management is something that allows users to look into the fabric of their data, and that of the phone itself. Another big topic for the Basic Smartphone milestone is extending the app ecosystem through third-party and original applications to allow the user to do more things with the device.
Featured Smartphone
For the featured smartphone, we want to add more system-level integration features such as deeply integrated private cloud storage and have grown our own ecosystem with more apps and of course games. An often requested feature is support for Android apps. Supporting Android apps could give Plasma Mobile a huge boost in terms of possible target groups, since it allows users to switch away from Android more easily, even when they are requiring a few apps and can’t really live without these. Being able to run Android apps on a Plasma Mobile device can ease the transition considerably and it allows us to capture potential target user groups that rely on proprietary services which Plasma Mobile, at first, cannot serve simply because as a smaller player, it’s not an attractive enough platform to have the likes of WhatsApp develop native clients for.
When it’s ready!?
On purpose, we did not add a specific timeline to this roadmap for two reasons: First, Plasma Mobile is a participative project, if you want to see something done, get involved. We’re not running the show all by ourselves. We want to create an open eco system where people who do the work decide on its direction. This means if you get involved, you can help us shape the future of mobile computing instead of being just a code monkey that does what someone else has decided. Secondly, we don’t want to deliver half-assed software just because we set a timeline. We want to create quality software to build products upon. If you or your company want to ship on a specific date, work with us and we’ll plan together. We won’t make promises when something is ready beforehand, but as an upstream project, we want to ship “when it’s ready”. This “when” depends on all our input and hard work. So don’t sit in your armchairs and wait for someone else to do the heavy lifting, but let’s get cracking!
Librem 5 Plasma MobileIn the past days, the campaign to crowd-fund a privacy-focused smartphone built on top of Free software and in collaboration with its community reached its funding goal of 1.5 million US dollars. While many people doubted that the crowdfunding campaign would succeed, it is actually hardly surprising if we look what the librem 5 promises to bring to the table.
1. Unique Privacy Features: Kill-switches and auditable code
Neither Apple nor Android have convincing stories when it comes to privacy. Ultimately, they’re both under the thumbs of a restrictive government, which, to put it mildly doesn’t give a shit about privacy and has created the most intrusive global spying system in the history of mankind. Thanks to the U.S., we now live in the dystopian future of Orwell’s 1984. It’s time to put an end to this with hardware kill switches that cut off power to the radio, microphone and camera, so phones can’t be hacked into anymore to listen in on your conversations, take photos you never know were taken and send them to people you definitely would never voluntarily share them with. All that comes with auditable code, which is something that we as citizens should demand from our government. With a product on the market supplying these features, it becomes very hard for your government to argue that they really need their staff to use iphones or Android devices. We can and we should demand this level of privacy from those who govern us and handle with our data. It’s a matter of trust. Companies will find this out first, since they’re driven by the same challenges but usually much quicker to adopt technology.
2. Hackable software means choice
The librem 5 will run a mostly standard Debian system with a kernel that you can actually upgrade. The system will be fully hackable, so it will be easy for others to create modified phone systems based on the librem. This is so far unparalleled and brings the freedom the Free software world has long waited for, it will enable friendly competition and collaboration. All this leads to choice for the users.
3. Support promise
Can a small company such as Purism actually guarantee support for a whole mobile software stack for years into the future? Perhaps. The point is, even in case they fail (and I don’t see why they would!), the device isn’t unsupported. With the librem, you’re not locked into a single vendor’s eco system, but you buy into the support from the whole Free software community. This means that there is a very credible support story, as device doesn’t have to come from a single vendor, and the workload is relatively limited in the first place. Debian (which is the base for PureOS) will be maintained anyway, and so will Plasma as tens of millions of users already rely on it. The relatively small part of the code that is unique to Plasma Mobile (and thus isn’t used on the desktop) is not that hard to maintain, so support is manageable, even for a small team of developers. (And if you’re not happy with it, and think it can be done better, you can even take part.)
4. It builds and enables a new ecosystem
The Free software community has long waited for this hackable device. Many developers just love to see a platform they can build software for that follows their goals, that allows development with a proven stack. Moreover, convergence allows users to blur the lines between their devices, and advancing that goal hasn’t been on the agenda with the current duopoly.
The librem 5 will put Matrix on the map as a serious contender for communication. Matrix has rallied quite a bit of momentum to bring more modern mobile-friendly communication, chat and voice to the Free software eco-system.
Overall, I expect the librem 5 to make Free software (not just open-source-licensed, but openly developed Free software) a serious player also on mobile devices. The Free software world needs such a device, and now is the time to create it. With this huge success comes the next big challenge, actually creating the device and software.
The unique selling points of the librem 5 definitely strike a chord with a number of target groups. If you’re doubtful that its first version can fully replace your current smart phone, that may be justified, but don’t forget that there’s a large number of people and organisations that can live with a more limited feature set just fine, given the huge advantages that private communication and knowing-what’s-going-on in your device brings with it.
The librem 5 really brings something very compelling to the table and those are the reasons why it got funded. It is going to be a viable alternative to Android and iOS devices that allows users to enjoy their digital life privately. To switch off tracking, and to sleep comfortably.
Are you convinced this is a good idea? Don’t hesitate to support the campaign and help us reach its stretch goals!
A Plasma Phone
In one of my latest blogs, I’ve explained what convergence is, how Plasma benefits from it, and why we consider it a goal for Plasma. This time around, I’ll explain the how, how it works across the stack and how we implemented it. Naturally, this article dives a lot deeper, technically, than my previous one.
Convergence plays a role at different levels of the whole software stack. In this, more technical article, I’ll look at different layers of the software stack, from boot/kernel and middleware to UI controls and overall layout and input methods. After reading this article, you’ll understand how Plasma allows to use the same software on a range of devices, which parts are different, and where code sharing makes sense, and thus happens. Keep in mind that Convergence, at least for Plasma, doesn’t mean that we ship a lowest-common denominator UI so it “kind of” runs on all things computer, but that it provides a toolbox to build customized UIs that allow taking advantage of specific characteristics of a given target device.
Lower Levels and Packaging
Plasma — same code, different devices
One aspect of convergence that is of course the deployment side. This doesn’t just include the kernel and bootloader, which needs to be compiled differently for ARM devices and for x86 devices. The rest of the stack is by now largely the same. We are now using the same set of packages and CI for both, mobile and desktop builds, in fact most packages are the same, and the difference between a device set up for mobile use cases and desktop is the selection of packages, and what gets started by default. Everything is integrated to a very large degree, lots of work is shared which means timely updates across the device spectrum we serve.
Controls
Plasma Mobile
When it comes to user interface controls, such as buttons, text fields, etc., convergence is mostly a solved problem. Touch input is possible, Qt nowadays even ships a virtual keyboard (which Plasma uses for example for password input in the lock-screen), and buttons react to touch events as well. QtQuick-based user interfaces often work quite well with both, keyboard/mouse and touch input, in fact touch is one of the design goals of QtQuick.
Not everything is perfect yet, however, especially text selection and keyboard control of QtQuick-based UIs often still requires custom-code, meaning it needs more development and maintainance time to get right. QWidget-based UIs are still a bit ahead of the game here, though often the benefits of also being able to deploy an app on touch devices (such as many Android devices out there!) make QtQuick an attractive technology to use. We see more and more QtQuick-based applications, as this technology matures also for desktop use-cases.
Widgets
Convergent Plasma Widgets
Plasma is made of widgets. Even in a standard Plasma desktop, everything is a widget: The menu in the bottom left is a widget, the task manager is, the system tray is a widget, and there are widgets inside the system tray for notifications, battery, sound, network, etc.. Plasma is widgets.
These widgets can be used on any device of course, but it doesn’t always make sense. Some of these widgets are very specific for desktops. The task-manager (that thing you use to switch windows, which is usually located in center of the bottom panel) doesn’t really make sense on a mobile device. For a mobile device, which needs larger areas to touch, something more aking to a full-screen window switcher is useful (and in fact what we use for Plasma Mobile). Other widgets, such as the network connections widget or battery and brightness widgets are perfectly suitable also for mobile devices. Plasma’s architecture allows us to re-use the components that need no or just little changes and use them across devices. That means we can concentrate on the missing bits for each device, and that in turn means we can deliver a feature-rich and consistent UI across devices much easier, while making sure the specific characteristics of a given form-factor are used to their fullest extent.
Again, by sharing the components that make sense to share, we can deliver higher quality features for a given devices with less effort, and thus quicker.
Shell and Look & Feel
Look & Feel setup for Plasma
Plasma can dynamically load different so-called shell packages. The shell package defines the overall layout of the workspace environment. On the desktop, it says that there’s a fullscreen wallpaper background, with a folderview, a panel at the bottom and the widgets which are loaded into that panel: application launcher, task-manager, system tray and clock for example.
The shell package is different for each device, as this defines the overall workflow, which is highly dependent on the type of device.
To take differences between devices even further, Plasma has the concept of “Look and Feel” packages, which allow further specilialization how a device, well, looks and feels. There’s the widget style and the wallpaper of course. The Look and feel package also defines interaction patterns, such as if a settings interface should use “instant apply” when a setting is changed, or if it should present an “Apply and Okay” button for the user to save settings. Mobile devices typically use instant apply, while desktop interfaces (at least Plasma’s) use the “Apply and Okay” concept throughout. For Plasma UIs, this can be changed dynamically. Plasma’s Look and Feel features is not just useful in the convergence aspect, it allows also for example to switch between a traditional default Plasma setup and a workspace that closely resembles Unity. These “Look and Feel” packages are available through the KDE store, so they’re easy to install and share. There’s even a cool tool that allows you to create your own Look and Feel packages, very much like themes.
Apps
Subsurface Mobile, Linux, Android and iOS from the same code-base
Finally, at application level, we see more and more convergent applications. Kirigami, a high-level toolkit that supplied components for consistent, touch- and keyboard/mouse-friendly application nagivation and layout makes it very easy to create applications with responsive UIs that adapt well to screen size and density and that show flexibility in their input methods. This doesn’t just work between Laptops and phones, but also allows to create one app that works equally well on desktops, laptops, phones and tablets.
Kirigami complements Plasma’s convergence feature on application side, and we recommend it for most newly developed apps. With Qt and QtQuick being a viable target for Android devices, it increases the possible target audience by a very large degree. As an example, Subsurface Mobile, an application for scuba divers, uses Kirigami and works on Linux desktops, Android and iOS, all from the same code-base.
Make it happen…
If you like the idea of convergence, why not join KDE and help us work on Plasma? Perhaps you’d love to see Plasma on a mobile phone? In that case, consider backing the crowdfunding campaign for the librem5 so we can build a convergent phone!
