Contrary to popular belief, Akademy 2024 was not my first Akademy. KDE seems to keep tagged faces from Akademy group photos around, so I stumbled over some vintage pictures of me in 2006 (Glasgow) and 2007 (Dublin). At the time, I was an utter greenhorn with big dreams, vague plans, and a fair bit of social anxiety.

And then I disappeared for 15 years, but now it's time for a new shot. This time around, I'm a little less green (rather starting to grey a little) and had a surprising amount of stuff to discuss with various KDE collaborators. Boy, is there no end of interesting people and discussion topics to be had at Akademy.

"Oh, you're the PowerDevil guy"

You're not wrong, I've been contributing to that for the past year. As such, one highlight for me was to meet KDE's hardware integration contractor Natalie Clarius in person and sync up on all things power-related.

Natalie presented a short talk and hosted a BoF session ("Birds of a Feather", a.k.a. workshop) about power management topics. We had a good crowd of developers in attendance, clearing up the direction of several outstanding items.

Power management in Plasma desktops is in decent shape overall. One of the bigger remaining topics is (re)storing battery charge limits across reboots, for laptops whose firmware doesn't remember those settings. There is a way forward that involves making use of the cross-desktop UPower service and its new charge limit extensions. This will give us the restoring feature for free, but we have to add some extra functionality to make sure that charge threshold customization remains possible for Plasma users after switching over.

We also looked at ways to put systems back to sleep that weren't supposed to wake up yet. Unintended wake-ups can happen e.g. when the laptop in your backpack catches a key press from the screen when it's squeezed against the keyboard. Or when one of those (conceptually neat) "Modern Standby" implementations on recent laptops are buggy. This will need a little more investigation, but we've got some ideas.

I talked to Bhushan Shah about power saving optimizations in Plasma Mobile. He is investigating a Linux kernel feature designed for mobile devices that saves power more aggressively, but needs support from KDE's power management infrastructure to make sure the phone will indeed wake up when it's meant to. If this can be integrated with KDE's power management service, we could improve battery runtimes for mobile devices and perhaps even for some laptops.

The friendly people from Slimbook dropped by to show off their range of Linux laptops, and unveiled their new Slimbook VI with KDE neon right there at the conference. Compared to some of their older laptops, build quality is improved leaps and bounds. Natalie and I grilled their BIOS engineer on topics such as power profiles, power consumption, and how to get each of their function keys show the corresponding OSD popup.

"I'm excited that your input goal was chosen"

Every two years, the KDE community picks three "Goals" to rally around until the next vote happens. This time, contributors were asked to form teams of "goal champions" so that the work of educating and rallying people does not fall on the shoulders of a single poor soul per goal.

So now we have eight poor souls who pledge to advance a total of three focus areas over the next two years. Supported by KDE e.V.'s new Goals Coordinator, Farid. There's a common thread around attracting developers, with Nicolas Fella and Nate Graham pushing for a "Streamlined Application Development Experience" and the KDE Promo team with a systematic recruitment initiative titled "KDE Needs You". And then there's this other thing, with a strict end user focus, briefly introduced on stage by guess who?

Turns out a lot of people in KDE are passionate about support for input devices, virtual keyboards and input methods. Gernot Schiller (a.k.a. duha) realized this and assembled a team consisting of himself, Joshua Goins (a.k.a. redstrate) as well as Yours Truly to apply as champions. The goal proposed that "We care about your Input" and the community's response is Yes, Yes We Do.

As soon as the new goals were announced, Akademy 2024 turned into an Input Goal Akademy for me. In addition to presenting the new goal on stage briefly, we also gathered in a BoF session to discuss the current state, future plans and enthusiastic volunteering assignments related to all things input. I also sat down with a number of input experts to learn more about everything. There is still much more I need to learn.

It's a sprawling topic with numerous tasks that we want to get done, ranging from multi-month projects to fixing lots of low-hanging fruit. This calls for a series of dedicated blog posts, so I'll go into more detail later.

Join us at #kde-input:kde.org on Matrix or watch this space (and Planet KDE in general) for further posts on what's going on with input handling in KDE.

Look at the brightness side

KWin hacker extraordinaire Xaver Hugl (a.k.a. zamundaaa) demoed some of his color magic on a standard SDR laptop display. Future KWin can play bright HDR videos in front of regular SDR desktop content. Accurate color transformations for both parts without special HDR hardware, that's pretty impressive. I thought that HDR needs dedicated hardware support, turns out I'm wrong, although better contrast and more brightness can still improve the experience.

I also got to talk to Xaver about touchpad gestures, learned about stalled attempts to support DDC/CI in the Linux kernel directly, and pestered him for a review to improve Plasma's D-Bus API for the new per-monitor brightness features. Also the XDC conference in Montreal, is happening in less than a month, featuring more of Xaver as well as loads of low-level graphics topics. Perhaps even input-related stuff. It's only a train ride from Toronto, maybe I'll drop by. Maybe not. Here's a medieval German town selfie.

Thanks to the entire KWin gang for letting me crash their late-night hacking session and only throwing the last of us out at 2 AM after my D-Bus change got merged. Just in time for the Plasma 6.2 beta. I was dead tired on Thursday, totally worth it though.

Atomic KDE for users & developers

Plasma undoubtedly has some challenges ahead in order to bring all of its power and flexibility to an image-based, atomic OS with sandboxed apps (i.e. Flatpak/Snap). David Edmundson's talk emphasized that traditional plugins are not compatible with this new reality. We'll need to look into other ways of extending apps.

The good news is that lots of work is indeed happening to prepare KDE for this future. Baloo making use of thumbnailer binaries in addition to thumbnailer plugins. KRunner allowing D-Bus plugins in addition to shared libraries. Arjen Hiemstra's work-in-progress Union style being customizable through configuration rather than code. Heck, we even learned about a project called KDE Neon Core trying to make a Snap out of each and every piece of KDE software.

Going forward, it seems that there will be a more distinct line between Plasma as a desktop platform and KDE apps, communicating with each other through standardized extension points.

All of this infrastructure will come in handy if Harald Sitter's experimental atomic OS, KDE Linux (working title), is to become a success. Personally, I've long been hoping for a KDE-based system that I can recommend to my less technical family members. KDE Linux could eventually be that. Yes, Fedora Kinoite is also great.

What took me by surprise about Harald's presentation was that it could be great even as a development platform for contributing to the Plasma desktop itself.

As a desktop developer, I simply can't run my Plasma development build in a container. Many functions interact with actual hardware so it needs to run right on the metal. On my current Arch system, I use a secondary user account with Plasma installed into that user's home directory. That way the system packages aren't getting modified - one does not want to mess with system packages.

But KDE Linux images contain the same system-wide build that I would make for myself. I can build an exact replacement with standard KDE tooling, perhaps a slight bit newer, and temporarily use it as system-wide replacement using systemd-sysext. I can revert whenever. KDE Linux includes all the development header files too, making it possible to build and replace just a single system component without building all the rest of KDE.

Different editions make it suitable for users anywhere between tested/stable (for family members) and bleeding edge (for myself as Plasma developer). Heck, perhaps we'll even be able to switch back and forth between different editions with little effort.

Needless to say, I'm really excited about the potential of KDE Linux. Even without considering how much work it can save for distro maintainers that won't have to combine outdated Ubuntu LTS packages with the latest KDE desktop.

Conclusion

There's so much else I've barely even touched on, like NLnet funding opportunities, quizzing Neal Gompa about KDE for Enterprise, Rust and Python binding efforts, Nicolas Fella being literally everywhere, Qt Contributor Summit, finding myself in a hostel room together with fellow KDE devs Carl & Kåre. But this blog post is already long enough. Read some of the other KDE blogs for more Akademy reports.

Getting home took all day and jet lag isn't fun, but I've reasonably recovered to give another shot at bringing KDE software to the masses. You can too! Get involved, donate to KDE, or simply enjoy the ride and discuss this post on KDE Discuss.

Or don't. It's all good :)

Introduction¶

License information in source code is best stored in each file of the source code as a comment, if at all possible. That way the license metadata travels with the file even if it was copied from its original package/repository into a different one.

Client-side JavaScript, CSS and similar languages that make up a large chunk of the web are often concatenated, minified and even uglified in an attempt to make the website faster to load. In this process, most often, the comments get culled the first to reduce the number of characters that serve no function to the program code itself.

Problem¶

The problem therefore is that typically when JavaScript, CSS (or similar client-side¹ code) is being built, it tends to lose not just comments that describe the code’s functionality, but also comments that carry licensing and copyright information. And since licenses (FOSS or not) typically require the text of the license and copyright notices² to be kept with the code, such removal can be problematic.

Proposal¶

The goal is to preserve copyright and licensing information of web front-end code even after minification in such a way that it makes FOSS license compliance³ of web applications easier.

In addition, my proposal is intended to keep things:

• as simple as possible;
• as short as possible;
• not introduce any new specifications, but rely on well-established standards; and
• not require any additional tooling, but rely on what is already in common use.

Essentially, my suggestion is literally as simple as wrapping every .js, .css and similar (e.g. .ts, .scss, …) file with SPDX snippets tags, following the REUSE specification as follows:

At the very beginning of the file introduce an “important” comment block that starts the (SPDX) snippet and includes all the REUSE/SPDX tags that apply to this file, e.g.:

/*!
 * SPDX-SnippetBegin
 * SPDX-CopyrightText: © 2024 Hacke R. McRandom <hacker@mcrandom.example>
 * SPDX-LicenseIdentifier: MIT
 */

And at the very end of the file introduce another “important” comment block that simply closes the (SPDX) snippet:

/*! SPDX-SnippetEnd */

… and that is basically it!

How any why this works (in theory)¶

This results in e.g. a .js file that would look something like this:

/*!
 * SPDX-SnippetBegin
 * SPDX-CopyrightText: © 2024 Hacke R. McRandom <hacker@mcrandom.example>
 * SPDX-LicenseIdentifier: MIT OR Unlicense
 */

import half_of_npm

code_goes_here();

/*! SPDX-SnippetEnd */

and a .css file as follows:

/*!
 * SPDX-SnippetBegin
 * SPDX-CopyrightText: © 2020 Talha Mansoor <talha131@gmail.com>
 * SPDX-LicenseIdentifier: MIT
 */

}
pre {
  overflow: auto;
  white-space: pre;
  word-break: normal;
  word-wrap: normal;
  color: #ebdbb2; /* This is needed due to bug in Pygments. It does not wraps some part of the code of some lagauges, like reST. This is for fallback. */
}

/*! SPDX-SnippetEnd */

All JavaScript, CSS, TypeScript, Sass, etc. files would look like that.

Then on npm run build (or whatever build system you use) the minifier keeps those tags where they are, because ! is a common trigger to keep that comment when minifying.

So if all the files are tagged as such⁴, the minified barf⁵ you get, should include all the SPDX tags in order and in the right place, so you see which license/copyright starts and ends to apply in the gibberish.

And if it pulls stuff that does not use REUSE (snippets) yet, you will still be able to tell it apart⁶, since it will be the barf that’s between SPDX-SnippetEnd of the previous and SPDX-SnippetBegin of the next properly marked barf.

Is this really enough?¶

OK, so now we know the start and end of a source code file that ended up in the minified barf. But are the SPDX-SnippetCopyrightText and SPDX-License-Identifier enough?

I think so, yes.

If I chose to express my copyright notice using an SPDX tag – especially if I followed the format that pretty much all copyright laws prescribe – that should be no problem⁷.

The bigger question is whether communicating the license solely through the SPDX IDs⁸ is enough, since you would technically not be including the whole license text(s). Honestly, I think it is fine.⁹ At this stage SPDX is not just long-established in the industry and community, but is also a formal international standard (ISO/IEC 5692:2021). Practically from its beginning – and probably the most known part of the spec – unique names/IDs of licenses and the equivalent canonical texts of those license have been part of SPDX. Which means that if I see SPDX-License-Identifier: MIT I know it specifically means the text that is on https://spdx.org/licenses/MIT.html. Ergo, as long as you are using licenses from the SPDX License List in these tags, all the relevant info is present.

How to keep the tags – Overview of popular minifiers¶

As mentioned, most minifiers tend to remove comments by default to conserve space. But there is a way to retain license comments (or other important comments). And this method existed for over a decade now!

I have done some research into how different minifiers deal with this. Admittedly, mostly by reading through their documentation. Due to my lack of skills, I did not manage to test out all of them in practice.

But at least theoretically the vast majority of the minifiers that I was told are common (plus a few more I found) seem to support at least one way of keeping important – or even explicitly copyright/license-relevant – comments.

From what I can tell it is only Bun that does not support any way to (selectively) preserve comments. There is a ticket open to implement (at least) the ! method though.

While not themselves minifiers, module bundlers do call and handle minfiers. Here are notes about the ones that I learnt are the most popular ones:

• WebPack is, from what I am told, the most wide-spread module bundler. By default is uses Terser to minify things, but it can be set to use a custom minification function too;
• Rollup is another popular module bundler. For this one you need to write a custom minification function, but in its documentation Terser is used as the example;
• (for SWC see the table above, as it does its own minification).

From this overview it seems like using the /*! comment method is our best option – it is short, the most widely supported and not loaded with meaning.

More details on both styles below.

Using @license / JSDoc-style¶

JSDoc is a markup language used to annotate JavaScript source code files to add in-code documentation, which is then used to generate documentation.

Looking at the JSDoc specification, the following keywords seem relevant:

• @copyright – “used to document copyright information in a file overview comment” – oddly enough, this tag does not seem to be deemed preserve-worthy, so we can discount it;
• @license – “identifies the software license that applies to any portion of your code” (seems to exist since 2013);
• @preserve – this one seems to be deprecated in favour of @license, but still recognised by several minifiers, so I mention it here.

So from JSDoc it seems the best choice would be @license. To quote from the spec itself:

The @license tag identifies the software license that applies to any portion of your code.

You can use any text to identify the license you are using. If your code uses a standard open-source license, consider using the appropriate identifier from the Software Package Data Exchange (SPDX) License List.

Some JavaScript processing tools, such as Google's Closure Compiler, will automatically preserve any JSDoc comment that includes a @license tag. If you are using one of these tools, you may wish to add a standalone JSDoc comment that includes the @license tag, along with the entire text of the license, so that the license text will be included in generated JavaScript files.

Using /*! / YUI-style¶

This other style seems to originate from Yahoo! UI Compressor 2.4.8 (also from 2013), to quote its README:

C-style comments starting with /*! are preserved. This is useful with comments containing copyright/license information. As of 2.4.8, the '!' is no longer dropped by YUICompressor. For example:

/*!
* TERMS OF USE - EASING EQUATIONS
* Open source under the BSD License.
* Copyright 2001 Robert Penner All rights reserved.
*/

remains in the output, untouched by YUICompressor.

Many other projects adopted this, some extended it by using also the single-line //!, but others have not.

Also note that YUI itself does not use the double-asterisk /** tag (if it did, it should be /**!), whereas that is typically the starting tag in JSDoc (and JavaDoc) of a document-relevant comment block.

So from the YUI-style tags, it seem using (multi-line) C-style comments that start with /*! is the most consistently used.

And as YUI-style seems to be the most commonly implemented way to tag and preserve (licensing-relevant) comments in JS, it would seem prudent to adopt it for our purposes – to preserve REUSE-standardised tags to mark license and copyright information in files and snippets.

A few PoC I tried¶

So far the theory …

But when it comes to testing it in practice, it gets both a bit messy and I very quickly reach the limits of my JS skills.

I have tried a few PoC, and ran into mixed, yet promising, results so far.

The most issues, I assume, are fixable by simply changing the settings of the build tools accordingly.

It is entirely possible that a lot of the issues are PEBKAC as well.

Svelte + Rollup + Terser¶

The simplest PoC I tried is a Svelte app that uses Rollup as a build tool and Terser as the minifier – kindly offered by Oliver “oliwerix” Wagner as a guinea pig. I left the settings as they are, and the results are mostly fine.

First we pull the 29c9881 commit and build it with npm install; npm run build.

In public/build/ we have three files: bundle.css, bundle.js, bundle.js.map.

The bundle.css file does not have any SPDX-* tags, and I suspect this is because it consist solely of 3^rd party components, which do not use these tags yet. The public/global.css is still referred to separately in public/index.html and retains the SPDX-* tags in its non-minified form. So that is fine, but would need further testing to check the minified CSS.

The bundle.js file contains the minified JS and the SPDX-* tags remain there, but with one SPDX-SnippetEnd being misplaced.

If we compare e.g. rg SPDX- src/*.js¹²:

src/store.js
2: * SPDX-SnippetBegin
3: * SPDX-SnippetCopyrightText: 1984 Winston Smith <win@smith.example>
4: * SPDX-License-Identifier: Unlicense
18:/*! SPDX-SnippetEnd */

src/main.js
2: * SPDX-SnippetBegin
3: * SPDX-SnippetCopyrightText: © 2021 Test Dummy <dummy@test.example>
4: * SPDX-License-Identifier: BSD-2-Clause
17:/*! SPDX-SnippetEnd */

… and rg SPDX- public/build/bundle.js

3:     * SPDX-SnippetBegin
4:     * SPDX-SnippetCopyrightText: 1984 Winston Smith <win@smith.example>
5:     * SPDX-License-Identifier: Unlicense
8:/*! SPDX-SnippetEnd */
10:/*! SPDX-SnippetEnd */
13:     * SPDX-SnippetBegin
14:     * SPDX-SnippetCopyrightText: © 2021 Test Dummy <dummy@test.example>
15:     * SPDX-License-Identifier: BSD-2-Clause

… it is clear that something is amiss. A snippet cannot end before it begins.

But when checking the public/build/bundle.js.map SourceMap, we again see the SPDX-* tags in order just fine.

I would really like to know what went wrong here.

React Scripts (+ WebPack + Terser)¶

Before that I tried to set up a “simple” React Scripts app with the help of my work colleague, Carlos “roclas” Hernandez.

Here, again, I am getting mixed results out of the box.

First we pull the af54954 commit and build it with npm install; npm run build.

On the CSS side, we see that there are two files in build/static/css/, namely: main.05c219f8.css and main.05c219f8.css.map.

Both the main.05c219f8.css and its SourceMap retain the SPDX-* tags where we want them, so that is great!

On the JS side it gets more complicated though. In build/static/js/ we have several files now, and if we pair them up:

• 453.2a77899f.chunk.js and 453.2a77899f.chunk.js.map
• main.608edf8e.js, main.608edf8e.js.LICENSE.txt and main.608edf8e.js.map

The 453.2a77899f.chunk.js* files contain no SPDX-* tags. Honestly, I do not know where they came from, but assume it is again 3^rd party components, which do not use these tags yet. So we can ignore them.

But it is the main.608edf8e.js* files that we are interested in.

Unfortunately, it is here that it gets a bit annoying.

It seems React Scripts is quite opinionated and hard-codes its preferences when it comes to minification etc. So even though it is easy to set-up WebPack and Terser to preserve (important) comments in the code itself, React forces it otherwise.

What this results in then is the following:

• main.608edf8e.js is cleaned of all comments – no SPDX-* tags here;
• but now main.608edf8e.js.LICENSE.txt has all the SPDX-* tags as well other important comments (e.g. @license blocks from 3^rd party components);
• and as for the main.608edf8e.js.map SourceMap, it includes SPDX-* tags, as expected.

The really annoying bit is that it seems like main.608edf8e.js.LICENSE.txt is not mapped, it is just a dump of all the license-related comments. So that does not help us here.

There is a workaround by injecting code and settings using Rewire, but so far I have not managed to set it up correctly. I am sure it is possible, but I gave up after it took way too much of my time already.

Some early thoughts on *.js.map and *.js.LICENSE.txt¶

If the license and copyright info is missing from the minified source code, but it is there in the *.js.map SourceMap (spec), I think that is better than nothing, but I am leaning towards it not being enough for the goal we are trying to reach here.

Similarly, when the minifier simply shoves all the license comments into a separate *.js.LICENSE.txt file, removing them from the *.js file and without any way to map the license and copyright comments back to the source code, I do not see how this is much more useful than the *.js.map itself.

So far, it seems to me like this is a problem caused by some frameworks (e.g. React Scripts) hard-coding their preferences when it comes to minification, without an easy way to override it.

But if there was a *.js.LICENSE.txt (or equivalent) that was mapped¹³ via SourceMaps, so one could figure out which license comment matches which source code block in the minified code, I would be inclined to take that as potentially good enough.

Future ideas¶

Once the base issue of preserving SPDX tags in minified (web front-end) code in proper places is solved, we can expand it to make it even more useful.

Open questions & Call for help and testers¶

As stated, I am not very savvy when it comes to writing web front-ends, so at this point this project would really benefit from people with experience in building web front-ends taking a look.

If anyone knows how to get React and any other similarly opinionated frameworks to not create the *.js.LICENSE.txt file, but keep the important comments in code, that would be really useful.

If you are a legal or license compliance expert, while I am quite confident in the logic behind this, feedback is very welcome and do try to poke holes in my logic.

If you are a technical person (esp. front-end developers), please, try applying this to code in different build environments and let me know what works and what breaks. We need more and better PoCs.

If you have proposed fixes, even better!

Comments, ideas, suggestions, … welcome.

Ultimately, my goal is to come up with a solution that works and requires (ideally) no changes in tooling and specifications.

If that means abandoning this proposal and finding a better one, so be it. But it has to start somewhere that is half-way doable.

Credits¶

While I did spend quite a bit of time on this, this would not exist without prior work and a lot of help from others.

First of all, the basic idea of treating each file as a snippet that just happens to currently span a whole file, was originally proposed to me by José Maria “chema” Balsas Falaguera in 2020 and we worked together on an early PoC on how to apply REUSE to a large-ish JS + CSS code-base … before (REUSE Snippets and later) SPDX Snippets came to be.

In fact, it was this Chema’s idea that sparked my quest to first bring snippet support to REUSE, and later to SPDX specifications.

At REUSE I would specifically like to thank Carmen Bianca Bakker, Max Mehl, and Nico Rikken for not refusing this idea upfront and also for being great intellectual sparring partners on this adventure.

And at SPDX it was Alexios “zvr” Zavras who saw the potential and helped me draft SPDX tags for snippets to the point where it got accepted.

I would also like to thank Henrik “hesa” Sandklef, Maximilian Huber and Philippe Ombredanne for their feedback and some proposals on how to expand this further later on.

Of course, none of this would be possible without everyone behind SPDX, REUSE, YUI, and JSDoc.

I am sure I forgot to mention a few other people, and if that was you, I humbly apologise and ask you to let me know, so I can correct this issue.

hook out → wow, this took longer than expected … so many rabbit holes!

From Fri, Sep 6^th to Tue, Sep 10^th I attended the 2024 edition of KDE Akademy in Würzburg, Germany. I booked a room in a hotel downtown the same place CoLa, a fellow KDE developer, stayed. Since parking is rather expensive in downtown areas, I left the car in front of the university building where the event was about to start on Saturday morning and took the bus into the city to the hotel. We all used the bus in coming days and one would always meet some KDE folks easy to spot wearing their lanyards.

On Friday night the KDE crowd gathered at a pub in the city and it was great to see old friends and also meet new people. At some point, I was talking to Carlos. It turned out that he already made some contributions to KMyMoney. The git log says it was in 2022. While more and more fellow KDE developers joined the place it became louder and louder and conversations were not easy anymore. Too bad that some of us got stranded at different places on their way out to Würzburg and did not make it until Saturday.

Conference

On Saturday, the conference program started with a keynote by Joanna Murzyn who took us on a journey from crucial mineral mining hubs to electronic waste dumpsters, uncovering the intricate connections between code, hardware, open source principles as well as social and environmental justice. We discovered how the KDE community’s work is shaping a more resilient, regenerative future, and explore ways to extend those principles to create positive impact beyond tech world.

On the first day, I took the opportunity to see the following talks

• Current Developments in KDE Hardware Integration
• KDE to Make Wines — Using KDE Software on Enterprise Desktops a Return on Experience
• KWin Effects: The Next Generation
• Adapt or Die: How new Linux packaging approaches affect wider KDE
• An Operating System of Our Own
• What’s a Maintainer anyway?

The last one for the day complemented the keynote in a nice way. In KDE newcomer Nicole Teale’s talk entitled “Getting Them Early: Teaching Pupils About The Environmental Benefits Of FOSS” she presented the work she is doing introducing KDE/FOSS to pupils, with a focus on its environmental benefits. She shared ideas on how to get schools involved in teaching pupils about reusing old hardware with FOSS. and presented some of the projects that have already been implemented in schools in Germany. This project is funded by the Umweltbundesamt (UBA) called “Sustainable Software For Sustainable Hardware”. The goal of this project is to reduce e-waste by promoting the adoption of KDE / Free & Open Source Software (FOSS) and raising awareness about the critical role software plays in the long-term, efficient use of hardware.

This becomes important in 2025 when Windows 10 runs out of support and Windows 11 requires new hardware, even though the existing one is still perfectly suited for the requirements of the majority of people. Linux and KDE to the rescue.

Saturday ended with Pizza and beer at the university as the booked beer garden canceled the reservation due to approaching thunderstorms.

On Sunday, I saw the following talks

• Openwashing – How do we handle (and enforce?) OSS policies in products?
• Opt In? Opt Out? Opt Green! KDE Eco’s New Sustainability Initiative
• KDE’s CI and CD infrastructure
• The Road to KDE Neon Core — Gosh! We’re surrounded by Snaps everywhere!

and of course the KDE Akademy award ceremony. In between those talks I had a chance to meet Julius Künzel and take a look at the problems we have in the KMyMoney project with the MacOS CD builds. He spotted a few things but I did not have the time to take care of them yet.

As a tradition, on Sunday is also the gathering to take the group picture. Here’s this years edition:

Birds of a feather sessions

On Monday and Tuesday I went to various BoF’s and took the opportunity to join the git/Gitlab presentation by Natalie Clarius. I learned a few subtleties of Gitlab that I didn’t know before, so it was worth it. In the meantime I talked with a lot of people and did a small bit of hacking (one bug fixed). The BoFs I joined:

• Opt Green / KDE Eco
• Tutorial: Using lager with Qt/QML
• KDE Goals – Streamlined Application Development Experience
• KDE Linux
• CI / CD

Good-bye Akademy 2024 / Thank you volunteers

Tuesday afternoon was the time to wave good-bye to the fellow KDE people and drive back home which I reached without delay (no traffic on the road) after an hour and a half. Hopefully, I will be able to join next time. Next stop will be the auditing of KDE accounting coming up in Berlin in a few weeks.

A big thank you goes out to the numerous volunteers who made this event happen. The team around seaLne just did a marvelous job.

Back from the fun of Akademy in Würzburg we can now get to the important task of testing Plasma 6.2 beta. It’s now in KDE neon testing edition which we build from the Git branches which will be used to make the 6.2 final release in 2.5 weeks time. Grab it now or if you don’t have a machine to install it on you can try the Docker images using the simple command `neondocker -p -e testing`.

I attended KDE’s Akademy and the Qt Contributor Summit that happened this year. I also completed my personal goal of giving a talk at a conference! These conferences were back-to-back and were located in Würzburg, Germany during the 5th-8th of September.

Travel

I stopped in IAD before flying into FRA, and the journey was fortunately uneventful compared to last year. My IAD->FRA flight was delayed by an hour due to (another plane’s) mechanical issues and the ATC was backed up. When they announced that they were “sequencing” departures, I was surprised to find them actually putting all of the departing planes in a physical line on the runway.

On the IAD->FRA flight, they were having some troubles with the satellite connection and tried restarting the in-flight entertainment. While that probably did not please many of the people enjoying their movies and shows, it did reveal the in-flight entertainment system for United flights were running Android. Boo, that’s no surprise.

The trains I were on weren’t too late and I quickly arrived in Würzburg after a transfer to Frankfurt Central Station. To save some money, I purchased a Deutschland-Ticket which covered most local transportation, including the buses in Würzburg proper. The ticket was only 50€, which if I had paid for the trains separately would mean at least 65€! I didn’t bother calculating how much bus fares would’ve cost. So the D-Ticket was definitely worth it during my stay.

On my returning overseas flight, the plane was half-empty. So I had a row with window seat all to myself, it was pretty sweet! Is this how flying first-class feels?

Hotel

I stayed in Hotel Amberger, close to the central station. It’s a cute little hotel, housed in a building that was clearly repurposed (my guess is some kind of hospital.) The hotel rooms are dead simple, but I didn’t really care. The first few days were really hot and the lack of a central air conditioning was really noticeable. Once the weather cooled off, the room was much more hospitable.

The hotel room had a TV, but mine did not work. No German TV for me this time! There was multiple bus stops near the hotel, so it was very easy to get to the Akademy venue. The QtCS venue was within walkable distance, so I walked there each day.

Qt Contributor Summit

This being my first Qt event, I didn’t really know what to expect. The venue is hosted in this expensive-looking conference center (Congress Centrum Würzburg) near the river. There was catered food, which included lunch and coffee breaks. Dinner was served on the first day. I noticed the wait staff and looked young so I wonder if they were local culinary students.

The talks were a mixed bag of topics, but I still found value going there. Most of the non-Qt people there were either KDE or KDE adjacent, of course. One of the cooler things for me was meeting a bunch of Qt people in person. Of whom I only knew by name, mentioned in e-mails and Gerrit, so on. Lots of people recognized me by my work on qmlformat, so that was neat.

The talk that interested me the most was Vladimir Minenko discussing “QML Next”, plans to use languages other than C++ with QML. Some languages discussed were Swift, and C#. Curiously Rust was absent, which he did duly note. They did mentioned they were hiring a developer to work on Rust support later this year. The talk itself the concept was a bit vague, but that’s because they’re still in the exploratory stage.

If you’re interested in the other talks in this conference, there are notes and slides available from the Qt Wiki.

Akademy

Akademy was hosted in Julius-Maximilians-Universität Würzburg, which was much farther than the venue for QtCS. That necessitated travel by bus, but that was also covered by the D-Ticket. The talks were hosted in two identical-looking lecture halls. On a bus heading towards Akademy one day, I noticed one of the screens didn’t work. Of course, I had to take a picture…

My talk was about integrating C++, Qt, Rust (and KDE Frameworks.) For proper disclosure, this talk is on behalf of my company for spreading the word of our cxx-qt library which eases integration of all of these technologies. I think was a bit too rough structurally but lots of people seem to enjoy it. One of my goals was to raise awareness of the usage of Rust you can find in KDE today, and that seemed to be successful! I want to express my gratitude to my fellow colleague Leon Matthes for helping review my slides. Also thanks to Darshan Phaldesai for his KDE work featured in the presentation.

The results of my talk I think were really cool! Within the KDE community, there seems to be some interest in picking up Rust. Lots of KDE developers were in varying stages of Rust interest. No one told me how stupid it was to glue the two together, so the general vibe I think is “it’s pretty neat, let’s see how well this works.” Unfortunately due to technical issues my talk was not recorded properly. A colleague recorded my talk on his phone, and will hand that over to the Akademy organizers soon.

The talk is now available on PeerTube. The slides are also available online.

Oh yeah, and the KDE goal I’m championing “We care about your Input” was selected! I’m pretty excited to keep hacking away on graphics tablets in KDE Plasma. Thanks to NLnet for sponsoring us to work on that, along with Wayland accessibility improvements.

One of my favorite talks was Xaver Hugl’s “What even is color?”. The work he’s doing in KWin is excellent, and I think he did a really great breakdown to understand what color management is.

Day Trip

In the day trip we went to Rothenburg. It was rainy, cold and miserable most of the day but we still had fun. One of my favorite parts was climbing up the tower to get an excellent view of the town.

That’s all I have to say about Akademy + QtCS, I had lots of fun this year! I’m happy that I was able to attend the talks this year, and meet a lot of people I missed last year. I hope everyone else were able to return home, and I’m excited to see what event I’ll attend next. See you!

Akademy is this yearly thing where bunch of KDE people go to talk about and work on KDE software. I had never been in one before, but this year I managed to make it there! This year Akademy was held at the city of Würzburg. This was also my first time in Germany, which is the furthest I've ever been from home.

I also had my wife Jenny with me, since if I had gone alone I would have gotten lost in some random mountain somewhere, or started a new life at the dark corners of Frankfurt airport, completely confused.

Friday, the day of flying (or so I thought)

On Friday the 6th, we left from Oulu to Helsinki first. Hop on plane at 14.30 and- Oh, a small delay.

Eh, it's fine, we hopped on the plane at 16.00 and-...

The flight was canceled.

So, we wait til like 19.30 or something to get to Helsinki. But of course, our flight from Helsinki to Germany had already left! No worries though, the next flight to Germany would leave soon.

Wait, what do you mean it leaves at 7.00?

Aaaaaaaaaahhhhggggggggggg....

Well, we got paid airport hotel room with paid dinner and breakfast. So we slept at Helsinki the first night. We were supposed to be at Würzburg at 23.55 or something, but of course not. Oh well, with some effort I might be able to make to the event, although I would miss the first few talks.

I had the most saddest (but still good) slab of lasagne at very sad and empty airport hotel restaurant. Very frustrated by everything. Sure it'll get better, right?

Saturday, the day of sleep deprivation

This time the airplane actually started to fly, instead of getting canceled for scandalous airplane activities, and we were on route to Frankfurt pretty soon. I spent some time in the airplane just working on my never-ending game project.

At Frankfurt, we got our luggage and went to the funny ICE train, which was a bit late. Apparently being late is some German train thing, I don't really understand it, but we have similar thing at Finland so it wasn't that shocking.

At the train, we were exhausted with our 4h of sleep due to stress not allowing us to sleep, so we just find some seats and sit down. Five minutes later some chap tells us to go away, so we stay up standing for the next 1h 30min next to the exit doors in some midcabin thing.

I wanted to watch some of the Akademy streams at this point, but I was mostly focusing on staying up.

Eventually, we finally reach the Burg of Würz. First impressions were that it looks really nice and.. What the hell is that? A.. mountain? Wow, they can be THAT tall??? (Authors note: Finland is very, VERY flat).

Also it was hellishly hot. The most I saw was 32 celsius. It was painful, I was sweating all the time and it was not fun.

We walk to our hotel room at Mercure hotel, which was really nice by the way. At this time, Akademy was having an incredible luncheon together, so me and Jenny decided to find something to eat. We found this place that was all about avocados, and I had something called powerbowl, which was brilliant.

After that, we began to study the incredibly complex thing that is the German bus system and started our trip towards the Akademy venue.

Aktually at Akademy

Me and my blurry sleep deprived brain walk to the venue and first off I meet familiar people. A lot of familiar people. Many hugs and "Oh you finally made it!"-s were shared. Jenny was with me there as well and it was fun to introduce her to my friends.

I honestly don't remember much about the day. It was quite a blur. But it was cool and I talked a lot.

I stole a lot of stickers and listened some talks, which I can barely remember... But I do remember which ones:

• Arjen's talk about Union KDE styling theme thing, that is super cool.
• Harald talked about of our own new possible shiny OS called KDE OS. Or 🍌 OS. I found this really exciting.
• A lot of lighting talks, where Nicole's talk about teaching lil kiddos how to install Linux with KDE software on old PC's to bring them back alive.
  • I think this talk was my favorite. It was very wholesome, motivating and I'd like to have similar kind of teaching event at home. No promises, but.. Maybe!

During this day I also began to give out salmiakki to people, since I had been well prepared. It was kinda fun to see peoples reactions, especially if they had never heard of it before.

Then it was back to sleep at the hotel.

Sunday, I managed to do things

On sunday I was at Akademy pretty much the whole day. Again, I listened bunch of talks, met more people and we had many good chats about LTS distros, KDE PIM, Kwin, Flatpak... And many other things I can't remember.

I listened Carl's KDE Apps Initiative talk which was very motivating for me, since I've wanted to make a KDE app for a while. A gaming related lil thing.

After the fun group photo and delicious lunch, I chatted more and wandered about the venue.

There was a talk about daily driving Plasma Mobile and I found it very cool, and we had a chat about the Plasma Mobile afterwards. Apparently my Fairphone 5 could run PostmarketOS with Plasma Mobile pretty well already, but I am not yet ready to commit to such a change with my mobile device.

Last I listened Xaver's talk about what color is in computers. I learned that sRGB is a lie and gasped audibly, then heard a lot of words related to color systems I didn't really always understand.. But I found the talk still quite interesting and informative.

The evening was then again a bit of a blur, with sponsors lightning talks and Akademy Awards (congrats to winners btw).

Very interesting day, but I've always been bad when it comes to learning from listening. I learn by doing.

Of course the day wasn't complete without me going to wait bus with my t-shirt and shorts (since it was hot again), and it started pouring like heck. I was soaked when I got to the bus, then at the last stop I had to walk 1km to the hotel in the rain. Ah well, it was warm so I didn't mind too much.

Monday, I skipped the class

On monday I was so exhausted by Everything:tm: I decided to just chill with my wife and we went around Würzburg, buying food and chocolate.

I spent that day just recharging my social batteries. And I ate some Flammenkuchen, which was delicious!

At some point when Jenny is done editing and uploading her video, I will make separate post for it. Then you can see what Würzburg is like, and hear what she did during the trip.

Edit: Am lazy but heres the link to the video: https://www.youtube.com/watch?v=05qexeiHNeY

Tuesday, I flocked together with the birds

Like on monday, on tuesday as well Akademy had these events called "BoFs" which is abbreviation of Birds of a Feather. Because "Birds of a Feather Flock Together". I don't know why it's called that, but anyhow, I participated a few of them:

• New design system bof
  • Very interesting discussions and ideas even I know nothing about design
  • I was mostly hoping to help people there with my programmer side of knowhow, as someone who has touched the Breeze styles codebases
• Tiling in kwin bof
  • We mulled over what we could do to make tiling in kwin even better
  • I have this mini task for myself where I try to make tiles split automatically when a window is dragged on top of the other
• Fedora KDE bof
  • I was just mostly curious whats up with Fedora KDE at the moment
  • I also wanted to give my praise for Fedora KDE, it's been my daily driver for many months now and it's been really good
  • Couple of my friends use it too due to my recommendation and they're having good time gaming on it! :)

To wrap up the evening, I had a fancy dinner with my friends. What was quite a culture shock to me was that after 22.00 the streets were practically completely empty. It was eerily quiet. At home we would have had few drunks about making noise, but at Germany there was just.. Silence.

Wednesday, to home again

Due to having two lizards and them needing a petsitter, and said petsitter not being able to be there the whole week, we left a bit early so we missed the daytrip and the last bof day.

Bit early being our flight from Frankfurt was leaving around 7.00. So we woke up at 5.00.

And when I wake up I saw a message in my phone saying: "Hi your flight is canceled"

Ah. Fun. If all had gone to plan, we would've been at home around 17.00. But instead, we were home at ~2.00.

We had to live at Frankfurt airport for ~7 hours, saw a lot of police with weapons (it was really scary to me, I've never seen weaponry like.. that openly), there was some suspicious luggage that got a whole McDonalds covered in "dont go here" tape and more police.

Urghgfhklfg. Scary.

Eventually we luckily made it to Helsinki and then back to Oulu and I didn't need to type out this blogpost from some corner of the airport.

Conclusions

Akademy was really fun event. I can hardly describe how fun it was. It's been quite a blur due to traveling issues and thus me being completely stressed and exhausted, but I still had many fun chats with everyone.

It was really nice to finally see who the people behind the internet names are and have talks with them, be it just random topics or KDE topics. I met people who I had never met before and shared many chats, laughs and information with them.

I learned quite a lot about what's going on in our KDE ecosystem and even outside of it, how we all interact. But I think the biggest thing I learned was that events like Akademy are crucial for the motivation and wellbeing of the KDE community. It helps us stay together, keep our bonds strong, be it KDE folk itself or people working with us, and keep us being awesome at what we do: Making computers do cool things, for free, for productivity and for fun.

Sorry about no photos, I have basically nothing: I am very bad at taking photos because I simply don't remember.

I love KDE and if you love KDE too, and if it's at all possible, visiting Akademy is well worth it!

See you at the next one, and apologies for the all-over-the-place-rambly-travel-post. Hope you find it a good read anyway.

Thanks for reading!

This year I went to Würzburg, which is a nice small German city famous for its wine. But I didn’t only go there for the wine, but also to attend Qt Contributor Summit and Akademy.

Qt Contributor Summit

The travel to Würzburg didn’t go as planned as Deutsch Bahn had some technical issues with their train and couldn’t reboot our train. We still managed to get in Würzburg on time and even had the change to get a small touristic tour from some locals.

The event itself was great and was the first time I attended fully a Qt Contributor Summit. Last year, I only attended a few session since the event was 20 min away from home.

There was many breakout rooms focused on some spcial topics, for me the most interesting sessions were about Qt for Python, how to hate QML, qt-project.org, Vector Graphics in Qt.

It was great to see how the KDE community still plays a big role in Qt and the Qt developers really appreciated what KDE finally moved to Qt6. They reported that the flow of contributors and bug reports increased.

Qt Chief Maintainer Volker Hilsheimer even stressed out how important it was for some of their customers to see KDE ported to Qt6, as it shows what Qt6 is stable and mature enough. Qt6 is indeed a hugo improvement over Qt5 and I am very happy how good the transition was.

I think it was a great idea to have Qt Contributor Summit just before Akademy. This allowed to have many KDE Contributor to the Qt Contributor Summit and many Qt developers to Akademy. It would be great next year to do the same next if possible and encourage more people from the Open Source Qt ecosystem to join too.

Akademy

Once the Qt Contributor Summit ended, we started a few hours later with the Akademy welcome event for some KDE beers. But before that, I had some bubble tea and spent some time with some friends exploring the city.

The weekend was full with a lot of great presentations. I presented a small report about the Accessibility Goal and the Fundraising working group. I also gave a bigger talk about the KDE Application Ecosystem, which I am really passionate about. The whole slides ware made with Calligra.

I was also very happy to see the new elected goals.

Sunday was also my birthday, thanks to everyone for congratulating me. I also received a super fancy special birthday sticker and some amazing cake.

Day Trip

We had our yearly day trip too, this time at Rothenburg ob der Tauber. A charming small town in south Germany.

BoFs

The next few days were filled with BoFs and many informal discussions. During the Promo BoF, we decided to create a “This Week in KDE Apps” blog posts. Paul volunteered Tobias, Joshua, and me as the initial team for this.

I also hosted a BoF about a future replacement of KWallet. There were some discussions about the scope of this effort. Should we just focus on storing OAuth2 tokens as a background service what the normal users should never interact with or do a full-blow password manager like macOS Keychain. I presented my work toward the latter around based on KeePassXC and the KeePass format (see my old blogpost) as it would allow to use a standardized file format that also work on other platforms. The KeePassXC developers are working on providing a reusable library, so we don’t need to fork their code. There will likely be more discussion about this in a separate gitlab issue. The lack of a good story around passwords is not unique to KDE but to the whole Linux ecosystem. If you have some opinions about this, feel free to reach out.

I discussed with Ben, Lydia and Aniqua the infrastructure for newsletters for our supporting members. Ben managed to get an instance of Listmonk in a matter of minutes and this seems to be the right way for us to manage a newsletters or at least way better than using a mailing list for this.

Kieryn hosted the best BoF: the Sticker BoF where we shared stickers and had a competition to see who had the best decorated laptop. I won!!! and received another special sticker. Thanks Kieryn for organizing this BoF and generally making Akademy this year such an awesome event!

I also ended up finishing a lot of work. I finally ported the last Drupal 7 website to Hugo: dot.kde.org which was a quite massive website with more than 20 years of history. I migrated the Hugo version used by KDE from 0.110.0 (which was more than a year old) to 0.134.0 and I am happy to report that the Hugo folks care a lot about stability and there was only some very small breaking changes. If you are working on some KDE websites, don’t forget to download the latest version of Hugo and to run the following command to update the KDE Hugo theme.

hugo mod get invent.kde.org/websites/hugo-kde@master

With Volker, we finally merged the status bar integration for Android apps so that KDE apps running on Android and now use breeze colors in their status bar, which looks much more integrated and like on Plasma Mobile.

I also got some improvements ideas during Akademy, and I already started implementing some of them: https://invent.kde.org/pim/itinerary/-/merge_requests/324

Finally I started rewritting the Calligra launcher to Kirigami based on the old Gemini UI. Still a bit far away from a being in a mergable state but it already looks quite good.

Conclusion

This was a great Akademy again. Thanks a lot for all the organizers for all their work. I hope to see some KDE contributors again soon at the Nextcloud Conference and Matrix Summit both in Berlin this month. And to the Linux Days in Dornbirn.

If you're using Plasma/KWin 6 i suggest you disable the Morphing Popups effect, it has been removed for Plasma 6.2 https://invent.kde.org/plasma/kwin/-/commit/d6360cc4ce4e0d85862a4bb077b8b3dc55cd74a7 and on X11 at least it causes severe redraw issues with tooltips in Okular (and i would guess elsewhere).

“Heather, Heather, Heather; what did you do now!” and both me & Fenris started laughing with Till, as we’re discussing about the thunderbird snap during the conference dinner.

Yup, this is from UbuCon Asia, my

• First conference
• First flight journey
• First travel out of my state
• First solo travel out of my state
• First solo stay at a hotel

Huhhh, a lot of first timers! I can’t think actually where to start with… I met so many people out there, got so many mentors! Thanks Till , for introducing me with so many mentors! I met Guruprasad sir (the launchpad guru 😄), Kierthana mam and Dimple didi (both are the documentation gurus). A lot of suggestions, tips, guides from them! Thanks a lot 🥹! BTW, How can I forget my OG Bhavani bhaiyaa!

Akademy 2024 in Würzburg - it was a blast

My second Akademy and has ended just yesterday. It was an amazing and productive time again! Apart from familiar faces I know from last year’s Akademy or the Plasma sprint last year in Augsburg, I met plenty of new faces. Some of which I of course had contact in KDE before, but only in the digital world.

One of the best parts was again the day trip with the KDE Community. While it was a bit rainy, we for sure made the best of it and saw the beautiful city of “Rothenburg ob der Tauber”. The view from the town hall tower was very beautiful:

The talks were also quite interesting and highlighted how many facades the KDE Community has. Apart from the lightning talks being great again, the “QML in Qt6” talk was quite valuable, because I did not manage to follow up closely on the latest improvements.
The talks and BOFs related to the KDE goals were also quite beneficial in getting a good impression in what direction we want to go.

Since we had so many interesting talks, it was not possible to join all of them. What I will follow up on later are the talks “Pythonizing Qt” and “C++, Rust and Qt: Easier than you think”.

Albert Astals Cid and I gave a lightning talk together about JSON linting (my part) and QML linting (his part). We were only able to touch the surface in the given time, but had some productive discussions and follow-up questions afterward. I will create a post about the JSON validation/JSON schema topic in the future, since I am still working on some aspects of this.

It has been great again to also do some hacking together and discuss ideas in-person. I will miss being able to say “Let’s discuss this at Akademy?” on merge requests ;).
I did quite a bit of hacking on KRunner, linting/formatting related tooling and also Clazy.
This can also be seen on my GitLab history that has turned a bit more blue and thus active:

What was a great improvement over the last Akademy were the chicken noises to make sure people stay within the time of their talk! To better improve on that, we should maybe get some real chicken next year 🥚🐣🐔. The talks on how to apply for funding in KDE might contain useful info when working towards this ;) PS: My life-long profile picture on GitHub/GitLab is of the super cute chicken I had 🥰.