It’s a pleasure to announce the first stable release of KIO FUSE, just in time for 2021.

Compared to the last release candidate, the following changed:

  • Symlinks with an absolute target path are “rewritten” to point to the location inside the target instead of the host system
  • Mounting a URL which includes symlinks now works.
  • The DBus service can use systemd activation now.

Known issues:

Hopefully distro packagers will be quick to pick up this release. If you wish to test with your own compiled version, or wish to contribute a patch please check out our README.

Please file bug reports here.

If you’re eligible for Google Summer of Code, please contact us if you’d like to take up a project developing on KIO FUSE. Some ideas (of which you can suggest your own) and contact details can be found here.



The last day of the year… So, let’s look back a bit. First off: none of the Krita developers has died this year. It feels strange to write that, but it might reassure some of our readers. Some of us have had some extended periods of down time, or have been less productive, both because of the effect of the different pandemic measures all over the world, and because it was at times really hard to stay motivated and find the energy for coding. That shouldn’t come as a surprise to anyone. It feels surreal to think we actually had a real, physical development sprint — in February.


So, what did we do? In the first place, we made four releases: Krita 4.2.9, 4.3.0, 4.4.0 and 4.4.1, and now we’re working on 4.4.2. Krita came to ChromeOS and Android, too!

With these releases came improved brush outlines while painting, new features for the color smudge brush, watercolor brush presets, new filters, extended scripting support, the snapshot docker, a magnetic selection tool, new fill layers, new features for the pixel brush engine, mesh gradients, mesh transforms, improvements to the gradients — and much, much more, as well as hundreds of bug fixes.


Still, bugzilla is a disaster area. We get too many bug reports that are actually user support requests, but apart from that, it’s a never ending stream of things that need to be cleaned up. Check the link if you want to read about the nightmares…


And we coded… A lot. Over all the branches, there were 5486 commits in 2020. Apart from the new features that ended up in releases, we also worked on supporting MyPaint brushes, making the appimages updatable, a new plugin for recording your painting process, storyboarding, a ton of new features and updates for animations and a lot of work on a project that we have been working on for three years now: the resource system rewrite.

You can test all of that in the nightly builds for Windows, Linux and macOS: KDE’s binary factory certainly has been the single most important thing for improving our development process! Though the move to gitlab also did wonders for our productivity.

The resource rewrite project still isn’t done, though pretty much everything is in place. It is taking a lot of work to convert all the places where resources (like brushes, gradients, presets) are used to the new system. And as a project, it turns out it’s simply too large. We decided to change too many things in one big refactoring and, frankly, it’s motivation-sapping especially in a year that’s already hard on everyone. And yes, we also mentioned that already last year. The 2020 February sprint was intended to be a kick-off for a concerted attack on the resource system with four people working on until it was done, but then came March…

We will have to finish this next year, so we can release Krita 5.0 and can start spending time on fun things like the text tool, machine learning based image scaling, dithered and HDR gradients and other fun and fancy features.

We also had Four Google Summer of Code: Sharaf Zaman with Mesh Gradients, Amyspark with the SeExpr-based scriptable fill layers, Saurabh Kumar with storyboarding and Ashwin Daikata with the MyPaint brush engine. The first two are already released, the other two projects have been merged to master and will be in Krita 5.0.


Compared to 2019, we have almost twice the number of downloads 4,856,435 downloads compared to 2,346,618 in 2019 — and that’s just from our download page.

We started sponsoring Ramon Miranda to publish regular videos on Krita’s youtube channel. The goal is to make a dozen videos a year:

And in addition to videos, Ramon has created resources like brush presets and templates, all freely downloadable!

Maybe the biggest success of the year was the way Raghukamath’s initiative has taken off. Fifty-thousand posts now, hundreds of active users and really interesting discussions about Krita’s user interface, about writing plugins in Python, about art — and importantly, it’s finally a place where people support each other.

krita-artists website


We are working on a new development fund, modeled on Blender’s. We’re actually reusing the same code Blender uses for their dev fund website. This should go live in 2021. It’s almost done, there’s some styling needed, and some work on a campaign to tell the world about it. Since we usually prepare campaigns like kickstarter by getting together physically and thrashing it out over the kitchen table in Krita’s Deventer HQ, we’re a bit at a disadvantage here.

Donations have held up strongly all through 2020, bringing in enough to sponsor our lead developer, Dmitry and fund ongoing work on the manual: €45,672.41 euros (2019 was €29,715.20). The other sponsored developers have been paid through income generated through the Windows Store and Steam. All in all, there are now nine people sponsored to work on Krita, in areas like animation, Android/ChromeOS, writing the manual, fixing bugs, working on the builds and build systems and coding up new features. Nobody is getting rich, but it’s a good feeling to work on an application that is being used by three to four million people every month.

And next…

We have to release Krita 5.0 as soon as possible, and for that we need to finish the resource system rewrite. That will be the absolute focus for the first months of 2021, which means that a 4.4.3 release will have to wait, if there will be one at all.

There will a release of Krita for Apple’s M1 laptops: though Apple probably will go on making life difficult for developers.

We will launch the new Developer Fund and maybe get Krita in the macOS app store (not the iPadOS store). Though right now, the team is about as large as Krita’s project maintainer can manage…

And Qt 6 has been released. The changes to the way Qt handles GPU acceleration will make it a real challenge to port Krita to Qt6, not to mention all the other changes and deprecations, making it unlikely we’ll have a Qt 6-based release ready in 2021. We’ll have to work on, though, which will eat into the time we have for creating features and fixing bugs users actually care about.

And maybe? Maybe there will be a real life contributors get-together again! Hope springs eternal. See you all in 2021!

The post Krita in 2020 appeared first on Krita.

2020 was for sure no good year for most people around the world. A lot of us are affected directly or indirectly by the currently still raging COVID-19 pandemic. Let’s hope that 2021 will bring better fortune at least in this aspect.

Still, good stuff happened in 2020, too, not all was bleak. I read already some wrap ups of 2020 from others like Nate and Aleix. A lot stuff happened inside the KDE community this year.

Kate and it’s closely related parts KTextEditor & KSyntaxHighlighting evolved a lot in 2020, too. Let’s take a look at the highlights out of my perspective ;=)

Kate got a new icon!

We refreshed our branding by introducing a new default icon for Kate designed by Tyson Tan.

Even thought this is no functional change, for a first time in the now 20 years lifetime of Kate we have some instantly recognizable icon. Yes, it doesn’t show it is an text editor, but the icons of Atom/Sublime/VS Code and Co. don’t do that neither. But you can finally remember it after seeing it a few times => the bird is Kate ;=)

Thanks again to Tyson Tan for spending his time to work on this. And thanks to Noah Davis & Nate Graham to get this into Breeze, too. Even “just” changing the icon is a real team effort!

Our LSP client matured

Already in 2019 with 19.12 we had the first release of our LSP client plugin. In 2020 this plugin matured even further since the latest status report.

Mark Nauwelaerts did a brilliant job in creating and further polishing this feature!

I use this plugin now daily at work and am very happy with the current state.

If you still have some itch to scratch there, please contribute. The plugin is well structured and it is easy to extended, for example Waqar Ahmed just provided support for “Find Implementations”.

Tabs, tabs, tabs…

One of the largest visible UI changes in 2020 in the Kate application itself was the return of the classical tabbing in 20.08 and then again the addition of optional LRU like tabbing in 20.12.

As can be seen above, since then Kate learned in the master branch a bit more fine grained configuration of the tabbing. You want LRU like tabbing => set a limit for number of tabs. You like larger expanding tabs? You dislike the double/middle-click behavior? => Configure it like you want it to be!

KTextEditor & KSyntaxHighlighting Color Themes

After years of procrastination KTextEditor finally started to use the color themes as provided by KSyntaxHighlighting. Details of this change can be found in the two summaries here and there. Unfortunately the configuration dialog in KTextEditor had still some faults in 5.75, these should be rectified in 5.76 and higher.

As this was an incompatible change, especially regarding user defined themes, this wasn’t done lighthearted but it was required to have some future proof theme support. The new theme storage is a standalone JSON file. The same format is used for the shipped themes as for the user defined ones. No longer some special storage inside some misused KConfig files.

If you have a lot of local old theme config, the KSyntaxHighlighting repository contains some python based converter scripts. The are inside the utils folder.

Kate provides now already 19 default themes. And as this is a KSyntaxHighlighting & KTextEditor feature, all other applications using this like KDevelop benefit, too. You can now have out of the box nice themes like ayu Mirage:

 * SPDX-FileCopyrightText: 2020 Christoph Cullmann <>
 * SPDX-License-Identifier: MIT
#include <string>
#include <QString>
// END
 * TODO: improve documentation
 * @param magicArgument some magic argument
 * @return magic return value
int main(uint64_t magicArgument)
if (magicArgument > 1) {
const std::string string = "source file: \"" __FILE__ "\"";
const QString qString(QStringLiteral("test"));
return qrand();
/* BUG: bogus integer constant inside next line */
const double g = 1.1e12 * 0b01'01'01'01 - 43a + 0x11234 * 0234ULL - 'c' * 42;
return g > 1.3f;

If you want to provide more themes, please submit some merge request.

Kate on Windows

Kate is now more than one year in the official Windows Store. And it seems we are not that unloved there, see the latest in detail status report.

Our rating even improved since that report, see below today’s state!

Today, 31.12.2020, 75,889 Kate installations were done via the store alone since we launched there last year!

Thanks to all that helped to make this happen, like Hannah!

Short interlude: Kate turned twenty!

Finally, in December, Kate turned twenty. How it all began:

Yes, we used stuff without anti-aliasing in the ancient past.

Most important: Our Contributors!

All above mentioned things are cool, but what keeps Kate and it’s KF5 frameworks base afloat are the people that contribute.

Perhaps this is just a feeling, as I didn’t do proper statistics about it, but I believe since we switched over the development to our GitLab instance at, more contributions are arriving.

Contributing via GitLab merge requests seems to really be more easy especially for new people. We already merge:

Naturally a lot of these patches are small things, but even they matter!

You found some wrong documentation => sure we are interested in a fix!

You did create color theme that might be worth sharing => hand it in!

You wrote a JSON configuration for a LSP server we forgot => we want that!

Our automatically generated team page now already lists over 560 contributors. Join our ranks and help us to make our stuff awesome!

Thanks to everybody that helped to improve our stuff!

New Year Wishes

Let’s hope 2021 will be a better year for the world!

And I hope we will see a further rise in contributors & contributions for Kate and KDE in general.

Let’s rock!

I recently obtained a brand new Raspberry Pi4 device and took the free days around x-mas to play a little bit around with it. And I must say, I am very pleased with this device!

Raspberry Pi 4 B

The important updates for me, comparing to the older Pis are:

  • Two displays can be connected! Either two HDMI or one DSI plus one HDMI.
  • It has a VideoCore VI GPU (very different to the IV from RPi3), which is driven by the MESA V3D driver.

My goal was to get a Yocto-built multi-display plasma-mobile environment on the device. Except two magic lines for the /boot/config.txt configuration that enabled multi-display output for me, it nearly worked out of the box.

RPi4 Multi-Display Setup

The important configuration step, compared to the default configuration as provided by meta-raspberry, are the following two lines that I had to add to the /boot/config.txt boot configuration:


Without these lines, the second screen always displayed just the Raspberry’s rainbow boot screen but it was never detected. I tested with both DSI+HDMI and HMDI+HDMI and both screens were always correctly detected at boot with these configuration.

Running Qt on Yocto-Build Image

Having the above configuration added, I was able to run a simple multi-screen QtWayland Compositor on the device. Note that I built Qt with

PACKAGECONFIG_append = " gbm kms eglfs"

and QtWayland with

PACKAGECONFIG_append_raspberrypi4 = " wayland-drm-egl-server-buffer"

With these options and having all requirements installed, the compositor runs via

export XDG_RUNTIME_DIR=/var/run/
export GALLIUM_HUD=fps # gives nice profiling information about fps
export QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=linux-dmabuf-unstable-v1
qmlscene Compositor.qml -platform eglfs

It is important to note that qmlscene internally sets the Qt::AA_ShareOpenGLContexts attribute which you have to do yourself when running a compositor with your own main file.

Having this compositor running, I could run a simple spinning rectangle application via

export XDG_RUNTIME_DIR=/var/run/
qmlscene SpinningRectangle.qml -platform wayland-egl

Plasma Mobile

The final step though was to get our KDE Demo Setup running. Since there were no live conferences this year, some parts were slightly outdated. So, this was a good opportunity to update our meta layers:

  • meta-kf5 is now updated to KDE Frameworks 5.77.0. Note that we also cleaned up the license statements a few months ago, which was only possible due to much better license information via the SPDX/REUSE conversion of frameworks.
  • meta-kde also gained an update to the latest Plasma release and to the latest KDE Applications release. The number of provided applications — additional to Plasma — is still small, but I also used the opportunity to add some more KDE Edu applications (Blinken, Marble, Kanagram, KHangman, GCompris).

Final Result

Plasma mobile running with two screens \o/

PS: My whole test configuration if available by my (quick and dirty) umbrella test repository, in which I have all used meta layers integrated as submodules.


31 December, 2020

2020 was not an amazing year for most of us, but it sure was for KDE and people who use KDE software! Despite the inability to travel and meet for sprints, conferences, and Akademy in person, we kept busy.

I’d like to highlight some of my favorite improvements throughout KDE! Keep in mind this is not even a small fraction of everything that went on. To keep this post from ballooning a hundred pages long, I’ve had to leave out many smaller features, all of the performance and bugfixing work, and tons of KDE apps that I don’t closely follow, including big important ones like Krita, Kdenlive, Digikam, and GCompris. You can find more news at

Also, those of you who like podcasts or are audio learners can listen to a condensed version of this post in the Linux Unplugged podcast #385, where I spoke a bit about some of these things:

Roadmap items

From last year’s proposed roadmap, we got FUSE mounts, improved Samba share discovery, automatic screen rotation, and Breeze Evolution visual overhaul work starting to land!

We did not get PolKit privilege escalation, new photo wallpapers, per-screen scale factors on X11, or inertial scrolling in Plasma and QML apps, or power/session actions on the lock screen. Some of these will be punted to next year. More on that tomorrow!

Hardware Partnerships

We created a new page on the website showcasing the ways that you can get Plasma pre-installed on hardware: It showcases two very exciting new devices:


This year massive progress was made on the Plasma Wayland session, including screencasting support, shared clipboard support in Klipper, support for middle-click-paste, support for multi-GPU output, support for thew KRunner windows runner, Task Manager Window thumbnails, screen rotation, High DPI screenshot and timer support in Spectacle, the virtual keyboard now works for GTK apps, configurable mouse and touchpad scroll speed, and global menu support. Phew! You can read more about it on Aleix’s blog:


The following websites were created or overhauled to modern standards and content:,,,,,,,,,,,,,,,,,,,,

Check ’em out; they look great!


We had our first virtual Akademy, and it went very well thanks to KDE’s talented sysadmins! You can watch the video recordings of all the talks, workshops, and other content at


We began the process of migrating to GitLab at! Thus far we are using GitLab for code review, and are working on migrating the continuous integration system next. After that will be Phabricator Tasks, and then hopefully bug reporting (a man can dream).

We also began the process of migrating to a totally new single sign-on system: Read all about it here:


We kicked off the year with the Plasma 5.18 Long Term Support version, which was received very well, and is shipped in Kubuntu 20.04 and openSUSE Leap 15.2.

It was a big year for Plasma and Breeze app styling. The overhauled visuals we’ve been working on for years started landing, including a defined header area in apps and plasma applets, an updated Breeze Light color scheme that’s now used by default, a new more compact OSD style, and a new optional hybrid dark/light theme. To top it all off, Plasma now uses an Icons-Only Task Manager by default.

We also did a massive overhaul of the System tray from top to bottom: all of the applets were polished both visually and functionally, most bugs were fixed, various new features were added, and the whole thing was made more cohesive overall.

The Digital Clock also received a lot of attention, gaining a fancy new popup that shows timezones, an overhauled page for adding, removing, and switching timezones, and the ability to set the first day of the week. It also shows the date in its panel version by default.

The rest of Plasma gained many new features including a fancy new “Get New [Thing]” dialog, a new System Tray applet for controlling Night Color, new System Monitor applets, a new system monitoring app, a new inline character palette for entering alternative characters, the ability to set a maximum charge limit for laptop hardware that supports it (like Lenovo ThinkPads), and the ability to reply to notifications inline, in apps that support it (like Telegram).

On the backend side, Plasma now has full touch support for Folder View/desktop items, and optional Systemd integration, which improves startup times and gains the ability to group processes by app.

Plasma Mobile also had a banner year, attracting a number of new developers and undergoing heavy development work, culminating in the PinePhone product running Plasma Mobile!

System Settings & Info Center

System Settings and Info Center (which now uses the System Settings app as its backend, sharing code) gained various new features, including automatically syncing relevant system-level Qt/KDE app settings to GTK apps, a “Highlight Changed Settings” feature, the ability to download new KRunner Runners from, a new S.M.A.R.T. Monitoring page and notification system, a new Network Interfaces page, a completely overhauled Samba page. We also ported many System Settings pages to QML. This makes those pages usable in Plasma Mobile and provides an opportunity to modernize the UX. Ported pages include Accessibility, Autostart, Background Services, Bluetooth, Desktop Session, Screen Locking, Shortcuts, Users, and Window Rules.

Those orange dots show which pages have any settings that have been changed from their default settings


In addition to the aforementioned Wayland work–almost all of which heavily involved KWin–our venerable window manager gained support for clipped subsurfaces and the ability to tile windows to a corner by combining the side tiling shortcuts. We also changed the window dragging shortcut to Meta+Drag to avoid conflicts with popular apps, and made minimized windows no longer automatically move to the end of the Task Switcher. All of this in additions to tons and tons of bugfixes and performance work.

Applications & Frameworks

All KDE apps now support AV1 images, support copy-on-write support when using the BTRFS file system, and remember the positions of their windows, including on a per-screen-arrangement basis.

Dolphin and file management

It was a big year for interacting with remote files. First, we released kio-fuse, which makes the experience of dealing with remote files a hundred times better. We integrated WS-DISCOVERY support which makes Dolphin able to locate modern Samba shares, and overhauled the Samba share creator to work much better. Dolphin also gained full touch support, a plugin to mount ISO images, the ability to display real on-disk sizes for folders in Details view. Dolphin also now displays its URL navigator/breadcrumbs bar in the toolbar by default, and remembers its prior window state by default.


Elisa gained many features including the ability to edit song metadata, change the sort criteria, remain playing in the background with only a System Tray item visible, repeat one track, display the contents of a category in the sidebar, and override the systemwide color scheme. Finally, the “Previous track” action goes back to the beginning of the current track unless playback is within the first 5 seconds.


Kate turned 20! To celebrate, its tab bar now has a standard appearance and new tabs are opened on the right. And the app–as well as other text editor views based on the KTextEditor framework–now fully respect your systemwide color scheme! You can read more about it on the Kate blog here:


Konsole gained a variety of useful new features such as inline previews for images and HTML color codes that you hover the cursor over, the ability to assign custom colors to tabs, and a new on-by-default toolbar. Also, paths in grep output are now clickable to jump directly to that line of code in the file!


Okular gained the ability to digitally sign documents and now offers (optional) smooth scrolling, which was a bit rocky at first, but we fixed it. 🙂 The Annotations feature was totally overhauled with a new toolbar that makes it easier to change the parameters of an annotation, and and there were various UI improvements to the sidebar and the default toolbar. Okular also adopted date-based versioning, matching most other KDE apps using the release service. 🙂


In addition to the aforementioned Wayland improvements, Spectacle gained the ability to annotate newly-taken screenshots!

How very meta

And remember, this is just a subset of a subset! KDE has over a hundred other apps which you can find out about at And I didn’t even mention some of the amazing stuff that’s still under development but not yet released, like a firewall control UI for Plasma and totally re-worked compositing in KWin which will result in support >60hz screen refresh rates and mixed refresh rates in multi-screen setups. Stay tuned for more information about that stuff and more. 🙂

Ten years ago, I started a new job. If I didn’t blog these things, I would never be able to remember them. Eleven years ago, I was blogging every other day, about all kinds of Free Software things and OpenSolaris bits and travels. This year has been a downer for a lot of folks, and I grew my hair long and my beard woolly as memories of swimming in the Amazon river fade away. Here’s some end-of-year summary bits to make an even 50 posts for the year.

Calamares in 2020

Calamares is a distro- and desktop-independent Linux installer. I keep intending to extend it to do FreeBSD installations as well, but get side-tracked by bugs and features on the Linux side instead. In 2020:

  • The Calamares website got a lovely make-over thanks to Anke
  • There were 17 regular releases
  • There were 5 hotfix releases

I try to run Calamares on a short-release-cycle system, where the main development branch is, in principle, always ready for a release and feature branches get merged in; every two or three weeks there is a release of whatever-is-ready-now, if it is at all useful. 52 weeks divided by three tells me that I’ve been reasonably good at keeping to that schedule on average.

For 2021 I intend to go support one Season of KDE student doing various improvements in Calamares, maintain the release cadence, help out PostmarketOS where possible and finally start on that long-needed partitioning rewrite.

FreeBSD in 2020

Bug counts have gone up in the past few months, we’re at 41 today. I remember us at 28 or so, which seems more manageable.

The KDE on FreeBSD team has expanded a bit, with new contributors and assistants and increased cooperation across the X11 and desktop layers on FreeBSD. Somewhat ironically, it is KDE that maintains GNOME on FreeBSD.

The things the team did can be found on the f.k.o site under news (note to self: add news items more regularly) and in the FreeBSD quarterly reports (note to self: q4 will be published soon). The summary is, though:

  • chased all the KDE Frameworks releases
  • chased all the KDE Plasma Desktop releases
  • chased all the KDE Applications releases
  • landed Qt 5.15.2 and WebEngine
  • chased all the CMake releases, including breakage across a few thousand packages
  • landed some ninja releases and other related build-stack tools

Individual team members also do other things in the FreeBSD world; I chased the releases of audio/praat which is a program to support doing phonology on a computer, while Tobias prepared Qt6 packages. I think we are getting better at upstreaming things in general, and I filed a lot of PRs in GitHub for things that were being fixed in packaging (and should be fixed upstream instead).

Now on this last day of 2020 I’m informed that Cutelyst has some new releases even if Daniele hasn’t announced them yet .. more updates to come!

KDE in 2020

On the KDE-upstream front the big news was the switch to GitLab but my own activity has been fairly limited; most of KDE software is just fine on FreeBSD, and I’ve done just a few small PRs for various improvements. I like the TODO feature of GitLab, although I kind of wish it would also include the “merge requests you have authored that are not yet merged” and some other bits and bobs.

Neochat is the best new thing to come out of KDE this year as far as I’m concerned: a desktop Matrix client that is pretty nice to use.

Other things?

There is life outside software! Yes indeedy. I grew my hair long, but that is a natural consequence of “I get my hair cut before going to conferences” and all the conferences being cancelled. I also didn’t visit nearly all the people I would have liked to, this year, and bicycling all over the place in summer didn’t happen either.

I did help repair the roof of the carport out front of my house, and watched both kids (unoriginally indexed as 0 and 1) grow up and learn to be adults. Kid 1 knows more gardening than I do, and kid 0 knows more real analysis than I remember having forgotten. Both have learned to cook the way I do: slapdash, and inventive, and sometimes inedible for some people in the house (it is possible to overdo it on the sambal front).

Things for the coming year are “fix my recumbent bike which has been rusting for too long in the shed” “build a chicken coop” and “restore my cooking website which vanished in the late ’90s”. Hopefully more than that will happen, and the world can slowly open up again as we head towards northern-hemisphere summer.

🎆🎇🍷💏 until the new year.

Over the last few years and especially since the Wayland goal vote, the Plasma team, we have been focusing on having our Plasma Wayland experience work at least as good as our traditional Plasma X11 experience does. Today I’d like to wrap up my experience on this front for 2020.

Despite having been working on KDE and even Plasma projects for a long while, I’d never gotten much deep into working on KWin internally. I dipped my toes in it in 2019 when working on the key states feature (that plasmoid that says if caps lock is pressed or not, which we needed because the KDE Slimbook didn’t have an LED for the Caps Lock). Here I’ll discuss a bit how it evolved over time.


Tablet support

It’s probably been my first big feature contribution to KWin. From 5.19 you’ve been able to use your tablets to draw things, all features should work fine and life should work. In the beginning, I was mostly interested in getting the 2-in-1 tablet with a pen work, hence implementing this one first.
The rest of the spec implementation is pending review here and hopefully should make it into 5.21:

Screen casting support

This is something I’ve worked on mostly with my Blue Systems hat on, but still is something very important for our daily usage of Wayland, especially nowadays where working remotely is more important than ever and sharing our screens and windows is something that we need to do on a daily basis.

KWin used to support already sharing screens, or rather xdg-desktop-portal-kde could, now we centralised the implementation in KWin and made sure it’s as performant as possible. It was admittedly rather complex to put together, but allowed me to understand how the system works and helped me have a better insight of the architecture.

Input Methods

Plasma Mobile is becoming a palpable reality and input is very important on any touch device. In Plasma Mobile we’d been relying on having Qt’s embedded virtual keyboard since the beginning and while it worked reasonably well, we needed to make it possible for us to offer more and better solutions. This time, we implemented the unstable input-method protocol which allowed us to use keyboards implemented in a separate process, hence making it possible to integrate the Maliit keyboard transparent, as well as the weston keyboard if minimalism is your thing.

Maliit keyboard

This, of course, opens the possibility of much more development on top in terms of other better virtual keyboards, improving the current ones or the integration of more esoteric kinds of input methods (e.g. ibus, fcitx, emoji keyboard or even spell checkers and the likes).

Developing comfortably

Something that was clear to me as soon as the Wayland Goal was shaping up was that we had to find ways to free ourselves a bit from the ABI limitations. From the beginning, Wayland interfaces started to be developed in KWayland under KDE Frameworks 5. This meant that server-side implementations had to stay backwards compatible to certain versions of KF5 and that we couldn’t do certain things. We moved KWayland Server components into a separate component here, that is released with Plasma and we can develop as we see fit: Note that KWayland Client classes stay there where they always were.

This has allowed us in turn to adopt the usage of qtwaylandscanner, which is a tool that generates certain boilerplate C++ code for us from the xml spec, allowing us to focus on the parts we care about in the implementation. This makes Wayland protocol implementation a bit more straightforward while removing some code. You can see the MRs Adrien and Vlad made doing this if you’re curious about the changes it conveys. Our first protocol implementation to use qtwaylandscanner was the keystate protocol I mentioned earlier.


As it’s important to explain what we do so people are aware of it, I decided to take some time this year to explain the different aspects of our Wayland initiative and overall why Wayland makes sense. You can see it explained here, I wouldn’t recommend you to look at them all, but it could be useful for you to look at the one that fits your perspective better.

KWin and Wayland

Wayland for Product creators

Wayland for App Developers

Plasma Wayland: donde estamos y como ayudar (in Spanish)


I know there’s a lot of really exciting stuff coming up from the team. If you’re interested, stay tuned. We will be having a sprint early January to discuss different topics from major roadblocks to a light and comfortable experience.

Consider joining us either at the sprint or at the Wayland goal forums and work with us towards a better experience using Free Software and Plasma.


30 December, 2020

Currently, Calindori works with calendar data provided by files that follow the iCalendar specification, without offering an out-of-the-box way to synchronize your calendars with external sources, e.g. with Nextcloud. However, this will change in the future. In specific, a plan for this feature has been devised. The first step, a plugin interface that will enable Calindori to use calendar data from various data sources is already in progress.

Although Calindori works on Linux mobile, desktop and even Android, it has been created as the calendar of Plasma Mobile. From this point of view, as soon as a personal information management (PIM) system is available on Plasma Mobile, Calindori will make use of it. However, such a system has not been implemented yet. Various ideas have been discussed on the Plasma Mobile sprints and community meetings. Personally, I am in favor of a sustainable, KDE community driven solution that will work well with Plasma desktop as well as taking into account the particularities of the mobile world, e.g. low energy consumption, “deep sleep” support, etc.

Calindori desktop Calindori on desktop

That being said, let me describe here an online calendar synchronization approach that has worked well for me. My personal workflow consists of a personal Nextcloud server -where my calendar is hosted- and various devices that make use of the Nextcloud calendar. As I said in the beginning, Calindori uses iCalendar files for calendar data. Thus, I looked for a mechanism that uses iCalendar files and synchronizes them with Nextcloud. During my research for such a solution, I stumbled upon Vdirsyncer.

As the home page of the project reads, Vdirsyncer is a “command-line tool for synchronizing calendars and address books between a variety of servers and the local file system”. Let me now describe how I managed to configure it and make it work with Calindori.

Certainly, the first necessary step is to install Vdirsyncer. Luckily, it is available in various Linux repositories. E.g, on Ubuntu you just have to install the vdirsyncer package. Next, according to the project documentation, a configuration file should be created. So, I created this config file in the ~/.config/vdirsyncer directory:

status_path = "~/.local/share/vdirsyncer/status/"

[pair nc_myusername_caldav]
a = "nc_myusername_caldav_local"
b = "nc_myusername_caldav_remote"
collections = ["from a", "from b"]
metadata = ["color"]
conflict_resolution = "b wins"

[storage nc_myusername_caldav_local]
type = "singlefile"
path = "~/.local/share/vdirsyncer/caldav/myusername/%s.ics"

[storage nc_myusername_caldav_remote]
type = "caldav"
url = ""
username = "myusername"
password.fetch = ["command", "keyring", "-b", "keyring.backends.kwallet.DBusKeyring", "get", "Nextcloud", "myusername:"]

So, in the configuration file, I defined two storages:

  • nc_myusername_caldav_local, the local iCalendar file that Calindori will “consume” and the
  • nc_myusername_caldav_remote, the Nextcloud personal calendar.

The pair nc_myusername_caldav section makes Vdirsyncer synchronize the calendar storages bidirectionally. In case of a conflict -an event or task has changed on both sides since the last sync- I opted for the conflict to be resolved in favor of the remote storage.

With regards to authentication to Nextcloud for user myusername, keyring has been used in order to access the kwallet subsystem via D-Bus.

KDE Wallet KDE Wallet Nextcloud entry

This approach works perfectly for me since various passwords that I daily use have been stored in the kwallet which is opened just after logging in to my user session. If this approach does not fit your needs, there are various alternatives.

Then, after creating the ~/.local/share/vdirsyncer/caldav/myusername directory and running:

vdirsyncer discover
vdirsyncer sync

an iCalendar file will be created and populated with your Nextcloud tasks and events.

The next step is to synchronize automatically at certain intervals. So, if you

  • download vdirsyncer.service and vdirsyncer.timer
  • put them into ~/.local/share/systemd/user
  • activate and run the timer
    systemctl --user enable vdirsyncer.timer
    systemctl --user start vdirsyncer.timer

the Nextcloud calendar will be synchronized every 15 minutes.

Finally, we need to let Calindori know about the Nextcloud calendar. The process is straight forward: navigate to Settings > External > Add and add the Vdirsyncer calendar file. From now on, the tasks and events that are created either on Calindori or Nextcloud side are going to be synchronized between each other.

Add external calendar Add an external calendar

Finally, let me clarify that this approach is not the way that Calindori and Plasma Mobile are going to offer online synchronization of calendars in the future. Nevertheless, Vdirsyncer is a nice, simple utility that enable users to use Nextcloud calendars in Calindori at the moment. It has worked pretty well for me, and I think that the Linux-on-mobile community will find it as an interesting solution for calendar synchronization.

A few years ago I read a fascinating article about the cycle of how subcultures grow, mature, and die. The whole thing is worth a read (as well as the whole site), but here’s the abridged version:

  1. Creators invent something new and cool, attracting fanatics who validate them and help spread it around. These people are the “Geeks.” I would guess that most current users of KDE software are in or near this group.
  2. The coolness attracts “Mops”–normal people who want to enjoy the cool thing with minimal effort or investment. They dilute the coolness by demanding that it be simplified, sanitized, and mainstreamed for them. In KDE terms, these people would be our non-technical friends and relatives.
  3. At this point, the Geeks may start to quit because the coolness has been destroyed by the Mops. However sometimes the Geeks realize that Mops are key to expanding the cool thing even further.
  4. At this point Sociopaths will appear–people who participate in a system for the money or power games. They figure out how to monetize the Mops, allowing some Geeks to go pro and create the cool thing full time.
  5. Sociopaths increasingly exploit both the Geeks and the Mops, because they’re in it for the money and social power.
  6. The Geeks increasingly burn out because they’re spending their time unpleasantly interacting with exploitative Sociopaths and compromising their original vision to placate demanding Mops who provide their income.

I’m old enough that I’ve started to notice this cycle play out in various hobbies, subcultures, and even commercial companies I’ve been involved with: they start out small and cool, but along the way, mainstreaming and commercialization seem to corrupt everything.

I’ve also noticed that many FOSS projects seem to avoid this cycle and the dark fate at the end. Not all do, but some seem to. Why? How?

How FOSS helps

In the FOSS world, Mops are not easily monetized. The product is given away for free, after all! Only mildly Geeky Mops will be attracted, and the more entitled mainstream Mops can be told to pound sand when they start to demand more. They didn’t pay anything, so they’re not entitled to anything.

As a result, many FOSS projects are able to preserve their stable niche status because they explicitly reject a strong Mop appeal, limiting the attractiveness for Sociopaths. To tie this fairly theoretical discussion back to the software world a bit, Arch Linux is a good example: not having an installer acts as a gate to keep out low-investment Mops, ensuring that the project remains safely in the hands of the Geeks.

However this kind of gatekeeping–intentional or not–has a drawback: if the gate is too strong, the project may shrink over time as the original Geeks get bored or driven away by internal politics. Because the pool of Geeks is fairly limited, Geek-only growth largely involves poaching from other Geek projects; it’s a zero sum game.

What to do? Is it really a matter of keeping out the Mops and staying small, or letting them in and burning out after growing huge? And how am I able to reconcile knowledge of this cycle with my stated goal to get KDE Plasma onto every computing device on planet Earth? Earthlings are mostly Mops, after all.

How KDE can do it

Well first of all, I acknowledge that my goal is more aspirational than realistic. 🙂 Better to shoot for the moon and fall short, I think. I’d be pretty happy if we get Plasma to 15% global market share. That’s enough to be a major player with a direct and ongoing positive impact on human civilization.

Anyway, here’s how I think KDE can avoid the cycle, and grow powerful without being corrupted:

Attract all the Geeks

You may notice how many sysadmins, software devs, and general nerds have Apple computers outside of the FOSS world. In the early 2000s, Apple attracted a huge number of Geeks by pairing support for power-user workflows with an attractive user interface and high reliability. This was the “It Just Works” factor, for people who were doing work. It allowed Apple’s ecosystem to maintain a favorable Geek-to-Mop ratio, at least until the iPhone took off. KDE can realistically follow this path as well. I myself am a former Apple nerd. We can convert them. And the more Geeks KDE has, the more engineering talent it will accumulate, and the more Mops it can safely support.

Minimize the project’s reliance on Mop money

This avoids creating a financial incentive to dilute the product, and it reduces the project’s appeal to Sociopaths (at least, the ones who are attracted to money). KDE already has this pretty well covered, because we don’t sell products directly to consumers for money–with the exception of Krita on the Windows store (to my knowledge), and even then there are simple ways to get Krita for free if you want. The existence of a free version is a pressure valve.

Preserve the KDE community’s gravitational center for development

Today KDE benefits from outside companies paying people to work on KDE who are benevolent: Blue Systems (my employer), Enioka Haute Couture, KDAB, SUSE, the city of Munich, and various others. But it won’t always be this way as KDE rises in importance.

Large companies with little exposure to the FOSS world, but who use or sell products with KDE software, will want to hire their own engineers to contribute to KDE so they don’t feel like they’re shut out of the development of a product that significantly affects them. If enough of this happens outside of KDE itself, we run the risk of the project being taken over by sheer weight of outside contributions by large companies.

This is why I feel so strongly that the KDE e.V. should start hiring community members for technical roles. With the KDE community itself clearly in charge of the gravitational center of paid engineering, these outside companies would find it more convenient to simply pay money to the e.V. to strengthen those development efforts, join a sort of technical advisory board, or pay for priority access to engineering resources to fix bugs affecting them (not features, only bugs). These could give those companies the the “seat at the table” that they’re looking for while keeping technical decision-making firmly in the hands of the community. The project would be able to remain independent more easily.

It’s not a problem we urgently need to solve right now, but it will be in the future if we’re as successful as I want us to be. I think it behooves us to do it now rather than later.

Hire Geeks, not Mops

Whenever someone is paid to work on KDE stuff–either by the KDE e.V. or anyone else–always prioritize hiring KDE community members over outsiders. There’s always the risk that the outsider is a Mop who just wants a paycheck rather that someone who truly believes in KDE. Those with the privilege of being paid to work on KDE stuff should be people who go above and beyond because they love it.

Foster a culture of resistance to Sociopathy

KDE will probably never be an institution where you can get rich quick, and I see this as a good thing. But not all Sociopaths are in it for the money; some crave power. An important project like KDE will still hold appeal for the type of Sociopath who wants to push everyone around as the king of a little digital fiefdom. We need to keep these people out.

Unfortunately, while Geeks are generally good at noticing when Sociopaths show up, they are generally terrible at kicking them out. Geeks can be conflict-averse, or believe that the Sociopaths can be reasoned with, reformed, or safely tolerated because they do some good work. They cannot be.

KDE needs to maintain and expand a culture of resistance to Sociopathy by teaching its members to harden themselves against Sociopaths and and use some of their own tactics against them when they show up. Nobody should be the king of KDE. KDE should not have a king! Central leadership is a risk factor, as I blogged about earlier.

What it all looks like

KDE will attract as many Geeks as possible through our continued commitment to technical excellence and supporting power user workflows in our software. We minimize the risk of demanding Mops burning everyone out by not selling anything to them directly and maintaining a favorable Geek:Mop ratio through our attraction of lots of Geeks. We start paying for engineering talent, but we hire insider Geeks, not outsider Mops. And we do it within KDE itself. Then we remain vigilant for Sociopaths craving power, and we kick them out so that KDE can remain a safe place for the Geeks.

So who’s ready to take over the world with love and positivity and user-empowering high quality software?


29 December, 2020

One of the biggest disadvantages of static site generators is that they are static and can’t include comments.

There are multiples solutions to solve this problem. You could add a third party blog engine like Disqus, but this has the drawback of including a third-party tool with a bad privacy record in your website. Another solution would be to host an open-source alternative but this comes at the cost of a higher maintenance burden. Having to host a database was something we wanted to avoid with a static site generator.

In my opinion, a better solution is to leverage the Mastodon and Fediverse platform. Mastodon is a decentralized social network and it allows people to communicate with each other without being on the same server. It is inspired by Twitter, but instead of tweeting, you write toot.

When publishing an article, you now only need to also write a simple toot linking to your article. Then Mastodon has a simple API to fetch the answer to your toot. This is the code I made for my Hugo powered blog, but it is easily adaptable for other static site generators. It will create a button to load comments instead of loading them for every visitor so that it decreases the load on your mastodon server.

{{ with .Params.comments }}
<div class="article-content">
  <p>You can use your Mastodon account to reply to this <a class="link" href="https://{{ .host }}/@{{ .username }}/{{ .id }}">post</a>.</p>
  <p><a class="button" href="https://{{ .host }}/interact/{{ .id }}?type=reply">Reply</a></p>
  <p id="mastodon-comments-list"><button id="load-comment">Load comments</button></p>
  <noscript><p>You need JavaScript to view the comments.</p></noscript>
  <script src="/assets/js/purify.min.js"></script>
  <script type="text/javascript">
    function escapeHtml(unsafe) {
      return unsafe
           .replace(/&/g, "&amp;")
           .replace(/</g, "&lt;")
           .replace(/>/g, "&gt;")
           .replace(/"/g, "&quot;")
           .replace(/'/g, "&#039;");

    document.getElementById("load-comment").addEventListener("click", function() {
      document.getElementById("load-comment").innerHTML = "Loading";
      fetch('https://{{ .host }}/api/v1/statuses/{{ .id }}/context')
        .then(function(response) {
          return response.json();
        .then(function(data) {
          if(data['descendants'] &&
             Array.isArray(data['descendants']) && 
            data['descendants'].length > 0) {
              document.getElementById('mastodon-comments-list').innerHTML = "";
              data['descendants'].forEach(function(reply) {
                reply.account.display_name = escapeHtml(reply.account.display_name);
                reply.account.emojis.forEach(emoji => {
                  reply.account.display_name = reply.account.display_name.replace(`:${emoji.shortcode}:`,
                    `<img src="${escapeHtml(emoji.static_url)}" alt="Emoji ${emoji.shortcode}" height="20" width="20" />`);
                mastodonComment =
                  `<div class="mastodon-comment">
                     <div class="avatar">
                       <img src="${escapeHtml(reply.account.avatar_static)}" height=60 width=60 alt="">
                     <div class="content">
                       <div class="author">
                         <a href="${reply.account.url}" rel="nofollow">
                           <span class="disabled">${escapeHtml(reply.account.acct)}</span>
                         <a class="date" href="${reply.uri}" rel="nofollow">
                           ${reply.created_at.substr(0, 10)}
                       <div class="mastodon-comment-content">${reply.content}</div> 
                document.getElementById('mastodon-comments-list').appendChild(DOMPurify.sanitize(mastodonComment, {'RETURN_DOM_FRAGMENT': true}));
          } else {
            document.getElementById('mastodon-comments-list').innerHTML = "<p>Not comments found</p>";
{{ end }}

This code is using DOMPurify to sanitize the input, since it is not a great idea to load data from third party sources without sanitizing them first. Also thanks to chrismorgan, the code was optimized and is more secure.

In my blog post, I can now add the following information to my frontmatter, to make comments appears magically.

  username: carl
  id: 105105837504372590