Tag Archives: kde

New Kirigami communication channels


Kirigami used to have a Telegram channel as its main communication channel. this is of course not optimal being a closed service and many potential contributors not having an account on Telegram.
Since today, we also have an IRC channel
#kde-kirigami on freenode and
#kirigami:matrix.org on Matrix
The Telegram channel is still there, and all 3 are bridged between each other, so a message sent by any of the 3 platforms will be received also by users on the other two.
See you there πŸ™‚

Akademy 2018


The time for Akademy came this year as well, this year it was in the gorgeous Vienna, Austria.
This year marks my 10th Akademy in a row, starting from my first one in Belgium in 2008.
Talks have been awesome as usual, but what’s always awesome for me year by year is all the face to face conversation with so much diverse and smart people in out awesome KDE community.


For me the highlight was the BOF session on Kirigami, in which some nice plans, together the VDG are starting to form.
Kirigami in a QML based UI framework at the core of some KDE applications, which will become more and more central as more and more QML based applications are made.
So far is still a relatively unknown gem in the KE software and frameworks offering, however as technologically is starting to mature, we’ll start to advertise it more and simplify onboarding.
A big part of that will be about web presence and documentation:

  • A nice media-heavy introductory website which will showcase the features it can offer to your app, together expanded sections of the central Kirigami UX patterns in the new Human Interface Guidelines website.
  • Improving the API documentation
  • The Kirigami channel on Telegram will need IRC and Matrix bridges
  • A series of tutorials how to get started developing applications using the Kirigami toolkit
  • Repurpose the example “Kirigami Gallery” application: It will become a showcase of components and UI patterns the developer is recommended to use: each gallery page will also have documentation text together links to the corresponding HIG page and to the gallery page sourcecode itself, to be used as a source of inpiration and best practiches to be used while developing your application

Kirigami Gallery on the Cards pattern, mobile version

Kirigami Gallery on the Cards pattern, desktop version

If you think you can help on this web presence effort, you are welcome to join πŸ™‚


On the Plasma side, many plans of improvement have been discussed and are on their ways, such as better support for touch-based convertible laptops, a completely rewritten and overhauled notification system, and improved Virtual Desktops/Activities infrastructure and UI, on Wayland too.
But, more on all of this in the future πŸ™‚


Vienna is a really charming and beautiful city, I would totally recommend going there at least once.

It’s home not only to great musician in the past:


But also to Important scientists that contributed so much to the knowledge of humanity and.. contributed a littel bit making possible all the technology we know and love πŸ™‚


Kirigami and color palettes


A new release of Kirigami is about to come with the new version of KDE Frameworks about to be released, 5.38.
This is an important release, which bumps the import version to 2.2, because has a very important new feature: A brand new (but retrocompatible) color theming API, which allows different areas of the application to have different color domains, allowing for instance parts of the application to have a light color palette and parts of the application to have a dark one.
This model is modeled after KColorScheme which is very powerful (even tough sometimes underused): as KcolorScheme will be actually used when running on Plasma Desktop (just a runtime plugin, it won’t depend on it, so dependencies on Android or other platforms are not affected) it will allow us to integrate tightly with the other applications made by KDE.

Here you can see the example Kirigami Gallery which has been set to use different color sets in different areas:

Kirigami Gallery with the Breeze widget style: areas with a different ColorSet, widget and icon colors following

Here, this is how choosing different color sets for different areas of the application looks on Android, using the Material style:


The Theme object in Kirigami used to be a singleton (and still is, for full compatibility when the 2.0 or 2.1 version of the import is used), but is now instead an attached property: which is source-compatible (no rewrite needed in your apps, except bumping the import version to 2.2)
You can color differently an area of you application with the following code:

 Item {
    // tells the Theme no not inherit the color set from parent objects
    Kirigami.Theme.inherit: false
    // uses Complementary color set
    Kirigami.Theme.colorSet: Kirigami.Theme.Complementary
    Rectangle {
        //this color will come from the Complementary set
        color: Kirigami.Theme.backgroundColor

Another example of a (very minimal) full application which has the Global Drawer in the Complementary color set:

import QtQuick 2.6
import org.kde.kirigami 2.2 as Kirigami

Kirigami.ApplicationWindow {
    id: root

    globalDrawer: Kirigami.GlobalDrawer {
        Kirigami.Theme.inherit: false
        Kirigami.Theme.colorSet: Kirigami.Theme.Complementary
        title: "Hello App"
        titleIcon: "applications-graphics"

        actions: [
            Kirigami.Action {
                text: "action 1"
            Kirigami.Action {
                text: "action 1"
    contextDrawer: Kirigami.ContextDrawer {
        id: contextDrawer

    pageStack.initialPage: mainPageComponent

    Component {
        id: mainPageComponent
        Kirigami.ScrollablePage {
            title: "Hello"
            Rectangle {
                anchors.fill: parent


Colored monochrome icons

In the above screenshot, you can also see that the icons used there are colored accordingly to the same text color of the ColorSet of the area they are in. When loading in Plasma Desktop, we have the luxury of loading such icons with KIconLoader, which can process SVG-based icon sets with stylesheets, so we can actually have in the icons areas colored with particular named-colors, which correspond with the Theme’s named colors (like textColor, backgroundColor, highlightColor, negativeTextColor and so on) for instance is important that a record icon like the one shown in the screenshot has a red dot as this is the universal accepted iconography. The monochrome icons in the Breeze icon set are “almost” monochrome, with those few colored accents used very sparsely, just when really needed and give definitely a nice touch of polish to the visual identity.
On other platforms they are just treated as monochorome and the whole icon is colored.

Better integration with Plasma Desktop and QWidget style

A QtQuickControls2 style has been written which uses QStyle to paint controls and will be used by default in next Plasma releases (from 5.11 onwards), this is released as a framework as well in 5.39, called qqc2-desktop-style
Here a screenshot of the Gallery using Oxygen widget style and icons:

Kirigami Gallery on desktop, shown with the Oxygen widget style

Different platforms plugins

The framework qqc2-desktop-style also contains a plugin that is dynamically loaded by Kirigami, which bridget the Kirigami Theme.* concept to KColorScheme, making Kirigami apps follow the same palette, as well as using KIconloader to load icons, being capable to apply color stylesheets to Breeze icons.
On other platforms, simpler plugins will be used to not drag dependencies and integrate better on whatever platform they are (like Material on Android)

What about fancy icons on my QWidget app?

Since several KF5 releases, Breeze icons in QWidget-based apps can follow the system palette, so when using a dark color scheme, icons will become white and so on. However: what about using a light color scheme in some areas and a dark one in some other areas?
Since 5.39 KIconLoader has gained a new method, setCustomPalette(), in which you can override the colors for a particular KIconLoader (the app will then need to use different KIconloader instances intended for different areas of the app). Pay attention that in that case you will have to monitor the QApplication palette change and eventually update that kiconloader palette by hand.

Accessibility at Randa


This year the Randa KDE meeting it’s all about Accessibility: a big effort has been concentrated around two very intertwined things: keyboard navigation and screen reader support.
(The fundraising campaign is still going on)
As a first taste, in Plasma 5.11 KRunner will be completely accessible (unfortunately until now screen readers didn’t work at all with it), which is important as is a completely keyboard-focused UI to do things, therefore potentially more user friendly towards vision impaired people.
Orca will be able to read out loud what query has been entered and the currently focused entry, that is what will happen if the user presses the Enter key.
Here it is a screencast of KRunner running with Orca navigating trough the list of result entries.

Climbing grades: a Kirigami example app


In the ever expanding catalog of applications based upon the Kirigami framework and design language, I’ve just published a small one, tough quite useful if you like me have the weird hobby of rock climbing πŸ™‚

It’s called Klimbgrades and it’s not much more than a conversion table between different grading systems for rock climbs (separed by lead and bouldering) used around the world.

At the moment the supported grade scales for lead are French, YDS, UIAA, British Tech and British Adjectival

the grades for Bouldering are Fontainebleu, Hueco and B Grade

You can grab it on Android from the Play Store, or build it from source for yourself either for your desktop or cross-compile it over Android.

From the screenshots you can see there is some amount of automatic adjustment between the mobile and desktop versions, both in terms of style and layout/functionality.

On Android:

On a Plasma Desktop:

Choose Your Own Experience in Plasma 5.8 and beyond


One of the key points of Plasma is while giving a simple default desktop experience, not limiting the user to that single, pre-packed one size fits all UI.
Its strength is to be flexible to greatly different user needs, “Simple by default, powerful when needed”.
Several years ago, the Visual Design Group had the idea of making easy to build and share desktop layouts to make easy to test wildly different user interfaces, see this old post by Thomas on the topic.
Since then, work on it has been going on, mostly on the infrastructure needed to make it a reality, and in Plasma 5.8 the first pieces are there, tough still far from the complete experience we want to offer.

The support for Look and Feel packages is there since a while (5.3 or so) that’s what one of those package can do:

  • Provide a default layout for when Plasma starts for the first time, it was used for distributions to personalise their UI, but now is easier for users as well.
  • Provide some default look options, like what color scheme to use, what icon theme etc
  • (advanced) provide the actual implementation of some UI, such as KRunner, the Alt+Tab window switcher dialog, the lock screen

So far the default Plasma layout provided by the Look and Feel theme was used only when starting up for the first time, on a clean user home (therefore very useful for distributions) but sice Plasma 5.8, in the Workspace theme -> Look & Feel section of system settings there is an option to load the new layout when switching the look and feel theme. Not as default as is a destructive action that will remove your current Desktop setup.


The other component is a tiny little application shipped in the “Plasma Sdk” package that’s called lookandfeelexplorer.
With this applciation you can:

  • Create a new Look and Feel theme
  • Edit the metadata and thumbnail of a locally created/installed theme
  • Create a default javascript desktop layout based upon your current Plasma setup
  • Create a defaults file based upon your current setup as well, such as color scheme and icon theme

The last two are the central part of sharing your idea of “the perfect desktop” with others, linked with the integration between the Look & Feel systemsetting module and the KDE store, also new in Plasma 5.8.

It’s still a preliminary feature, as ideally in the future if your shared Look & Feel theme depends for instance from a particular icon theme or a particular 3rd party plasmoid, the store integration will download those dependencies as well.

QtQuickControls2 and Desktop apps


In the screenshot below, the desktop/Breeze-looking scrollbar it’s actually a control coming from QtQuickControls2.

Since one of the goals of Kirigami is to support also desktop applications, while working on Kirigami 2 (that is mostly porting it to be based on top of QtQuickControls2) I had the need for it to continue to integrate with desktop applications as well.
Unfortunately, desktops are not the primary target for QtQuickcontrls2, and while in Qt 5.9 some much needed desktop-related features, such as mouseover effects are getting back in, being as unrecognizable as possible with QWidget-based applications is definitely not in the roadmap.

Luckily, theming QQC2 is easy, so I’ve started a QtQuickControls2 style that integrates with desktop QStyle-based widgets (actually, based upon the QtQuickControls1 QStyle painter machinery).

If we are serious in using QtQuickControls2 in applications shipped together Plasma, we also must make sure they integrate well with the Plasma desktop’s Breeze look and feel.

I started by theming the scrollbar because I felt it was one of the hardest controls to do.
in QtQuickControls2 the scrollbars are supposed to be an attached property of flickables..
This is pretty simple for the mobile use case, turns out it’s a nightmare to create scrollbars that behave like we are used to in the desktop (unless you’re on mac, which insists to look more and more like iOS), which need to be

  • always visible
  • have optional little arrow buttons for increment/decrenent
  • be besides the flickable, not overlapping the contents, because again, they’re always visible
  • use the global desktop theme

I’ve been able to do all of the following, tough it’s necessary to reintroduce the QtQuickcontrols1 component called ScrollView (which imo was a mistake to remove in QtQuickControls2) which can correctly lay out and size the Flickable relative to its ScrollBar.
Hopefully, you’ll be soon able to build an application with QtQuickcontrols2 and Kirigami2 that feels right at home in a Plasma desktop.
What about Plasma-themed QQC2 controls for plasmoids? that will come too, of course!

Kirigami 1.1


Today the first feature update of Kirigami has been released.
We have a lot of bug fixes and some cool new features:

The Menu class features some changes and fixes which give greater control over the action triggered by submenus and leaf nodes in the menu tree. Submenus now know which entry is their parent, and allow the submenu’s view to be reset when the application needs it to.
The OverlaySheet now allows to embed ListView and GridView instances in it as well.
The Drawer width now is standardized so all applications look coherent from one another and the title now elides if it doesn’t fit. We also introduced the GlobalDrawer.bannerClicked signal to let applications react to banner interaction.
SwipeListItem has been polished to make sure its contents can fit to the space they have and we introduced the Separator component.
Desktop Kirigami applications support the “quit” shortcut (such as Ctrl+Q) now.

Plasma 5.8 will depend from Kirigami 1.1, so if you are planning to write a Kirigami-based application, it will work by default and nicely integrate in the Plasma 5.8 desktop.

Plasma 5.8 also has a new big user for Kirigami 1.1, that is Discover: the application to search and install for new software, has a brand new user interface, based upon Kirigami.


This is problably the last feature release based upon QtQuickControls 1, QtQuickControls 2 version is on the way at an experimental stage. The port will have way simpler code (and smaller memory footprint) but this is an entry for another day πŸ™‚

Icon colors


Breeze icons are very simple SVG files, especially the ones used for actions that are mostly monochromatic are very simple, and that’s part of their appeal.
Since some time, Plasma themes that are SVG files as well have the capability of being colored with system themes.
So, why not doing this for every icon as well?
One problem with monochromatic icons is that they can lose contrast in particular situation: when the application uses another color scheme or in places such as in menu items uder the mouse, that get a blue background, giving a not too visible dark gray on dark blue.
That’s one of those “last mile” polishing issues that may be small, but have quite a big impact on the perceived quality of the finished product.

Starting with Plasma 5.7 Icons will behave the same way as Plasma themes: they can have an internal stylesheet which colors will be replaced at runtime with the colors from the system theme.

Here, Dolphin with the colors theme “Wonton Soup” and all the breeze icons following the text color of the theme:

Some applications, like Gwenview can use a completely custom color scheme, in the case of GwenView, it switches to a dark color scheme when fullscreen, regardless of the normal system color theme:

Icons that are in a “selected” state such as the menu item under the mouse or the current dolphin sidebar item change their color, just like the text does too:
Here with some custom colors for the highlight areas:

How to create a compatible icon?

First of all, Big kudos to Andreas for updating the whole breeze theme to the standard described below πŸ˜€
This is a quite minimal SVG file that supports colors from the system theme (Plasma Svg themes follow the same convention):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

   inkscape:version="0.91 r13725"
      .ColorScheme-Text {
      .ColorScheme-Background {
      .ColorScheme-Highlight {
      .ColorScheme-HighlightedText {
      .ColorScheme-PositiveText {
      .ColorScheme-NeutralText {
      .ColorScheme-NegativeText {
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title />
     inkscape:label="Capa 1"
       class="ColorScheme-Text" />

Here there are two important parts.
The first is the definition of the actual CSS stylesheet:

      .ColorScheme-Text {
      .ColorScheme-Background {
      .ColorScheme-Highlight {
      .ColorScheme-HighlightedText {
      .ColorScheme-PositiveText {
      .ColorScheme-NeutralText {
      .ColorScheme-NegativeText {

The colors defined in Text, Background, Highlight etc will be replaced with the corresponding colors from the system theme (look at the Systemsettings module to configure colors to see what colors they actually are)
This also defines a very minimal palette of “semantic” colors: you have the foreground and background colors for purely monochromatic shapes, and other colors for small accents that make the icon slightly more expressive than purely monochromatic such as Highlight, positive, negative (an “x” icon to close will be usually of “negative” color)

The other important part is the actual definition of the shape:

       class="ColorScheme-Text" />

The rectangle has class=”ColorScheme-Text” that will make the stylesheet match to the class definition of ColorScheme-Text, that defines a color.
In order to actually apply that color, you can see the attribute style=”fill:currentColor”. It’s important no other colors are defined in the style attribute.

Making (or, watering plants the complicated way)


This post wanders quite off topic… but has a lot of pretty pictures indeed πŸ˜‰
Sometimes I ask myself why I am a software developer, the answer in the end is that I always enjoyed creating things, whatever it is going from being sketched out totally in my imagination to finally seeing it in the flesh. Writing software, especially graphical software can be very satisfying exactly because of this mental process of seeing the thing you thought about slowly forming and starting to actually working, with the gap between the mental image and the real thing narrowing more and more (yeah, I’m one of those heavy visual thinkers that can think almost exclusively by images).
But sometimes nothing can replace the satisfaction to create an actual, beautiful object, and I also feel manual skills are something that we should cultivate much more, I feel more complete if every now and then I do something that a) I don’t know anything about when I start and b) it’s a difficult manual skill to craft.
That’s also why before drawing the svg for the Kirigami banner
I “had” to make some experiments of an actual kirigami…
But this post is not about that.

Almost a year ago, a friend of mine told me that he wanted to learn a bit to hack on some simple Arduino stuff, and you know what? I wanted too.
I have this stubborn quality that makes me to go quite overboard when I decide to do something (especially if is not for myself) and not to stop until is done, actually useful and pretty, so if we are doing some Arduino project, let’s do something that has an use and that will be pretty… and that’s how the project “Bagnur” started (means watering can in Piedmontese language).


Of course it needed a logo :p

The project is one that is seen again and again on the interwebs, so is just a remix of existing ideas rather than something truly innovative: the Arduino takes data from a soil moisture sensor (different humidity in the soil changes current conductivity), to figure out how much water the soil of a potted plant has.
When is dry enough it opens a solenoid based valve to pour enough water in, and the moisture sampling goes on and on, hopefully stopping you from killing those poor potted plants from thirst after forgetting watering them for days πŸ˜‰


The final hand made steampunk-like package

The moisture sensor is based on the LM393 chip, the solenoid valve is similar to this one (hilariously overspec for this project, love this kind of overkill).

So we know the Arduino output pins have a too weak current to operate the valve, it will have to be powered separatedly: the Arduino will close its circuit with a transistor, I had just salvaged an E13007 NPN transistor that had useful charateristics (low base-emitter saturation voltage, resists quite heavy loads) from a broken ATX power supply.
This makes things a bit more interesting, luckily in the end a single power source was enough to power the Arduino and the valve in parallel, probably not particularly recomended, but cheap and compact (having 2 different power bricks for such a sillyness wouldn’t have been particularly fun for day to day use).

To make the project a bit more interesting, we have a potentiometer that will regulate how much water the plant needs, different plants, different needs and one of those pretty RGB LEDs, that will be the “output UI” of the thing.
The state of the led will be:

  • Fading from pure red (soil bone dry) to pure green (soil soaking wet) with all the values in between
  • Fading to blue when the valve is open, and the plant is being watered
  • The LED will stay usually at a very low power, the sensor will do a reading every 10 seconds or so, when this happens the LED will fade to full power with a nice animation

For the final thing, I decided to use an Arduino Nano compatible board, based as well on the ATMega 328 chip, since I don’t need many pins or performance, it just has to be as small, low power and cheap as possible.

In this Github repo there are both the source code of the program running in the arduino and a couple of schematics drawn with Fritzing, so it should be of easy replication and improvement… if someone really wants to πŸ˜‰

The final board will be in an hand-made case made of wood that gives it a cool almost “steampunk” look: that was honestly for me the most fun part of the project of all, probably because was the farthest from what I usually do, the most low-tech, hand skill demanding part (and slightly dangerous… yep, it involves rotating blades :p).

Video of the thing in action

This videos shows some assembling steps and the thing in action, both opening the valve automatically based on the moisture sensor values and manually with the button on top.


Bagnur, bredboard

Let’s start from the usual prototyping with the classic Arduino Uno/breadboard combination (here still with different colored leds instead of the final single RGB one)

After the breadboard prototype is done, let's start to lay out the components on a perfboard, to make it more "definitive"

After the breadboard prototype is done, let’s start to lay out the components on a perfboard, to make it look more like a final prototype, usable day to day

First components attached to the perfboard. The Arduino Nano will connect it as a daughter board.

First components attached to the perfboard.
The Arduino Nano will connect it as a daughter board.

Yep!, i definitely need to improve my soldering skills, but I swear, even if is kinda ugly, it works like a charm ;)

Yep!, i definitely need to improve my soldering skills, but I swear, even if is kinda ugly, it works like a charm πŸ˜‰

Still some components missing, already attached to the wooden base

Still some components missing, already attached to the wooden base


As I mentioned, for me the most interesting part was to build a wooden case from scratch, from a raw plank of wood, trying to master some of the classic woodwork tecniques.

This is a Combination Machine, I show here some of the steps of the use of the thickness planer and the table saw.

The plank is made thinner and smoother via a thickness planer, after this step the setup of the machine changes becoming a surface planer to do a more precise retouch. Process repeats until the wood reaches the desired thickness.

The plank is made thinner and smoother via a thickness planer; after this step the setup of the machine changes becoming a surface planer for a more precise and smoother retouching. The process repeats until the wood reaches the desired thickness.

Did i mention, ROTATING BLADES?

Did i mention, ROTATING BLADES?

All the sides of the box are done

All the sides of the box are done

After the box has been glued, it has to be tied very, very tightly as the glue dries

After the box has been glued, it has to be tied very, very tightly as the glue dries

The joints are not very precise ...yet

The joints are not very precise …yet

...But some aggressive sandpapering for sure helps, best if done with a Sander

…But some aggressive sandpapering for sure helps, best if done with a Sander

The lid of the box with a translucent, water proof paint, with the moisture sensor, the led and the button attached

The lid of the box with a translucent, water proof paint, attached to the top are the moisture sensor, the RGB LED and a button to manually open the valve.

The complete device, ready to be closed. Wires on the left control the RGB LED, wires on the right control the moisture sensor.

The complete device, ready to be closed. The wires on the left control the RGB LED, the blue and green wires in the middle control the button, the wires on the right control the moisture sensor.

The completed little, mean machine.

The completed little, mean machine.

It has been an insanely fun project, and I am sure my technique can still improve in all areas (designing an electronics board, soldering, woodwork…). If I’ll keep trying to improve with new projects I don’t know yet, but the recomendation I can make is get out of the comfort zone of your day-to-day work and experiment: you have only to gain, if only for the act of doing things wrong, without which there is no learning.