People keep lamenting how lackluster Qt’s SVG renderer is. It leads to poorly rendered icons and wallpapers and it mostly only implements the SVG Tiny specification. As a weekend project I put together a resvg based image handler replacement. It was super easy because resvg is amazing!

The Plugins

An application that uses QSvgRenderer actually can, for the most part, just use resvg’s Qt header and call it a day. It has a very convenient interface that lets you replace most uses of QSvgRenderer with resvg’s. That’s all lovely, except who wants to port every application to a new library.

Luckily, most applications don’t actually use QSvgRenderer directly, they use it through 2 plugins. The iconengine plugin, providing a QIconEngine. And the imageformats plugin, providing a QImageIOHandler. Understanding when which is used is the first step.

Duh! The icon engine is used for icons! - Well, yes, usually…

The SVG QIconEngine confusingly isn’t actually used on KDE Plasma, instead we route all icon lookups through KIconEngine which does some magic. Ah! But where does it then get the icon from? If we follow the code paths a bit we end up here and after some reading on QImageReader we learn that on KDE Plasma icon lookup is actually not running through the SVG iconengine plugin but the imageformats plugin. Slightly confusing but actually beneficial because it means that icon rendering is ultimately running through the same code paths as regular SVG image reading when e.g. loading an Image in QML.

By creating an imageformats plugin we can replace most uses of QSvgRenderer with resvg without having to touch every application. Hooray!

QImageIOHandler

And the good news keeps on coming. A basic QImageIOHandler is super easy to implement.

    bool canRead() const override;
    bool read(QImage \*image) override;

All we need to do is implement reading

    \*image = ResvgRenderer(device()->readAll(), ResvgOptions()).renderToImage();

That gets us a working plugin. There are some extra features one can and should implement but for the most part that is all that’s needed. You can check out the complete source to see where things are at.

Duel of Plugins

Now that we have a plugin we just need to make Qt actually use ours instead of its own. Unfortunately this is where our luck runs out. Qt appears to have no facilities for manipulating which imageformats plugin is used when there are multiple candidates for the same format. In our case we have qsvg and qresvg both supporting SVG and it appears undefined behavior which of the two gets used. So, for the time being we’ll have to overwrite qsvg to get our plugin to reign supreme. Somewhat unfortunate.

Conclusion

Plugins are cool. Resvg is also cool. Making a resvg plugin is double cool.

You can give it a try at https://invent.kde.org/sitter/qresvgimageiohandler

Here’s what it looks like. On the left hand side you can see the image from a bug report where the image viewer icon is misrendered, on the right you can see the same icon rendered correctly using resvg.

To discuss this blog post head on over to KDE Discuss.

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

The Legacy of Bram Moolenaar - Jan van den Berg

Tags: tech, vim

Nice words about Bram Moolenaar maintainer of vim who passed away recently.

https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/

IBM, Red Hat and Free Software: An old maddog’s view - Linux Professional Institute

Tags: tech, unix, linux, redhat, history

Don’t be fooled of the title. Yes, it concludes about an opinion piece about the latest changes in policy around RHEL. Still, it starts with a very nice retelling of the history around UNIX and computing since the 70s. This is an invaluable resource.

https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-software-an-old-maddogs-view/

Your Computer Should Say What You Tell It To Say | Electronic Frontier Foundation

Tags: tech, google, browser, surveillance, attention-economy

Excellent piece against the Web Environment Integrity proposal from Google.

https://www.eff.org/deeplinks/2023/08/your-computer-should-say-what-you-tell-it-say-1

Blocked by Cloudflare

Tags: tech, cloudflare, google, surveillance, attention-economy

This is based on fingerprinting and sometimes fail. If Web Environment Integrity gets through it’ll be just worse.

https://jrhawley.ca/2023/08/07/blocked-by-cloudflare

Our current FOSS dystopia

Tags: tech, foss, politics, criticism

Definitely this. There’s still so much to achieve through FOSS, lots of missed opportunities. The mentioned factors clearly played a huge part in the current situation.

https://idiomdrottning.org/foss-dystopia

Just normal web things.

Tags: tech, browser, web

Indeed, too many websites or apps break or hijack basic features of the browser. To me it also shows the tension between trying to have a document browser and an application provider shoved in the same GUI.

https://heather-buchel.com/blog/2023/07/just-normal-web-things/

Python cocktail: mix a context manager and an iterator in equal parts

Tags: tech, programming, python

Definitely a clever combination of two Python constructs.

https://www.bitecode.dev/p/python-cocktail-mix-a-context-manager

Reverse Z (and why it’s so awesome) | Tom Hulton-Harrop

Tags: tech, 3d, floats

Good explanations of why you might want to revert the Z axis on your projection matrices. Of course it boils down to how float precision works.

https://tomhultonharrop.com/mathematics/graphics/2023/08/06/reverse-z.html

Remote work requires communicating more, less frequently | Ben Balter

Tags: tech, remote-working, management, communication

Kind of overlooking the cost of producing videos in my opinion. That being said, if you keep videos out of the picture this little article is spot on. Remote work is about more asynchronous and longer form communication first.

https://ben.balter.com/2023/08/04/remote-work-communicate-more-with-less/

I’m taking another short break, so no web review next week!

Bye for now!

This is the transcript of the talk I gave at Akademy 2023. If you prefer, you can watch the video (the sound is not great unfortunately) or look at the slides. The videos from the talk are in this post.

While this talk is focused on KDE software and Fedora Kinoite, most the concepts described here also apply to other Flatpak’ed applications (notably GNOME ones) and other rpm-ostree based desktops (Silverblue, Sericea, Onyx, etc.).

Testing: what, when, how?

Software has bugs! One way to find bugs is to have users test changes.

To make that possible, we need to deliver pre-release versions of our software in a way that is accessible to our users which are usually not developers.

Remember that even as a developer, you are always the user of someone else’s project. The technology stack is now so complex that it is mostly impossible to understand every single projects included in a modern desktop environment, even if it is fully open source.

Testing pre-release software also has to be reasonably safe regarding user’s data, as it’s often not practical to ask users to backup everything all the time and testing a small fix for an application should not have your entire system crash.

Users must also be able to go back to state where their system is running only “stable” software again, after they have completed testing a change or a fix.

Ideally, we would let users test all changes before they are commited to a repo, during the merge request process. But sometimes this is too difficult and we should then enable them to test those changes as soon as possible after they are commited.

Let’s start with KDE Apps

We’re now publishing most of KDE Apps as Flatpaks on Flathub. We track the latest stable releases. Updates are directly shipped to users.

See Albert Astals Cid’s talk (Flatpak and KDE) for more details about Flatpak, how they work and how we use it for KDE Apps.

KDE Apps on Flathub

On Flathub, the pull-request workflow is enforced. Each PR will build a “test” Flatpak. This Flatpak is installed using a single command.

This let’s developer create Flatpaks with fixes for users to test on top of stable releases.

Below is a demo of testing a Flatpak fix from Flathub:

Transcript of the video:

# Go to PR: https://github.com/flathub/org.kde.gwenview/pull/97

# Download Flatpak:
$ flatpak install --user \ https://dl.flathub.org/build-repo/35177/org.kde.gwenview.flatpakref

# Run Flatpak
$ flatpak --user run org.kde.gwenview

# Run Gwenview from the host to compare versions
$ gwenview

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

KDE Apps on KDE Invent

We are progressively setting up the same infrastructure in KDE GitLab instance (invent.kde.org) using GitLab CI.

Flatpak manifests are directly stored in application’s repos. Every pull request creates a Flatpak bundle to try out.

This let’s user test fixes and features before the change is merged.

Below is a demo of testing a Flatpak from GitLab CI:

Transcript of the video:

# Go to PR: https://invent.kde.org/graphics/gwenview/-/merge_requests/208

# Download the artifact:
$ curl -O https://invent.kde.org/graphics/gwenview/-/jobs/1041125/artifacts/download?file_type=archive

# Unzip and install the Flatpak bundle
$ unzip Flatpak_artifacts.zip
$ flatpak --user install --bundle ./gwenview.flatpak

# Run the Flatpak
$ flatpak --user run org.kde.gwenview

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

More advanced Flatpak usage

Flatpak content is stored in an ostree repo. Similarly to a Git repo, you can fetch any previous build to test regressions or compare behavior. This works with Flatpaks from Flathub.

Note that apps strictly tied to Qt versions will also need an older Runtime.

Below is a demo of bisecting a Flatpak from Flathub:

Transcript of the video:

# Install a Flatpak from Flathub
$ flatpak --user install org.kde.kcalc 

# Look at the log of versions (ostree commit log)
$ flatpak --user remote-info --log flathub org.kde.kcalc | less

# “Checkout” an older version
$ flaptak --user update --commit=... org.kde.kcalc

# Run the older version
$ flatpak --user run org.kde.kcalc

# Reset to latest version (note: operation canceled)
$ flapak update

# Skipping updates for a Flatpak
$ flatpak --user mask org.kde.kcalc

# Testing updates again
$ flapak update

# Removing the mask
$ flatpak --user mask --remove org.kde.kcalc

# Listing masks
$ flatpak --user mask

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

Can we do the same for KDE Plasma?

(Re-)introducing Fedora Kinoite

Fedora Kinoite is a Fedora variant featuring the KDE Plasma desktop. It follows the latest upstream KDE releases. It is stable and based on an up to date software stack from Fedora: Wayland, Pipewire, systemd user sessions, etc.

Fedora Kinoite brings the concept of an immutable desktop operating system, which means that you control when your system is changed.

The system is focused on Flatpak and container based workflows.

See my previous talk at Akademy: Akademy 2021: Kinoite, a new Fedora variant with the KDE Plasma desktop (slides, video).

Benefits of rpm-ostree

The system is shipped as a single consistent image. The updates are performed atomically: either fully applied or not, thus there are no broken updates and your system is always in a working state.

System updates (rpm-ostree) keeps all your data and Flatpak apps as-is. It makes it easy to rollback to a previous known good version.

You also have access to package diff between versions.

rpm-ostree ❤️ containers

rpm-ostree is now capable of delivering operating system images as a container images. This lets you manage operating system versions with containers tags.

You can store each version of your operating system inside a container registry and rebase your system to almost any version.

Below is a demo of rebasing to a container on Kinoite:

Transcript of the video:

# Looking at current state
$ rpm-ostree status

# Find the version to rebase to in the repo on Quay.io:
https://quay.io/repository/fedora-ostree-desktops/kinoite?tab=tags

# Rebase to this version
$ sudo rpm-ostree rebase \
ostree-unverified-registry:quay.io/fedora-ostree-desktops/kinoite:38.20230710.xyz
$ reboot

# Package diff
$ rpm-ostree db diff

# Cleanup and rollback
$ rpm-ostree cleanup
$ rpm-ostree rollback

Looking forward to Plasma 6

Fedora Kinoite Beta & Nightly

See Introducing Kinoite Nightly (and Kinoite Beta).

The builds for those images are currently paused (waiting for Plasma 6).

Plasma 6 Kinoite images?

We’re working on it! We’ll make Fedora Kinoite Nightly images, with Plasma 6 packages, on top of stable Fedora.

Hopefully coming soon!

Future options for testing?

Could we do pre-merge checks? Testing with OpenQA?

Running OpenQA tests for each Plasma PR is likely to create too much overhead, but maybe we can do daily or weekly checks?

Bringing RPM specfiles to Git Repos and building then in GitLab CI would significantly help with Fedora Kinoite Nightly and Beta efforts for testing.

Conclusion

Happy testing!

With this blog I would like to introduce KRdp, which is a new library implementing
the required glue to create a server exposing a KDE Plasma Wayland session over
the RDP protocol. It also contains a command-line based server
which will allow remote clients to control the current Plasma Wayland session.

Remote Desktop Support for Wayland

With the increase in people working from home the past years and other remote
use cases, it has become increasingly important to be able to control a running
computer remotely. While on X11 there are several existing solutions, for
Wayland the choices are rather more limited. Currently the only way of allowing
remote control of a Plasma Wayland session is through Krfb, which uses VNC1
for streaming to the client.

Unfortunately, VNC is not ideal, for various reasons. So to provide a better
experience we started looking at other options, eventually settling on building
something around the RDP protocol. Fortunately, because of the work done for
Krfb and various other projects, we do have all the parts implemented to allow
remote desktop control, the "only" thing left was to glue everything together.

Why RDP?

This raises the obvious question of "why use RDP?". There were several things
we considered when starting with this. From the start, we knew we wanted to
build upon something pre-existing, as maintaining a protocol takes a lot of
time and effort that are better spent elsewhere within KDE. Especially because
a custom protocol would also mean maintaining the client side. Both VNC and RDP
have many existing clients that can be used, which means we can focus on the
server side instead.

Another major consideration is performance. VNC sends uncompressed images of
the full screen over the wire, which means it requires a lot of bandwidth and
performance suffers accordingly. While I have seen some efforts to change this,
they are not standardised and it is unclear what clients would support those.
RDP, on the other hand, has a documented extension called the "Graphics
Pipeline" that allows using H.264 to compress video, greatly reducing the
needed bandwidth.

The main drawback of RDP is that it is owned by Microsoft and developed for the
needs of Windows. While a potential problem, the protocol is
openly documented and, equally important for us, there is an extensive
open-source implementation of both server and client side of the protocol in
the form of FreeRDP. This means we do not need to bother with the details of
the protocol and can instead focus on the higher level of gluing everything
together.

While I am talking about client support and performance since those were some
of our main considerations, RDP has many more documented extensions that, long
term, would allow us to greatly enhance the remote desktop experience by adding
features such as audio streaming, clipboard integration and file sharing.

Other Considerations

While the protocol was one major thing that needed to be considered for a good
remote desktop experience, it was not the only part. As mentioned, we
technically have all the pieces needed to enable remote desktop, but some of
those pieces needed some additional work to really shine. One example of this
is the video encoding implemented in KPipeWire.

During development of KRdp it became clear that using pure software encoding
was a bottleneck for a responsive remote desktop experience. We tried several
things to improve its performance, but ultimately concluded that we would need
to use hardware encoding for the best experience. This resulted in KPipeWire
now being able to use VA-API for hardware accelerated video encoding, which
not only benefits KRdp but also Spectacle once it is released with KDE Plasma 6.

Another part is the KDE implementation of the FreeDesktop Remote Desktop
portal. While it would be possible to directly communicate with KWin to request
remote input and a video stream, we preferred to use the portal so that it
would be possible to run KRdp from within a sandboxed environment. However, the
current implementation is fairly limited, only allowing you to choose to accept
or reject a remote desktop request. We are working on adding some of the same
features to the remote desktop portal as are already available for the
screencasting portal. This includes screen selection and remembering the
session settings.

KRdp

So all that leads us back to KRdp, which is a library that implements the glue
to tie all these parts together to allow remote desktop using the RDP protocol.
It uses the FreeDesktop Remote Desktop portal interface to request a video
stream and remote input from KWin, uses KPipeWire to encode the video stream
to H.264 and FreeRDP to send that to a remote client and receive input from that
client. The long term goal is to integrate this as a system service into KDE Plasma,
with a fairly simple System Settings page to enable it and set some options.

Trying it Out

For those who want to try it out, we are releasing an alpha as a Flatpak bundle
that can be downloaded from here. This Flatpak, when run using
flatpak run org.kde.krdp -u {username} -p {password} will start a server
and listen for incoming connections from remote hosts. See the readme for more
details and known issues. The Flatpak bundle was built from this code.
If you encounter any other issues, please file them at bugs.kde.org.

Discuss this blog post at discuss.kde.org.

1. While strictly speaking the protocol used by VNC is called Remote
   Framebuffer or RFB, VNC is the general term that is used everywhere, so that is
   what I am using here as well. ↩

Most of our desktop applications have a toolbar, sometimes they even have multiple toolbars next to or stacked on top of each other. More complex desktop applications such as Krita, Kdenlive or LabPlot often consist of multiple sub-windows, docks, tabbed views, etc. Docks and toolbars can be undocked, moved around and arranged freely and when dragged over a part of a window snap back into the window. This allows the user to customize their work environment to their liking and needs. This worked fine on X because it lets you do anything, this post explores the situation on Wayland.

The current situation

Lets start with a more familiar example, tabs in applications such as web browsers can often be dragged between different windows of the browser and when dropped somewhere else they become their own window. Dragging a tab out of Chrome creates a new window that follows the cursor and it is seamlessly integrated back into other Chrome windows when hovering over their tab bar. When doing this in a Wayland session it tried to do the same, starting a drag operation and creating a new window, when the cursor goes back to the bar the window is reincorporated. Except that clients can’t position their own windows on Wayland leading to sub-par UX. So it creates the window which the compositor places somewhere according to its policies. This window does not move around with the cursor but vanishes when the cursor enters the tabbar of another browser window. This feels weird and broken.

Qt exhibits similar behavior to Chrome when trying to drag around toolbars in a Wayland session, they detach and appear in the middle of application but the app itself reacts as if the toolbar is being dragged around and you could reattach it in some part of the window. However since they don’t have any window decorations, once detached they can only be moved around by compositor specific means like pressing Alt and dragging when using KWin. Dragging the cursor on the displayed move handle starts the “app thinks the window moves but it isn’t” state again and it may be possible to drag it back to its window. ‘May’ because this feels even weirder than the initial action since the app can’t know on Wayland where the toolbar window was in relation to the other window . Detaching a dock results in the same experience, except that once it is detached it is actually impossible to dock it again. Floating docks receive a system titlebar so at least can be moved around more easily but contain no way to start the docking process again. This is also weird and broken.

This problem is one of the last remaining blockers for some of our more complex applications in KDE for switching to Wayland by default. While some workarounds (such as the one outlined above) exist, a proper solution is needed.

The solution

Facing this shortcoming a new extended drag protocol was proposed and implemented by Chrome developers in 2020 but unfortunately the effort stalled. My initial impression was that it provided a good starting point but maybe sometimes a bit complicated. Nevertheless I started to prototype an implementation in KWin and although not even Chrome implemented the more involved parts of the protocol I had working tab dragging not soon after. Encouraged by this I implemented the minimal client parts in Qt and could successfully drag toolbars and dock widgets around. This convinced me that a more focused protocol would be sufficient cover the different use cases.

A bit of trimming, renaming and shuffling things around resulted in the xdg-toplevel-drag protcotol. The idea behind it is that the application can attach a window to a drag operation which then the compositor moves around with the cursor. The advantage of using the existing drag mechanism is that the window under the cursor is informed of the cursor position while a normal window move does not provide any information to it. The application can then also use the normal drag and drop negotiation mechanisms to infer the state and choose an appropriate action. For example the drag being accepted means it is over an area that will incorporate the window. It’s up to the client to take immediate action or not, Chrome will move a tab to a window the moment it reaches its tabbar while Qt just shows an indicator and waits for the drop to perform any action. When a drop happens but the drag is not accepted the cursor was over some other area and a likely (non-)action of a client would be to keep the window that was being dragged around alive.

The above shows the mentioned protocol in action inside Qt and KWin. I also went ahead and added support for the newly proposed protocol to Chrome since I iterated on their original work. But it also shows that the same protocol also works for its slightly different use case of attaching and detaching tabs during the ongoing drag. Below you can see Chromium using this new protocol inside KWin.

The way forward

This work addresses one of the main blockers for our Wayland session that we want to solve in time for the initial Plasma 6 release. Due to timeframes we know that Plasma 6 is likely to require Qt 6.6. However the feature freeze for Qt 6.6 was already in June and the protocol was not accepted at that time. To ensure the functionality is available for our deadlines the Qt implementation that is shown in this blog post was merged under a different name (changing thexdg prefix toqt). The intention here is to change it back once as soon as possible when the upstream procotol is accepted. So the applications relying on it work perfectly not only on Plasma but also on all others desktops.

Discuss this post on KDE Discuss.

There is a term, that in recent years my brain is using a lot when trying to explain to me what my eyes observe. Late-Roman Decadence. I am not a historian, so I might be inaccurate with its actual meaning. For me it just means "wasting because we can". If you want to see this in action, delete your YouTube cookies to get out of your tech bubble and open its start page. Probably depending on your location, it's all about eating the biggest meals for 9000€, driving the fastest cars for 777k€, destroying expensive things in the most hilarious ways for 2M€ as well as giving homeless people 100€ and filming them at whatever they do with it before they fall back into their own life of being spat out and ignored by society. For me: disgusting and worth another strategically well sized and well placed comet.

But that's just the depression speaking. So let's not look at the world, let's look at and try to tackle my own little problems.

I like to have my laptop efficient and quiet. No fan, no moving parts that "klack" or whatever. Just silence. Bonus points if the AC adapter does not emit high-pitched buzzing. My ears are broken and very sensitive to noise. But I also like to have a machine that is as low-spec as it can be. Using less resources should be a good thing, right? So currently I am using an Acer Swift 1, which comes with an N6000 1.1GHz CPU and 8GB of RAM. This is fine for me performance-wise and I can have my usual 5 to 10 applications running with no problems at all. It even plays many of the coop games, my girlfriend comes around the corner with once in a while. For KDE work, the translation summit workflow is one of the things I tend to wait for. It would of course be faster on a higher spec'ed system but it takes around 20 minutes with Fedora and around 4 minutes with Debian on the same machine, so other factors than hardware seem to play a big role in this story as well. Also, I can still have that laptop at the... well... top of my... well... lap without burning my legs or making my blanket smell funny.

On a side note, this laptop sucks in other ways. It cannot do suspend properly. If it wants to go to sleep it immediately wakes up again with full display brightness and it repeats that every few minutes. Acer support says: no Windows, go fuck yourself. (Disclaimer: They did not actually say "go fuck yourself", they just stopped responding once I mentioned Linux.) Also the touch pad is only recognised as PS/2 device and lacks all gestures like scrolling and such. (Yes, I learned to use scrollbars again and hate scroll indicators that are thin or hidden.) Again, without Windows, you do not have the right of owning properly working hardware. I spent weeks looking into these two issues but none of the proposed solutions I found worked for me, either because they only work on Swift 3 and upwards with more settings available in EFI or they just did not do for me what they did for some other people. But broken hardware being sold and then fixed with Windows drivers is a completely different topic I do not want to delve into. Back to what I want to talk about. Buying another passively cooled laptop in the future. So what is the market up to?

Due to the bad Linux experience with the current Acer laptop, I decided to specifically look for Linux devices. Tuxedo to the rescue! Let's look at their current lineup. The InfinityBook 14 v2 was passively cooled but it is not in stock anymore and according to their support, there are currently no plans for new passively-cooled laptops. OK, so ... what are they up, then? In their latest news, they show a Stellaris 17 - Gen5 ... with absolute high-end hardware which needs an external water cooling system to operate properly. One of the key selling points is that the graphics card alone is allowed to draw 175 watts. Let's burn the planet ... because we can!

I do not want to pick at Tuxedo here in particular. The processor vendors are playing the same game for years. If they can gain 5% performance by increasing power consumption by 30%, they will do it. Complete nonsense, but it sells. Bigger, faster, louder. Let's make sure nobody realises that a 1GHz CPU and 8GB of RAM might be enough for 90% of the people. Instead, make the people think they are missing out so they consume without thinking about their actual needs. The same success story the car manufacturers are wallowing in with their SUVs. Let's burn the planet ... because we can!

So, what now? "Everything's fucked" is not a healthy attitude. But trying to change things seems impossible because of all the "not listening" you get when trying to talk to vendors about it. ... Yes, even from small vendors.

I will continue watching the Tuxedo space because I would like to support what they are doing (Linux-wise, not Hardware-wise). I will also keep an eye on AMDs Ryzen Embedded R1305G CPU and its close friends. Maybe some laptop manufacturer will be stupid enough to put it in one of their models. They could at least sell one of them. My backup plan is to buy a laptop with e.g. a low-spec Ryzen U series CPU and hope the fan can be made shut up with energy profiles and disabled boost and such. But that feels like wasted resources again. I will also continue to write to laptop manufacturers even if they do not even bother answering because my desires are too non-mainstream and as such too expensive to deal with. ... But I also ask myself, why bother at all. If the majority of our society (I am talking "western" here but the rest of the world is catching up quickly) is happily burning the planet for no reason but the fun of it, why am I trying to disagree and having a hard time? Why not just party along and wait for the cleansing comet? ... I guess it is one of life's challenges to find an answer to that question.

I tooted posted on Mastodon about how it would be great if more open source project would adopt REUSE.

Someone pointed out that it would be great to automate the addition of the metadata inside the files based on the git repository.

So here is a small script that does exactly that. It goes over all your .cpp and .h file and will add the header based on the list of authors as well as the first commit on that particular file.

You will want to adapt it to the license you are using for your project as well as change **/*.cpp to **/*.py if you are doing Python development.

#!/usr/bin/env bash
# SPDX-FileCopyrightText: 2023 Carl Schwan <carl@carlschwan.eu>
# SPDX-License-Identifier: MIT

for file in **/*.cpp **/*.h;
do
 year=`git log --format="format:%ci" --reverse $file | head -n1 | cut -d "-" -f 1`
 git shortlog -n -e -s -- $file | cut -f 2 | while IFS= read -r author
 do
 reuse annotate --copyright "$author" --year "$year" --license "GPL-2.0-or-later" $file
 done
done

This is not perfect and you want to run git diff before commiting the result, to check if the change made are fine.

At KDE we make software for many different platforms. One of them is Microsoft Windows. But what if an application crashes on Windows? New tech enables us to track crashes right in Sentry! Time to learn about it.

When an application crashes on Windows the user can submit crash data to Microsoft. Later KDE, as publisher of the app, can retrieve the crashes from there. This is the standard crash handling for the platform and it works incredibly well. What’s more, it means we don’t need to engineer our own custom solution for the entire process. So, that is all lovely.

Alas, since we are rolling out a KDE-wide crash tracking system called Sentry it would be even nicer if we had Windows crashes in there rather than third party service. That is just what I’ve built recently.

Crashes for our Windows applications now get imported into Sentry!

There are two pieces to this puzzle. One is a symstore and one is the actual importer.

Symbol Storage

In the Linux world we not so long ago grew debuginfod, it’s basically a tiny service that lays out debug symbols in a standardized file path so it may be consumed by any number of tools by making HTTP GET requests to well-known URIs.

Windows has something like this called symbol storage. It’s incredibly simple and merely lays out Windows debug information in a well defined path setup for consumption in tools.

To maintain a symstore of our own we use the excellent python module symstore along with some custom rigging to actually retrieve our debug information files.

Import

The second piece is our importer. It’s a trivial program that uses Microsoft’s APIs to retrieve crash data along with the minidump (the dump format used by Windows crashes), converts it into a Sentry payload, and sends it off to our Sentry instance. Sentry then consumes the crash, does symbolication using the debug symbols from our symstore, and generates a crash event.

Support

If you are shipping your application on the Windows Store you should consider publishing your dbg.7z files on download.kde.org (for example here is Okular), simply file a sysadmin ticket same as with any other upload to get this published. Once that is done you can submit a change to our symstore to publish the debug symbols, and our importer to import data into Sentry. If you need help just give me a poke.

If you are publishing builds for Windows but are not yet on the Window Store, you definitely should change that. It increases your application’s reach considerably. Get in touch with sysadmins to get yourself set up.

Importing crashes into Sentry adds another piece towards higher quality, more actionable crash reports. It’s going to be amazing.

Discuss this blog post on KDE Discuss.

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

The BBC on Mastodon: experimenting with distributed and decentralised social media - BBC R&D

Tags: tech, fediverse, attention-economy

Welcome to the Fediverse! It’s just an experiment for now, let’s hope they stay longer.

https://www.bbc.co.uk/rd/blog/2023-07-mastodon-distributed-decentralised-fediverse-activitypub

Sci-Hub’s Alexandra Elbakyan Receives EFF Award for Providing Access to Scientific Knowledge * TorrentFreak

Tags: tech, foss, science

This is well deserved. She’s doing a very important work for the progress of science. All those pay walls are nonsense.

https://torrentfreak.com/sci-hubs-alexandra-elbakyan-receives-eff-award-for-providing-access-to-scientific-knowledge-230728/

Tor’s shadowy reputation will only end if we all use it | Engadget

Tags: tech, anonymity, surveillance, tor

Indeed, we need more traffic going through Tor if we want to keep it effective.

https://www.engadget.com/tor-dark-web-privacy-secure-browser-anonymous-130048839.html?guccounter=1

“Web Environment Integrity” is an all-out attack on the free Internet — Free Software Foundation — Working together for free software

Tags: tech, foss, google, browser, surveillance

The FSF words are strong but deserved in this case. Let’s hope it marks the beginning of an efficient campaign against this move from Google.

https://www.fsf.org/blogs/community/web-environment-integrity-is-an-all-out-attack-on-the-free-internet

Google’s Plan To DRM The Web Goes Against Everything Google Once Stood For | Techdirt

Tags: tech, google, surveillance, attention-economy, security

Good explanations, the parallel and history perspective on Palladium is right. It’s the same fight than 20 years ago, it shows up its ugly head regularly. Time to collectively say no once more.

https://www.techdirt.com/2023/08/02/googles-plan-to-drm-the-web-goes-against-everything-google-once-stood-for/

Splitting the Web

Tags: tech, web, attention-economy

Interesting point of view. We have two worlds now coexisting on the Web and they tend to ignore each other more and more.

https://ploum.net/2023-08-01-splitting-the-web.html

From Napoléon to Macron: How France learned to love Big Brother – POLITICO

Tags: tech, france, surveillance, politics

Welcome in France, this country which claims to be a beacon for Human Rights but has a problem with its law enforcement for the past two centuries… surveillance abounds and its accelerating.

https://www.politico.eu/article/france-surveillance-cameras-privacy-security-big-brother-paris-olympics/

The Reluctant Sysadmin’s Guide to Securing a Linux Server

Tags: tech, server, self-hosting, security

This is a good list, should be seen as a starting point there are more things to do after this. I’m thinking for instance about adding fail2ban to the mix.

https://pboyd.io/posts/securing-a-linux-vm/

What’s in a Module? · thunderseethe’s devlog

Tags: tech, design, architecture, modules, programming, language

Interesting look at module systems and what they entail. It’s funny to see that most languages do things slightly differently in this area.

https://thunderseethe.dev/posts/whats-in-a-module/

Making the Global Interpreter Lock Optional in CPython

Tags: tech, python, multithreading, performance

OK, this could be big for Python. Let’s see how they execute this plan. It carries some risks as well, but they seem well aware of them.

https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474

Overloading arithmetic operators with dunder methods | Pydon’t 🐍 | mathspp

Tags: tech, programming, python

Nice summary of everything you can do with operators overload in Python.

https://mathspp.com/blog/pydonts/overloading-arithmetic-operators-with-dunder-methods

A Blog Post With Every HTML Element - Patrick Weaver

Tags: tech, web, frontend, html

A little experiment which turns into a neat reference in HTML elements. Could be useful.

https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/

Git files hidden in plain sight 🫥 - Tyler Cipriani

Tags: tech, git, funny, tools

Funny what you can do with Git at a lower level. 😊

https://tylercipriani.com/blog/2023/07/31/git-files-hidden-in-plain-sight/

Jujutsu: A Git-compatible DVCS that is both simple and powerful

Tags: tech, tools, git

Looks like an interesting alternative to Git. To investigate I think.

https://github.com/martinvonz/jj

Retrospective Prompts

Tags: tech, project-management, retrospective

Interesting set of follow up questions during a retrospective.

https://two-wrongs.com/retro-prompts.html

On levelling, learning and development - Robbie Clutton

Tags: tech, management, career, hr, learning

Interesting to look at several career progression models and compare them indeed. This is likely necessary when making your own model for your context.

https://blog.robbieclutton.com/p/on-levelling-learning-and-development

Netscape Meteors - Eryn Rachel Wells

Tags: tech, browser, history

Nice trip down memory lane. Interesting conservation work in any case.

https://erynwells.me/blog/2023/08/netscape-meteors/

When the wizards of the web met - The History of the Web

Tags: tech, web, history

Nice recounting of the first meetings to make the web what it is today.

https://thehistoryoftheweb.com/postscript/when-the-wizards-of-the-web-met/

Bye for now!

(German version of this post: https://wordsmith.social/felixernst/akademy-2023)

37 °C were the average daily temperature heights during the Akademy week in Thessaloniki. When you walk outside at these temperatures, your first thought is that you would rather go back inside. This used to be a temperature that one would hardly ever see there. 38 °C has not been exceeded in Thessaloniki in the 5 year span 1980 to 1984. But actually we were lucky, because the real heat wave only came around when we already left with around 44 °C in Thessaloniki and forest fires everywhere. It is a shame that with the current global political landscape none of this seems likely to become any better (to put it mildly) within our lifetimes. The nature in Greece is very nice aside from that.

But I think I have already exceeded my doom quota for this report, so back to brighter topics like the KDE community!

Meeting Everyone

I usually throw myself into these events, talking to everyone I haven't met yet and doing my part in making sure everyone feels welcome. It was especially interesting to talk to the local Greek students attending the event. One of them is already making attempts at contributing to Dolphin. I don't want to praise and pressure him here by saying his name already, but if you see a new Greek name on “This Week in KDE” in the next few weeks/month, you will know.

Some of the Greeks were part of the key note presentation “Libre Space Foundation – Empowering Open-Source Space Technologies”. Their passion for bringing their open source software to space was contagious.

I, on the other hand, am still stuck on this planet that gets hotter by the day. Did I mention the heat already? Oh right, back to topic…

Since becoming a maintainer of the Dolphin file manager about a year ago, I try to look out for the long-term health of the project. In that regard, I had an idea about how everything could go horribly wrong at this years Akademy:

Meeting the Other Dolphin Maintainer

I had never actually met the Frenchman Méven Car, who I share maintainership of Dolphin with. We hardly sent any direct messages to each other ever and none of them before April this year. All of this might seem strange considering that we have worked on Dophin together for a while now, but it also shows that one doesn't need to work behind closed doors to bring software forward. The most important aspect is having an atmosphere in which the technical and UX merits of work can be discussed honestly and without fear.

So one possible way our first meeting could go was, that we loathe each other. The next logical step would then be that we don't trust each other to be good stewards of the Dolphin project. One of us then creates a competing fork, which follows a different but similar vision, and in the end Dolphin would be stuck in an unpleasant atmosphere of hostile accussations and bad stability, eventually leading to its demise into irrelevance. 😱

In actuality, this didn't happen though. Phew!
But the above paragraph was the first story I told him.

We actually get along very well and had much time to talk about matters pertaining to Dolphin. It doesn't really seem like we have different ideas about what work needs to be done for further world domination.

Speaking of which:

Dolphin's Strategic Position

At last year's Dolphin meeting I had already tried to figure out the biggest areas of improvement by making this the headline of the meeting. Read all about it over here.

By this time, it seems like we are aware of most aspects that are still lacking in some regard. I am not really encountering a lot of fundamental criticisms anymore that I am not already aware of or which we don't know a way forward with. Most of the time we are lacking the work force to fix the more long-standing issues soon™.

Some of these were discussed at the Dolphin meeting at Akademy.

Especially Dolphin's search functionality was a big topic. It is kind of sad that people can't always rely on the Dolphin search to quickly find their files. This is partially for technical reasons, but also for user interface design reasons. You can read all about it here: https://invent.kde.org/system/dolphin/-/issues/46 Currently we are looking for a clear direction when it comes to the Dolphin search UI. You can find a mockup I made when you follow the link, but as long as nobody else is commenting on it or bringing their own design, there is no consensus. There are a lot of more technical background topics that need work as well though.

I was also wondering what Dolphin can gain from trying to break out of the Linux/Unix eco-system. Projects like Krita and Kdenlive were successfull in finding a user base outside of Linux. Dolphin is already one of (or even) the most popular file manager(s) on Linux. How much room for growth might there be if Dolphin's Windows version were more polished and visible for Windows users? Currently we don't seem to have people who want to fix bugs for this proprietary platform in their free time. Similar things could be said about a Mac or potential mobile version of Dolphin.

In line with KDE's current goals we also talked about improving testing using Selenium and AT-SPI. There is already some progress on this. Next there is the accessibility goal, for which I can point to a merge request I started creating while in Greece: https://invent.kde.org/system/dolphin/-/merge_requests/577 There is however still a lot of room for improvement when it comes to accessibility in Dolphin. Most annoyingly the “Back” and “Forward” buttons can currently not be focused using the Tab key. More contributions are always welcome in that regard. After attending all the talks about accessiblity I could find at this year's Akademy I feel a lot more confident about being able to review such contributions.

Méven has covered some more Dolphin topics in his article, so I will refer you to it: https://www.bivouak.fr/dolphin-at-akademy-2023/

Aside from Dolphin

…there is a lot more to talk about. So much more actually that it is becoming very apparent to me that I should probably cut it short now. Many of the talks are available on Peertube.

One more talk I want to highlight is “Make it talk: Adding speech to your application” by Jeremy Whiting. That one was about using speech more often in applications. I liked that talk not necessarily because I think there was a good way to add more speech to Dolphin in particular, but because it encourages improvements to tried and old basics of application design. If there was a “Speak” button next to this text you are currently reading, you would be able to transform this reading exercise into a podcast-like experience and a five-year-old kid could have listened along (and be bored about the tech-speak). I think a similar talk could be made about using animations for improved clarity when the state of an application or some data changes.

Thanks to the people who made this possible

Akademy would have been a very lonesome experience if we didn't have donors, sponsors and volunteers allowing everyone to come together. I am not sure if an international community like us could function long-term without such meetings. It gives me hope when people from eight different nations can sit at one table, talk about politics and still have a good time.

After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.