Skip to content

Welcome to Planet KDE

This is a feed aggregator that collects what the contributors to the KDE community are writing on their respective blogs, in different languages

Saturday, 23 September 2023

Last weekend I attended this year’s Nextcloud conference in Berlin, together with a few other fellow KDE contributors.

Nextcloud Itinerary integration

My main involvement with Nextcloud so far has been the integration with KDE Itinerary. While this generally works fine, it’s not ideal yet when it comes to continuously getting updates of the travel document extractor to Nextcloud users.

Nextcloud uses this in form of a statically built executable, going back to the initial prototype still using ad hoc builds of that executable. Meanwhile we have this implemented on KDE’s Gitlab CI, which should give us more reliable and reproducible results. What’s still missing though is feeding this into the corresponding Nextcloud package more or less automatically for every release, either from our Gitlab job, or by running the same job in Nextclouds Github setup.

Virtual file system API for cloud syncing clients

There is demand for Linux getting an equivalent to the virtual file system APIs other platforms offer for cloud syncing clients, so that all file dialogs or file managers can see the remote file trees even if not fully synchronized locally and request a file of interest to be synchronized on demand.

It came up for the Nextcloud Linux desktop client here, I have heard the same from ownCloud before, KDE wants this and I’m sure so does GNOME. It might be possible to implement this using environment-specific APIs such as a KIO or GVfs, but this doesn’t scale.

This looks like something where a FreeDesktop/XDG standardized API would make sense, so that each syncing client has to only implement that to support all Linux environments (ideally without much extra code, given similar logic is needed for other platforms already), and where KDE/GNOME/etc would gain support for all kinds of cloud file storage system by supporting that API.

Push notifications for CalDAV/CardDAV

Probably the biggest surprise for me was the DAVx⁵ team presenting their work on adding push support to the CalDAV/CardDAV protocols. This would allow e.g. changes to calendar events becoming instantly available on all your devices, while saving energy by needing a lot less polling. This might also then allow things like synchronized reminder states across multiple devices.

Technically this nicely ties in with our existing CalDAV/CardDAV connectors in KDE PIM and the work on integrating push notifications using UnifiedPush, and thus should hopefully be easy for us to add once this becomes available in servers.

For more details see the WebDAV Push Matrix room and the corresponding Github project.

Too much “AI” hype

The “AI” topic was a bit over-hyped for my taste, like in many other places as well. While things like the ethical AI rating or the focus on getting things to run locally address important problems, the features as such and their consequences weren’t questioned much. And how people can consider “AI” as a tool to solve the climate crises is beyond me.

An interesting point raised in the discussions was how to mark machine generated content. This might not even always be obvious to the direct user, and people the output is shared with have even less of a chance to assess this. And this already matters for relatively uncontroversial uses like machine translations.

As an example, some time ago I was confronted with some questionable statements I had supposedly made on the Internet (in German). Being relatively sure I hadn’t said that I was pointed to my own website as the source. With all content here being in English though it eventually turned out that the person was using some automatic translation feature in their browser without even realizing that. It worked mostly fine so this went unnoticed for quite some time, up to the point where it failed and the failure then was attributed to me instead.

Responsible use of such technology requires transparency.

Political work

Two particular highlights for me were Max Schrems and Simon Phipps presenting about their respective work on fixing EU regulations. It’s quite encouraging to see that this isn’t out of reach for “us” (ie. the wider community that shares our ideas and values around free and open source software and privacy), and that the way of influencing this has become much more professional and effective in the recent years, with many organization coordinating, building relations and sharing the work on lobbying “political communication”.

I’m happy that KDE is associated with two organizations doing good work there, FSFE and OSI, but we could probably do more still, on the EU level, the regional/national level in the EU and of course outside of the EU as well, be it through throwing out weight behind allies or by being present in stakeholder hearings ourselves.

Though the number of total Plasma 6 known issues rose this week, we managed to fix some major and longstanding ones from Plasma 5! You might recognize a few in the text below. Ultimately, these were deemed more pressing than the comparatively minor new ones. We’ll be continuing to hammer those bugs, but we do need help–your help! Discovering bugs is important, but so is fixing them, and we need help to get it done.

Plasma 6

General infoOpen issues: 90

Fixed the infamous issue of Panels visually freezing in the Plasma Wayland session when using a non-Intel GPU in conjunction with the Basic QtQuick render loop and Task Manager previews turned on (David Edmundson et al, link)

Searching for apps, System Settings pages, and other things classified internally as “services” in KRunner and other KRunner-powered search tools (such as Kickoff) now matches English text as well when using the system in a language that’s not English (Alexander Lohnau, link)

When using a single-row Icons-Only Task Manager, the last opened task on the row is no longer sometimes missing under certain circumstances (Marco Martin, Link)

Fixed a bug that could cause auto-started apps with System Tray icons to sometimes not show their System Tray icons as expected until manually quit and re-launched (David Edmundson, link)

Fixed various cursor glitches and brokenness when using rotated screens in the Plasma Wayland session on a GPU that supports hardware cursors (Xaver Hugl, link)

The “Manually block sleep and screen locking” switches of multiple Battery and Brightness widgets are now synchronized; when one is toggled, all of them will change as well (Natalie Clarius, link)

Repeated messages on the lock screen now do a little bounce, rather than piling up and repeating themselves (me: Nate Graham, link):

Reduced resource usage in QtQuick apps that have mnemonics–those little underlines below letters when you hold down the Alt key (Kai Uwe Broulik, link 1 and link 2)

The menu item that says “Enter Exit Mode” now changes to “Exit Edit Mode” when you’re already in Edit Mode (me: Nate Graham, link)

The Kirigami.BasicListItem component has been deprecated with a planned removal in KF6, because it was too slow, heavy, and inflexible, worsening performance in QtQuick apps that used a lot of them. In its place are a new set of lightweight components that are thin wrappers around the standard Qt ItemDelegate, CheckDelegate etc. components, plus some more basic building blocks for making custom list items. This provides most of the convenience of BasicListItem, without the performance overhead (Arjen Hiemstra, link)

Other Significant Bugfixes

(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)

Gwenview now displays images more correctly when using a fractional scale factor in the Plasma Wayland session (Kai Uwe Broulik, Gwenview 24.02. link)

Fixed multiple bugs in Elisa that could cause odd and incorrect behavior when you re-arrange the contents of the playlist around the currently-playing song (Jack Hill, Elisa 24.02. Link)

Filelight once again respects the settings regarding folders exclusions and filesystem boundaries (Yifan Zhu, Filelight 23.08.2. Link)

When closing a document in Kate and KWrite that has unsaved changes, you’ll no longer see two dialogs asking you if you want to save them (Kai Uwe Broulik, Kate and KWrite 23.08.2. Link)

Widgets using the standard Plasma Calendar integration will no longer sometimes display holidays from the default region, rather than the selected one (Eugene Popov, Plasma 5.27.9. Link)

Other bug-related information of interest:

Automation & Systematization

Added some autotests for MPRIS media playback global shortcuts (Fushan Wen, link 1 and link 2)

…And everything else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Plasma 6 is usable for daily driving now, but still in need of bugfixing and polishing to get it into a releasable state by the end of the year.

Otherwise, visit to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!

Friday, 22 September 2023

With user edition out the door last week, this week was spent stabilizing unstable!

Spent some time sorting out our Calamares installer being quite grumpy which is now fixed by reverting an upstream change. Unstable and developer ISO rebuilt and installable. Spent some time sorting out some issues with using an unreleased appstream ( thanks ximion for help with packagekit! ) KDE applications are starting to switch to Qt6 in master this week, the big one being KDE PIM! This entails an enormous amount of work re-packaging. I have made a dent, sorta. To be continued next week. I fixed our signond / kaccounts line for qt6 which entailed some work on upstream code that uses QStringList.toSet which was removed in Qt6! Always learning new things!

I have spent some time working on the KF6 content snap, working with Jarred to make sure his qt6 content snap will work for us. Unfortunately, I do not have much time for this as I must make money to survive, donations help free up time for this 🙂 Our new proposal with Kevin’s super awesome management company has been submitted and we will hopefully hear back next week.

Thanks for stopping by! Till next week.

If you can spare some change, consider a donation

Thank you!

Let’s go for my web review for the week 2023-38.

Unity’s New Pricing: A Wake-up Call on the Importance of Open Source in Gaming – Ramatak Inc.

Tags: tech, 3d, foss, gaming, business, licensing

Unsurprisingly after people massively converged to two main closed source engines for their games, they start to be massively screwed over. Maybe it’s time for them to finally turn to Free Software alternatives?

Your New Apple Watch Series 9 Won’t Be Carbon Neutral | WIRED

Tags: tech, apple, ecology

Sure they’re pulling some effort on the way their hardware is produced and cheap. But don’t be fooled by the grand claims, this can’t be carbon neutral.

We Are Retroactively Dropping the iPhone’s Repairability Score | iFixit News

Tags: tech, apple, ecology, repair

What are the hardware improvements good for if it’s all locked down through software? This is wasted.

Organic Maps: An Open-Source Maps App That Doesn’t Suck

Tags: tech, map, foss

Interesting review, this seems mostly aligned with my own experience. That said I got less mileage since I use it mostly when walking around places I don’t know well.

Long-term support for Linux kernel to be cut as maintainence remains under strain

Tags: tech, linux, kernel, community

Interesting, the situation for kernel maintainers is actually harder than I thought. You’d expect more of them could do the maintainer job on work time… - Matrix 2.0: The Future of Matrix

Tags: tech, messaging, matrix

Lots of progress, they’re finally delivering on past announcements at FOSDEM it seems. Let’s hope the spec effort catches up though.

This month in Servo: upcoming events, new browser UI, and more! - Servo, the embeddable, independent, memory-safe, modular, parallel web rendering engine

Tags: tech, web, servo, rust

Nice to see this effort keeps bearing fruits. This is a very needed engine to avoid a monoculture.

Should I Rust or should I go?

Tags: tech, rust

Keep the downsides in mind. Rust has an ecological niche, but it’s maybe not that big.

Supply Chain Issues in PyPI - by Stian Kristoffersen

Tags: tech, python, supply-chain

There’s still some work to secure the Python supply chain. It’s clearly suffering from fragmentation and ambiguous data.

Java 21 makes me actually like Java again - WSCP’s blog

Tags: tech, java, type-systems

This is definitely a big deal for the Java type system and its ergonomics.

Java 21 Is Available Today, And It’s Quite The Update | Today

Tags: tech, programming, java

This is definitely a big release! Lots of changes and improvements in this language.

Monkey-patching in Java

Tags: tech, java, metaprogramming

Lots of possibilities in the JVM to monkey-patch some behavior. Most of them are a bit involved though.

SQL join flavors

Tags: tech, sql, databases

Everything you wanted to know about SQL joins, and more.

B612 – The font family

Tags: tech, fonts

Interesting free font. Made for aeronautics, but brings interesting properties which might be useful in other contexts as well. Created around Toulouse and my old University too!

The Frustration Loop | ᕕ( ᐛ )ᕗ Herman’s blog

Tags: tech, spam, blog, funny

This is a funny spammer deterrent. I like the idea.

1 Trick to Finish Your Next Talk in Style - David Nihill

Tags: communication, talk, presentation

Interesting trick indeed. I’ll try this when I get the chance. Clearly this avoids the underwhelming atmosphere closing after most Q&A session.

Bye for now!

Wednesday, 20 September 2023

Hello and welcome back to my blog! In this blog, I will be detailing the work I've done over the second coding period of my 2023 GSoC journey with KDE. Let's dive in!

Work done

Over the second coding period, I accomplished the following tasks:

Fix Okular Icon Rendering

Okular's Android app was not rendering the icons at all. At first, I thought that it might be an issue with the icons not being packaged. I tested out this theory, by exploring the contents of Okular's apk file. Inside the APK was a .qrc file, which I decompiled using a tool recommended to me in the KDE Android matrix room. Upon exploring the contents of the .qrc file, I found that all the icons were already packaged there. If I used the icons with their full paths in the qrc file instead of their freedesktop name (i.e. qrc:/path/to/document-open.svg instead of just document-open), the icon would show up properly in the app. I concluded that the issue was not due to faulty packaging of icons, but Kirigami not being able to find the proper icons.

Over the next week, I spent a large amount of time desperately trying to pick apart Okular and find the faulty bit of code that was causing the icons not to display. As I grew increasingly frustrated, I turned to the KDE android matrix room to ask for help.

They suggested that the KIconThemes library was causing issues just by being present, due to this line of code that executes any time the Okular app started up. What it does is, it automatically configures the app to use the breeze theme as a fallback. This was interfering with Kirigami's icon-finding mechanism, causing the icons to not show up.

Initially, I just removed KIconThemes as a dependency from Okular's CMakeLists.txt, but that didn't work. A couple of days later, several developers from the KDE Android matrix room pointed out that even though KIconThemes was removed, it was still being packaged with Okular by craft. They suggested that I wrap the offending code within a conditional compilation block so that Android would not execute it automatically.

I followed their advice, and it worked like a charm - Okular was finally displaying the icons properly.

I then created a Merge Request at the KIconThemes repository to implement the fix for the icons issue.

Peruse, another KDE application, was also having similar issues with icons as Okular. The fix also helped it to render icons properly.

Package Okular Icon

After fixing icon rendering, I added the Okular icon to the CMakeLists.txt for Okular's Android version, which would package it along with the other icons. This was needed because two places in the Okular app use icons:

  • The global drawer

  • The About Page

These places were empty when they should've been displaying the Okular logo, as can be seen here:

After adding the Okular icon to the kirigami_package_breeze_icons() array, you can now see the Okular icon in its glory in the global drawer and about page.

However, I did run into some footgun moments with craft while performing this task. This is because to test changes in Okular, I had always run the following craft commands to build and package it as an APK:

craft --compile okular
craft --package okular

However, icons are a special case. If you add a new icon, it has to be installed and qmerged as well. You do that by:

craft --compile --install --qmerge okular
craft --package okular

I spent a couple days trying to figure out what was wrong due to this small mistake. I only realized what was happening when I took a closer look at the output when freshly installing Okular using craft -i okular.

The members of the KDE Android Matrix room suggested that I edit the wiki page for Craft so that other people can avoid being plagued by this small mistake.

Moving from Kirigami.AboutPage to MobileForm.AboutPage

While adding the Okular icon to the app, I also came across MobileForm.AboutPage, which is an experimental feature from Kirigami Addons that changes the layout of the About page from Kirigami.AboutPage. I asked my mentor if we should move to MobileForm.AboutPage since it looks better and more modern, and he agreed. So I replaced Kirigami.AboutPage with MobileForm.AboutPage in this merge request.

Here's how the Kirigami.AboutPage looks in Okular:

Here's how the new MobileForm.AboutPage looks in Okular:

Porting to FormCard from MobileForm

Shortly after I had moved Okular to using MobileForm.AboutPage, Kirigami Addons renamed MobileForm to FormCard. The MobileForm QML import would still be available but it would not receive new features. The new FormCard will receive new improvements, so it is advised to switch to it. This blog post by Carl Schwan explains it in more detail. So I ported Okular to the new FormCard API in this merge request.

FormCard.AboutPage has a few subtle differences from MobileForm.AboutPage. Here's how it looks like:

Fix qtbase Crash/Hang in Okular

Sometime around the start of the first coding period, I noticed that Okular on my phone would freeze on a black screen when attempting to open PDFs in it. I initially worked around this running Okular in the Android emulator packaged with Android Studio.

However, since I had some more free time during the second coding period, my mentor and I decided to tackle this issue. The issue seemed to be device specific, and only a couple of the phones I tested Okular on had this issue.

I distinctly remembered that an older version of the Okular apk was running properly on my device, without freezing/crashing to a black screen whenever I attempted to open a PDF. Luckily I was able to find an old APK from my phone backups, and confirm this.

This older APK was v22.12.3 of Okular, with Qt 5.15.8, and KDE Frameworks 103.0. The newer APK with the black screen issue was release/23.04 of Okular, with Qt 5.15.10 and KDE Frameworks 108.0.

My mentor suggested downgrading Okular to version 22.12.3 and testing it. The app still crashed, so my mentor suggested that Qt itself might be causing issues, and so I compiled Qt 5.15.8 in Craft and testing Okular by building against it. It worked fine, and opened PDFs properly. After this I did the same with Qt 5.15.9, which displayed the black screen issue in Okular.

So far we had deduced that the issue occurred sometime between Qt version 5.15.8, and 5.15.9. To narrow down the search, my mentor then shared a list of commits which were applied between Qt 5.15.8 and 5.15.9, and were related to Android.

Immediately I noticed that when running Okular on Android, adb logcat would have some warning messages from Qt A11Y. During testing, I had also noticed that in the tombstone file generated by Okular crashing during the black screen, the stacktrace indicated that Qt was doing some threading-related stuff and also executing Qt A11Y code.

In the list of commits shared by my mentor, you will notice that commit 513fcf0d2ad3328830dbf73dc2a55ad1487393c0 deals with Qt A11Y and threading both, so this commit stood out to me. My suspicions turned out to be correct - when I checked out the commit in git, Okular was freezing/crashing as usual, but when I checkoud out the commit immediately before it, Okular was working fine.

I shared this information with my mentor, and he looked up some commits from qt6 that seemed related:




To test these patches, I backported them using git cherry-pick, rebuilt Qt, and the rebuilt Okular.

After a bit of testing, I saw that the commit ac984bd8768b3d7e6439e0ffd98fd8b53e16b922 completely solved the issue of black screening when opening a PDF on Okular. Out of the 2 devices I tested this on, both no longer displayed any issues with this commit.

My mentor suggested that I send these patches to the kde/5.15 branch of qtbase at KDE's qtbase repository by following this guide:

I followed the instructions given in the page - I cherry picked the commit to the kde/5.15 branch of qtbase, and opened a merge request on the kde/5.15 branch of KDE's qtbase repository.

Challenges faced

Getting used to Craft's system:

Craft is an open source meta build system and package manager. It manages dependencies and builds libraries and applications from source, on Windows, Mac, Linux, FreeBSD and Android.

In order to work with Okular, I had to get used to Craft. As a beginner who just learnt CMake over the course of GSoC, learning to use Craft took quite a bit of effort. The first few steps were a breeze, thanks to the KDE wiki page about Craft and also because I had worked with Craft during the first coding period.

However, Craft keeps bumping up versions of software such as KDE Frameworks, Qt, etc. every once in a while. This can make it tough to test out older versions of such software. In my personal experience, I had to mess around in Craft's version.ini files for Qt5, located at /CraftRoot/etc/blueprints/locations/craft-blueprints-kde/libs/qt5.

Building Qt in craft - binutils

While trying to build applications and libraries in craft, I frequently ran into errors about the GNU binutils not being able to recognize the file format of the compiled files. I usually bypassed these by setting the $PATH variable to point to the GNU binutils built for Android, usually located at /home/user/CraftRoot/tmp/android-24-toolchain/arm-linux-androideabi/bin. Now keep in mind that I have only encountered this issue when building for arm32 devices, it could be entirely possible that it builds just fine when building for arm64 android devices.

However, that's not all - I encountered this issue again when building Qt for arm32 Android inside the Craft environment. For example, when building qtbase, I got the following error when using the default toolchain.

/opt/android-sdk/ndk/22.1.7171670/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy:/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9/bin/qmake: File format not recognized
Command ['/opt/android-sdk/ndk/22.1.7171670/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy', '--only-keep-debug', '/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9/bin/qmake', '/home/user/CraftRoot/build/libs/qt5/qtbase/image-MinSizeRel-5.15.9-dbg/bin/qmake.debug'] failed with exit code 1
Action: install for libs/qt5/qtbase:5.15.9-1 FAILED

In this case, simply setting the $PATH variable did not work, I had to improvise and use the Xamarin android toolchain as it was more up to date, and add it to $PATH inside the Craft docker container. However, this toolchain generated much larger APK sizes, jumping from a modest 56 MB to 110 MB.

Maybe in the future I could try creating a Craft package for GNU binutils for Android, which would minimize, or at least reduce the frequency of running into problems like this. No promises though! :P

Debugging in Android

This has been mentioned in my previous blog post already, but Android's way of handling permissions made debugging a headache. Initially I rooted my Android phone and used gdbserver to try and get debugging going, but it eventually ended with me giving up and resorting to staring at ADB logcat and trying to make Okular crash so that it would produce a tombstone file. While this approach did lead me to success with solving the black screen issue, it would have been nice to have some good debugging infrastructure.

Remaining Work

While this GSoC coding period was useful to fix some of Okular's issues as well as improve it a bit, there is still some remaining work that would go a long way for Okular to be considered an attractive PDF reader on Android:

Adding a "recent documents" section

Okular on desktop has a list of documents that were recently opened by the user. This allows the user to quickly re-open documents that they frequently access, and consequently speeds up their workflow as well as being much more usable. However, Okular on Android lacks this feature, and it would go a long way to make Okular a more attractive PDF viewer.

Adding the ability to jump to a specific page number

Okular on Android has no support for jumping to a specific page number of a PDF. This can be tedious for example in large documents with hundreds of pages.

Fixing bookmarks

At the moment, bookmarked pages do not show up in the bookmarks tab, as the bookmarks tab of the side drawer cannot be accessed as it is grayed out.

What now?

This GSoC journey has been an enjoyable learning experience for me. In the future, I'd like to contribute to KDE again, no matter if its through GSoC or not.

I'll most likely try to contribute to KDE and other FOSS projects whenever I have free time, and help those projects to improve, while improving my skills at the same time.

Wrapping it up

This GSoC has been a valuable and unforgettable experience into the world of Open Source Software. Not only did I get to learn the process for contributing to open-source and hone my own skills, I was also able to contribute to KDE, one of my favorite FOSS projects.

I'm thankful to my mentor Albert Astals Cid for his patience and guidance, which undoubtedly helped me overcome many of the obstacles in my journey.

I'd also grateful for the KDE Community, especially the members of the KDE Android Matrix room - they helped me to fix the Okular icon rendering, and without their help I might have still been bashing my head trying to solve it.

That's all for now. See you next time, and have a nice day! :D

Tuesday, 19 September 2023

San Miguel De La Palma is my home island. Most people simply refer to it as La Palma. Located in the Canary Islands, this has always been the place for me to recharge, for sharing time with friends and family. My friends there have lives different from mine. My family too. They live slower, they … Continue reading Meetup group related with technology in San Miguel De La Palma: next steps

Monday, 18 September 2023

The first maintenance release of the 23.08 series is out:


  • Fix audio channel setting breaking opening of existing project file. Commit.
  • Fix possible crash in audiolevel widget. Commit.
  • Fix default audio channels for project not correctly saved. Commit.
  • Fix guide/marker categories all black on some non english locales. Commit.
  • Ensure Media browser saves zoom level when using mouse wheel to zoom. Commit.
  • Extract audio: export only active streams, merge all if requested. Commit.
  • Fix crash on subclip transcoding. Commit.
  • Fix audio extract for multi stream clips. Commit.
  • When restoring audio or video component in timeline, first try target track, then mirror track. Commit.
  • Fix multi guide export enabled by default. Commit.
  • Fix guides categories all black when opening a project from a different locale. Commit.
  • Fix archiving crash on Windows caused by filesystem case sensitivity. Commit.
  • Project Bin: don’t draw icon frame if icon size is null. Commit.
  • Fix zone rendering not remembered when reopening a project. Commit.
  • Fix detection/fixing when several clips in the project use the same file. Commit.
  • Correctly update guides list when switching timeline tab. Commit.

The post Kdenlive 23.08.1 released appeared first on Kdenlive.

Sunday, 17 September 2023

Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately.

So today, let’s talk about it!

What is Wayland?

Wayland is a set of protocols that govern how a compositor draws stuff on the screen, and how apps interact with the compositor’s drawing-stuff-on-the-screen infrastructure. It’s similar to the HTTP and SMTP protocols that govern how web browsers and email clients send and receive web pages and data.

Wayland also includes an implementation of those protocols in a set of extremely lightweight libraries called libwayland-client and libwayland-server that offer stable and versioned APIs. Apps and compositors such as KDE’s KWin and GNOME’s Mutter use those APIs to do stuff.

Why does Wayland exist?

In a nutshell, because X11–the thing it’s replacing–is dead.

X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world.

Why did X die?

The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.

But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.

In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well.

How is Wayland any better?

Wayland was conceived of by X developers who wanted to avoid repeating their own mistakes. In addition to a lot of technical differences, by being a minimal set of protocols and two extremely thin client and server libraries, all the heavy lifting was delegated to individual compositors, which became the window servers of their environments. A new feature added to one would not destabilize any other compositors. Compositors were also free to implement new features via private protocols outside of the standard ones that apps only targeting that compositor could use.

Wait, that sounds like it sucks

Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work–such as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on. Compositors all needed to come up with ways to do these things themselves. And that need for each compositor to implement everything itself fragments development efforts and disadvantages small teams without the expertise of heavy-hitting graphics developers. These are real problems and we shouldn’t sweep them under the rug.

Yes, but there are solutions

Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.

In addition, the problem of fragmentation of effort is being solved by wlroots, a library of Wayland implementations that you can use to build a Wayland compositor. We don’t use it in KDE’s KWin compositor because we already did most of that work ourselves before wlroots existed, but it’s a big benefit to anyone writing a new compositor from scratch today. And there’s a chance we might port KWin to use wlroots in the future.

Why is the adoption taking so long?

The fact that Wayland’s minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008. We didn’t see the same problem with other newer projects like Systemd and PipeWire which were adopted much faster.

And unfortunately, shepherding new protocols through the approval process to fix this problem is a grueling political exercise. It demands empathy and compromise with people from other projects who approach the problem you’re trying to solve from a fundamentally different perspective. Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. For a long time, the urgency of pushing through it was low because X wasn’t dead yet.

So it took over a 15 years and resulted in Wayland’s dirty laundry being aired in public for that whole time. And that sucks. But… we’re there now. Standard protocols now exist for just about everything anyone needs. The few remaining obvious omissions (like screen color calibration) are being actively worked on as a matter of priority.

“Are we there yet?”

Plasma and KDE apps work great on Wayland, especially in the upcoming Plasma 6 release. Like I said, there are still a few omissions, but those holes are being plugged very quickly these days.

Most 3rd-party apps that aren’t Wayland-native also work fine via the XWayland compatibility layer. But there are some that don’t, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland. That’s understandable. But this time it’s for real, and the time to port is now. For any protocols that still aren’t good enough and need revision, app developers’ input is needed to revise them or even propose new ones. This process takes a long time, so better to start sooner rather than later. But it’s not just gonna go away.

Which brings us to Fedora KDE

Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.

It should be clear that Fedora’s target audience consists of people who are excited about change. If this is you, all of these projects should seem exciting and cool! If not… then Fedora isn’t for you. And that’s fine. The Linux world has approximately five hundred bajillion distros. What’s that you say? Only about 20 of them are any good? Well, fair enough, but even if that pulled-out-of-someone’s-butt number is accurate, there are still 19 distros that aren’t Fedora! Reinstalling your OS is unpleasant, but it’s important to choose the right one that suits your needs and preferences. Choice comes with the responsibility of choosing wisely.

Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything is going to go. And you wouldn’t be wrong about that, but transitions still take time. Distros that intentionally ship old software like Ubuntu LTS or Debian Stable will let you keep using X11 for years and years. Arch will probably keep shipping X11 for a while too. You have options. By the time Ubuntu LTS removes X11 too, everything will be fully ready.

Putting it all together

Wayland is a replacement for X11, which is dead. Despite a rocky development process, it’s ready enough for Plasma and KDE apps that Fedora KDE is pushing it pretty hard. Many 3rd-party apps are already Wayland-native, but many are not, and they need to put in the work to port to Wayland. If anything they need is still missing, they need to step up to be part of the process of adding it. This process is happening, and isn’t going to stop happening. We need to work together to make it happen faster and more smoothly.

Saturday, 16 September 2023

Kraft (Github) is a desktop utility making it easy to create offers and invoices quickly and beautifully in small companies.

Today we are releasing Kraft Version 1.1 with significant improvements for users and the Krafts integration with latest software such as cmake and KDE.

It received updated dutch translations in UI and also for the manual. The application icon was fixed, and some cmake related fixes were done that make Kraft working with different versions of Akonadi that are available on different distributions.


For users, two significant improvements are included: The header- and footer texts of the documents now may contain macros that support automatic computing of values such as dates that depend on the document date. With that, it is for example easy to have for example a payment date printed out on the document, that is ten days later than the document date.

There are even more interesting macros, stay tuned for a separate post about this feature.

Insert Templates Button

The second new feature is a new button that allows to insert templates for the header- or footer text at the cursor position. Before it was only possible to replace the entire text with a template. This will give users way more flexibility how to structure template texts.

In parallel to these improvements, work is also going on in a branch for Kraft 2.0 which will enable more collaborative functions for Kraft.

The upside of a wet summer followed by a late heatwave is here.