After the announcement upstream, Fedora’s @kde-sig follows up by making KDE Gear 22.12.2 available on Fedora 37.

As per Fedora’s policy, the software will first land on updates-testing and after receiving feedback and karma it will land on the updates repository.

If you want to help, make sure to follow the instructions on the update. You only need to run:

sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-17c31eabf7

Feel free to join us at our Matrix room!.

This is a non-comprehensive list of all of the major work I’ve done for KDE this month of January. I think I got a lot done this month! I also was accepted as a KDE Developer near the start of the month, so I’m pretty happy about that.

Sorry that it’s pretty much only text, a lot of this stuff isn’t either not screenshottable or I’m too lazy to attach an image. Next month should be better!

Custom icon theme in Tokodon

[Feature] I threw all of the custom icons we use in Tokodon into a proper custom icon theme, which should automatically match your theme and includes a dark theme variant. In the future, I’d like to recolor these better and eventually upstream them into Breeze.

KXMLGUI tooltips

[Bugfix] As part of cleaning up some KDE games-related stuff, I also looked into the issue of duplicate “What’s This?” tooltips. This also fixes that visual bug where you can close normal tooltips that don’t have “What’s This?” information to actually open.

KBlocks background changes

[Feature] This one isn’t merged yet, but in the future - KBlock themes authors will be able to specify where to pin the background instead of having it stretched by default.

Kirigami “About KDE” dialog

[Feature] I added something that’s been wanted for a while, Kirigami’s own “About KDE” dialog! It’s currently sitting in Add-ons, but will most likely be moved in the future. If you would like to suggest what we do about the About pages/windows in KDE, please check out the proposal. See the merge request.

Media improvements in Tokodon

[Bugfix] I did a lot of work improving media in Tokodon this month, including fixing the aspect ratios scaling correctly, video support (not merged yet) and other miscellaneous fixes. I also caught a bunch of blurhash bugs along with making the timeline fixed-width so images aren’t absurdly sized on a typical desktop display. Also a fix for three media attachments!

Krita.org dark theme

I’m starting to get involved in improving the KDE websites, and currently working on the new Krita.org website and adding a proper dark theme to it.

See the work-in-progress merge request.

Gwenview MPRIS fixes

[Bugfix] Not merged yet (due to MPRIS bugginess in general?) but I cracked a shot at improving the MPRIS situation with Gwenview. Notably, slideshow controls no longer “hang around” until a slideshow is actually happening.

CMake Package Installer

I worked a little on solving the kdesrc-build issue of manual package lists, and created cmake-package-installer. It parses your CMake log and installs the relevant packages for you. I want to start looking into hooking this into kdesrc-build!

See the repository.

KDE Wiki improvements

I made some misc changes to the Community Wiki this month, mostly centered around fixing some long-standing formatting issues I’ve noticed. The homepage should be more descriptive, important pages no longer misformatted (or just missing?) and the Get Involved/Development page should be better organized.

Misc Qt patches

[Bugfix] I cherry-picked a Qt6 commit fixing video playback in QML, which should appear in the next Qt KDE Patch collection update, mostly for use in Tokodon when video support lands. I also submitted an upstream Qt patch fixing WebP loading, meant for NeoChat where I see the most WebP images. See the GStreamer cherry-pick and the WebP patch.

Window Decoration KCM overhaul

[Feature] This isn’t merged yet (but it’s close!) so it barely misses the mark for January, but I’ll include it anyway. I’m working on making the Window Decoration KCM frameless and give it a new look that matches the other KCMs. See the merge request.

Flatpak applications are based on runtimes such as KDE or Gnome Runtimes. Both of these runtimes are actually based on Freedesktop SDK which contains essential libraries and services such as Wayland or D-Bus.

Recently there were a lot of discussion about supply chain attacks, so it might be interesting to ask how Freedesktop SDK was built. The answer can be found in freedesktop-sdk repository:

sources:
- kind: ostree
  url: freedesktop-sdk:releases/
  gpg-key: keys/freedesktop-sdk.gpg
  track: runtime/org.freedesktop.Sdk.PreBootstrap/x86_64/21.08
  ref: 0ecba7699760ffc05c8920849856a20ebb3305da9f1f0377ddb9ca5600be710b

So it is built using an older version of Freedesktop SDK image. There is now an approved merge request that completely reworks bootstrapping of Freedesktop SDK. It uses another intermediate docker image freedesktop-sdk-binary-seed that bridges the gap between freedesktop-sdk and live-bootstrap.

So what is this live-bootstrap? If you look at parts.rst you’ll see that it is a build chain that starts with 256 byte hex assembler that can build itself from its source and also 640-byte trivial shell that can read list of commands from the file and executes them. Then it proceeds building 130 (as of the moment of writing) other components and in the process builds GCC, Python, Guile, Perl and lots of other supporting packages. Furthermore, each component is built reproducibly (and this is checked using SHA256 hash).

Some caveat: at the moment freedesktop-sdk-binary-seed still uses older binary of rustc to build rustc but in principle one could leverage mrustc to build it. Or possibly rust-gcc will become more capable in future versions and will be able to bootstrap rustc.

So unless your flatpak application uses rust, it will soon be buildable from sub 1 KiB binary seed.

This is a rather small release with only two new features and one small improvement.

Big thank you to Xstrahl Inc. who sponsored development of new features included in this release and of QCoro in general.

And as always, thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

The original release announcement on qcoro.dvratil.cz.

Improved QCoro::waitFor()

Up until this version, QCoro::waitFor() was only usable for QCoro::Task<T>. Starting with QCoro 0.8.0, it is possible to use it with any type that satisfies the Awaitable concept. The concept has also been fixed to satisfies not just types with the await_resume(), await_suspend() and await_ready() member functions, but also types with member operator co_await() and non-member operator co_await() functions.

QCoro::sleepFor() and QCoro::sleepUntil()

Working both on QCoro codebase as well as some third-party code bases using QCoro it’s clear that there’s a usecase for a simple coroutine that will sleep for specified amount of time (or until a specified timepoint). It is especially useful in tests, where simulating delays, especially in asynchronous code is common.

Previously I used to create small coroutines like this:

QCoro::Task<> timer(std::chrono::milliseconds timeout) {
 QTimer timer;
 timer.setSingleShot(true);
 timer.start(timeout);
 co_await timer;
}

Now we can do the same simply by using QCoro::sleepFor().

Read the documentation for QCoro::sleepFor() and QCoro::sleepUntil() for more details.

QCoro::moveToThread()

A small helper coroutine that allows a piece of function to be executed in the context of another thread.

void App::runSlowOperation(QThread *helperThread) {
 // Still on the main thread
 ui->statusLabel.setText(tr("Running"));

 const QString input = ui->userInput.text();

 co_await QCoro::moveToThread(helperThread);
 // Now we are running in the context of the helper thread, the main thread is not blocked

 // It is safe to use `input` which was created in another thread
 doSomeComplexCalculation(input);

 // Move the execution back to the main thread
 co_await QCoro::moveToThread(this->thread());
 // Runs on the main thread again
 ui->statusLabel.setText(tr("Done"));
}

Read the documentation for QCoro::moveToThread for more details.

Full changelog

See changelog on Github

KDE's getting started page on documentation states:

KDE documentation is written in DocBook XML.

Historically, this was probably a good decision. Who does not remember that XML was so much easier to read, parse, and work with compared to binary or virtually any propitiatory file format?

KDE is aiming to bump its major version to 6. This might be a good time to reflect whether DocBook should serve as the sole official documentation language. Well, I would like to open this to an optional second language.

I don't mind what the second language could be; possible candidates are reStructuredText / Sphinx, Markdown, AsciiDoc -- among others. I don't want to convert DocBook to any other format. But giving projects some choice, might help.

I am by far not the only person with regard to a replacement of DocBook: DigiKam recently switched to Sphinx for their user documentation after 20 years of using DocBook. Krita uses Sphinx for five years and Kdenlive for over a year. By the way, the Linux kernel left DocBook for Sphinx, too.

What do you think? This would be a good topic for an Akademy BoF. Where should we discuss this in the meantime?

The XRechnung format is a E-Government standard for electronic invoicing. At some point it will be mandatory for every company dealing with German governmental partners to send the invoices in this XML format.

Many commercial vendors have already caught up and provide ways to generate XRechnung formatted documents with their software. However, to my knowledge, the availability of open source end user software is very limited. Since the standard itself is at least very open and transparently documented, so I think it is worthwhile to also support it with free software on the desktop.

Kraft, the desktop software for invoicing and efficient office work in the small enterprise, supports export of XRechnung documents since a while.

Over the weekend I created a new little project that adds a viewer for XRechnung documents called xrview.

A german city was looking for something to evaluate processes in a Linux- and KDE based productivity work environment.

Technically it is not very sophisticated: It renders the provided XML file using XSL styles officially provided by the Koordinierungsstelle für IT-Standards in a two step process to HTML, which is displayed in a web view. Some values of interest are extracted from the XML and displayed in a detail pane on the left side.

This is just a POC and has to be continued, but the time was good to kickstart this project.

Maybe anybody is interested to create a PR to help to improve digitalization in Germany?

It has been a while since the last blog post covering Qt OPC UA news. This short update will outline what we have primarily worked on in 2022.

Continue reading Qt OPC UA news catch up at basysKom GmbH.

New year, new digiKam Recipes book release. The new version features the completely rewritten Tag faces with the Face Recognition feature chapter and an all-new example workflow section in the Batch process photos and RAW files chapter. Several chapters have been revised and improved, including Edit tags with Tag Manager, Color management in digiKam, and Move digiKam library and databases. All screenshots have been refreshed, too. As always, the new revision includes plenty of tweaks and fixes.

We at the @kde-sig are happy to announce we have created a COPR repository which currently contains the KDE Plasma 5.27.0 Beta (aka: 5.26.90).

We intend to use this COPR repository in the future for KDE beta releases so that those Fedora users who want to help the KDE Community can test and report bugs to the KDE developers.

Enabling this COPR repository is very simple:

sudo dnf copr enable @kdesig/kde-beta
sudo dnf update

Your system should now have the Plasma Beta:

For our users using Kinoite, you should check out this blog post by @siosm

That’s all for now.

Feel free to join us at our Matrix room!.