Skip to content

Plasma Sprint 2023 in Augsburg

Tuesday, 16 May 2023 | David Redondo

Finally a sprint again! The 2019 the Plasma Sprint in Valencia was my first in person KDE event and I was hooked instantly. However something mysterious happened in the next years that and in person meet ups stopped happening. While Akademy 2022 happened in person again, a sprint has different atmosphere and I was awesome to see people that couldn’t make Akademy or for whom it was their first sprint. Other attendees have blogged about the sprint as well, check them out too. Either on the planet or over on discuss Carl created a collection of a bunch of them.

So what did I do? Aside from the usual talking, discussion, planing which the others already blogged about. (And of course the live bug investigations on fellow developers’ machines who always seem to attract the weirdest issues.) I am afraid I spent the rest of the time on boring backend stuff.

For Plasma 6 we want to make use of the layer-shell wayland protocol for positioning and stacking Plasma’s own panels, backgrounds and some other windows such as krunner. This protocol was developed by the awesome wlroots people and is currently proposed for standardization. In the past we used our own plasma-shell protocol and unfortunately not only Plasma is using it at the moment but it also spread to applications with more advanced use cases than just having a normal window. As mixing windows from both systems together will be harder to layout and in general a desire to move on from the plasma-shell protocol for a more streamlined experienced I ported yakuake to use layer shell via our own Layer Shell Qt library.

Still Wayland related but probably even less interesting, I started porting libtaskmanager away from KWayland. KWayland was/is a framework consisting of two libraries (client and server side) wrapping wayland code for more straightforward consumption of Qt programs. As you can imagine this is quite some amount of boring code to maintain and with other good solutions available we would like to stop doing so. The server part of the framework was already moved to KWin in the past and we embraced qtwaylandscanner there for generating code wrapping wayland. For the client side we are now moving in the same direction. KWayland included everything but most of it was not used because Qt handles all the normal interactions with the compositor and almost all the remaining protocol interfaces were used only once because there is only a single place in our stack that needs to communicate the additional information with KWin (for example Klipper or the taskmanager). So it makes sense to move the code to the places where it is used instead of having to maintain a framework with the usual stability guarantees.

But I did not only work towards eliminating a framework, I also created an entire new one. Sorry! Enter KColorScheme. To be fair it’s not entirely new but KColorScheme and friends moved to their own library. KColorScheme was a pain point in our dependency stack since it was very central but its location in the KConfigWidgets library meant that you had to depend on a bunch of unwanted stuff just to read some colors. So we decided at the sprint to split it out to a new library and I implemented that. Afterwards I adjusted some consumers which do not need to longer depend on KConfigWidgets together with Nicolas.

As you can see it was quite the productive sprint which was possible because of the awesome people at Tuxedo Computers who hosted us and the KDE e.V that enables people from all over the world to come together and build awesome things. Consider donating so that we can continue doing so. The last thing left to say, I will be at Akademy which happens soon. See you there! I am going to Akademy 2023 in Thessaloniki, Greece