Getting physical

plasma-cernbannerI’ve just finished my travel preparations for this year’s Plasma sprint, which will start tomorrow with the arrival of my fellow hackers in Geneva, CH. Together with a few other groups in KDE and organized by our WikiToLearn friends, we’re honored to be guests at CERN, the European Organization for Nuclear Research where physicists and engineers are probing the fundamental structure of the universe. Of course, these scientists and engineers couldn’t do their work without Plasma, so we’re obliged to hold our meeting there. :-)

Topics range from our Wayland support to Plasma Mobile, documentation, how we can improve our desktop experience, and general planning for the next months. I’m also looking forward to some face-time with my fellow hackers, and discussions with the artists and usability experts who are holding a meeting of the visual design group in KDE. Only good stuff can come out of this.

Many thanks go to all the people who support KDE. This support makes meetings like next week’s possible. Please consider supporting us.

Plasma Components on Android: Accelerating Subsurface Mobile Development

Marco has come over to the Netherlands to pay me a visit, and to hack a little bit together, in person. So with the weather clearly suggesting to stay inside, that’s what we did over the weekend, and how better to entertain yourself than to work on mobile software?

Marco has been working for a while on components that follow Plasma’s human interface guidelines and make it easy to implement applications with a common navigation pattern and look and feel. Obviously, these components use a lot of Plasma under the hood, so they get excellent integration at a visual and at a technical level. This high integration, however, comes at the price of having a non-trivial chain of dependencies. That’s not a problem in Plasma Mobile, or other Plasma workspaces, since all that is already there, anyway.
We thought that an interesting exercise would be to find out what really defines a “Plasma application”, and how we can make the concepts we engrained in their design available to application developers more easily. How hard could it be to use Plasma components in an Android app, for example? The answer is, not entirely trivial, but it just became a whole lot easier. So what did we do?

For those reading this article via a feed aggregator, hop over to youtube to watch the demo video.
We took Subsurface, which is a piece of Free software used for logging and analysing scuba dives. Subsurface has a mobile version, which is still in its infancy, so it’s an excellent candidate to experiment with. We also took Marco’s set of Plasma components that provide a reduced set of functionality, in fact, just enough to create what most applications will need. These components extend QtQuick components where we found them lacking. They’re very light weight, carry no dependencies other than QtQuick, and they’re entirely written in QML, so basically, you add a bunch of QML files to your app and concentrate on what makes your app great, not on overall navigation components or re-implementing for the n-th time a set of widgets.

So after solving some deployment issues, on Saturday night, we had the Plasma mobile components loading in an Android app. A first success. Running the app did show a number of problems, however, so we spent most of the Sunday to look into each problem one by one and trying to solve them. By early Monday morning, we had all of the glaring issues we found during our testing solved, and we got Subsurface mobile to a pretty solid appearance (pretty solid given its early state of development, not bug free by any means).

So, what to take a away from this? In a reduced form, Plasma can be a huge help to create also Android applications. The mobile components which we’re developing with Plasma Mobile as target in mind have had their first real world exposure and a lot of fixes, we got very useful feedback from the Subsurface community which we’re directly feeding back into our components.

A big thanks goes out to the Subsurface team and especially Dirk Hohndel for giving us excellent and timely feedback, for being open to our ideas and for willing to play guinea pig for the Plasma HIG and our components. The state you can see in the above video has already been reviewed and merged into Subsurface’s master tree, so divers around the world will be able to enjoy it when the app becomes available for a wider audience.

Wall drawing

Sol Lewitt's wall drawing at Stedelijk Museum Amsterdam
Sol Lewitt’s wall drawing at Stedelijk Museum Amsterdam
A few weeks ago, I visited the Stedelijk Museum in Amsterdam for an exhibition of Henry Matisse’s works. What stuck is not a painting or collage by Matisse, but a wall drawing by Sol Lewitt. I took a photo with my phone and have since then used it as wallpaper for it, and it works well, colors are nicely toned, everything provides enough contrast, and I like how it looks on a screen.

Yesterday, when I needed a break from hacking on Plasma’s Wayland integration, I remade the photo into vector art to use it as wallpaper. You can download the result here (the wallpaper package has versions for all resolutions, including phone and landscape versions, you can just unzip the package into /usr/share/wallpapers).

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.

Say hi to cuttlefish!

Cuttlefish icon previewer
Cuttlefish icon previewer
One of the things I’ve been sorely missing when doing UI design and development was a good way to preview icons. The icon picker which is shipped with KDE Frameworks is quite nice, but for development purposes it lacks a couple of handy features that allow previewing and picking icons based on how they’re rendered.

Over the christmas downtime, I found some spare cycles to sit down and hammer out a basic tool which allows me to streamline that workflow. In the course of writing this little tool, I realised that it’s not only useful for a developer (like me), but also for artists and designers who often work on or with icons. I decided to target these two groups (UI developers and designers) and try to streamline this tool as good as possible for their usecases.

Cuttlefish is the result of that work. It’s a small tool to list, pick and preview icons. It tries to follow the way we render icons in Plasma UIs as close as possible, in order to make the previews as realistic as possible. I have just shown this little tool to a bunch of fellow Plasma hackers here at the sprint, and it was very well received. I’ve collected a few suggestions what to improve, and of course, cuttlefish being brand-new, it still has a few rough edges.

You can get the source code using the following command:

git clone kde:scratch/sebas/cuttlefish
git clone kde:plasmate

and build it with the cmake.

Enjoy cuttlefish!

[Edit] We moved cuttlefish to the Plasmate repository, it’s now part of Plasma’s SDK.

“Killing the Cashew” done right.

Plasma Desktop's Toolbox
Plasma Desktop’s Toolbox
One of the important design cornerstones of Plasma is that we want to reduce the amount of “hidden features” as much as possible. We do not want to have to rely on the user knowing where to right-click in case she wants to find a certain, desktop-related option, say adding widgets, opening the desktop settings dialog, the activity switcher, etc.. For this, Plasma 4.0 introduced the toolbox, a small icon that when clicked opens a small dialog with actions related to the desktop. To many users, this is an important lifeline when they’re looking for a specific option.

In Plasma 4.x, there was a Plasmoid, provided by a third party, that used a pretty gross hack to remove the toolbox (which was depicted as the old Plasma logo, resembling a cashew a bit). We did not support this officially, but if people are deliberately risking to break their desktop, who are we to complain. They get to keep both pieces.

During the migration to QML (which begun during Plasma 4.x times), one of the parts I had been porting to QtQuick was this toolbox. Like so many other components in Plasma, this is actually a small plugin. That means it’s easy to replace the toolbox with something else. This feature has not really been documented as its more or less an internal thing, and we didn’t want to rob users of this important lifeline.

Some users want to reduce clutter on their desktop as much as possible, however. Since the options offered in the toolbox are also accessible elsewhere (if you know to find them). Replacing the toolbox is actually pretty easy. You can put a unicorn dancing on a rainbow around your desktop there, but you can also replace it with just an empty object, which means that you’re effectively hiding the toolbox.

For users who would rather like their toolbox to be gone, I’ve prepared a small package that overrides the installed toolbox with an empty one. Hiding the toolbox is as easy as installing this minimal package, which means the toolbox doesn’t get shown, or even get loaded.

I would not recommend doing this, especially not as default, but at the same time, I don’t want to limit what people do with their Plasma do what we as developers exactly envision, so there you go.

Download this file, then install it as follows:


plasmapkg2 -t package -i emptytoolbox.plasmoid

Now restart the Plasma Shell (either by stopping the plasmashell process, or by logging out and in again), and your toolbox should be gone.

If you want it back, run

plasmapkg2 -t package -r org.kde.desktoptoolbox

Then restart Plasma and it’s back again.

Even more than just removing the toolbox, I’d like to invite and encourage everybody to come up with nice, crazy and beautiful ideas how to display and interact with the toolbox. The toolbox being a QtQuick Plasmoid package, it’s easy to change and to share with others.

Grumpy wizards

Oxygen Font Example
Oxygen Font Example

In Plasma, we have traditionally relied on the font settings dictated by the distribution we run on. This means that we’ll take whatever “Sans” font the distro has set up (or has left to something else), and worked with that. The results of that were sub-optimal at least, as it meant we had almost no control how things are going to look like for end users. Fonts matter a lot, since they determine how readable the UI is, but also what impression it gives. They also have effect on sizing, and even more so in Plasma Next.

Many widgets’ size in a UI depend on the font: Will this message actually fit into the allowed space for it? (And then: What about a translated version of this message?) In Plasma Next, we’re relying even more on sensible font settings and metrics in order to improve our support for HighDPI displays (displays that have more than 150 dots per inch). To achieve balance in the UI sizing, and to make sizing based on what really matters (how much content fits in there?), we’ve put a much stronger emphasis on fontsize-as-rendered-on-a-given screen. I’ve explained the basic mechanics behind that in an earlier post, so I won’t go into too much detail about that. Suffice to say that the base unit for our sizing is the height of the letter M rendered on the screen. This gives us a good base metric that takes into account the DPI of the screen, but also the preference of the font as set up by the user. In essence, this means that we design UIs to fit a certain number of columns and rows of text (approximately, and with ample dynamic spacing, so also longer translations fit well). It also means that the size of UI elements is not expressed in pixels anymore, and also not relative to the screen resolution, but that you get roughly the same physical size on different displays. This seems to work rather well, and we have gotten little complaints about sizing being off.

Relying on font metrics for low-level sizing units also means that we need the font to actually tell us the truth about its sizing. We need to know for example, how many pixels a given font on a given screen with a given pointsize will take, and we need this font to actually align with these values. This sounds quite logical, but there are fonts out there who don’t do a really good job in telling their metrics. This can lead to over- or undersizes UIs, alignment and margins being off, and a whole bunch of other visual and usability problems. It also looks bad. I find it personally quite frustrating when I see UIs that I or somebody else has spent quite some time on “getting it juuuuuust right”, and then seeing it completely misaligned and wrongly sized, just because some distro didn’t pay enough attention to choose a well-working (by our standards, of course ;)) font.

Oxygen Font in Kickoff Launcher
Oxygen Font in Kickoff Launcher rendered at 180DPI

So, to mitigate these cases, we’ve chosen to be a bit more bold about font selection in Plasma Next. We are now including the Oxygen font and setting it up as default on new installs. This means that we know the defaults work, and they work well across a range of displays and systems. We’re also defaulting to certain renderer settings, so the fonts look as smooth as possible on most machines. This fixes a slew of possible technical issues, but it also has a huge impact on esthetics. By setting a default font, we provide a clearer idea of “with this setup, we feel it’s going to look just right”.

For this, we’ve chosen the Oxygen font, which has been created by Vernon Adams, is released under the SIL Open Font License and has been created under the Google webfonts project. It’s a really beautifully done, modern, simple and clean typeface. It is optimized for rendering with Freetype, and it mainly targets web browsers, desktops, laptops and mobile devices. Vern has created this font for Oxygen and in collaboration with some of the Oxygen designers. The font has actually been around for a while already, but we feel it’s now ready for prime-time, so limelight it is.

As it happens with Free software, this has been a long-lasting itch to scratch for me. One of the first thing I had to do with every install of Plasma (or previously, KDE 3 even), was to change the fonts to something bearable. Imagine finishing the installer, and being greeted with Helvetica — Barf. (And Helvetica isn’t even that bad a font, I’ve seen much worse.) I’m glad we could fix this now in Plasma Next, and I’m confident that this will help many users having a nicer looking desktop without changing anything.

Apart from the technicalities, there will always be users who have a strong preference for a certain font, or setting. For those, we have the font selection in our systemsettings, so you can always set up your personally preferred font. We’re just changing the default.