Online publication of the documentation for many KDE applications has been updated to docs.kde.org. Tellico’s current handbook can be found there.

A surprising long time passed since my last status update about KJournald. So it’s time again to shed some light on the recent changes.

KJournald is a KDE project that provides graphical browsing UI for journald log databases. For those who never heard the term “journald”, journald is the system logging service of systemd and it is found in most modern Linux systems. This means, in the journald databases one can find all the system log messages about important incidents happening on a system, which make it very important for system admins but also for all technical users who want to analyze when something is not working correctly on their systems.

The kjournald-browser provides a Qt and Kirigami based UI to efficiently browse and filter those logs (note: there exist different tools for that, even systemd provides its own command line tool “journalctl”). The focus of kjournald-browser are the following use cases:

• ease filtering of log messages in order to efficiently reduce huge logs to sizes that a human can analyze
• ease analysis of interactions of different processes / systemd units by colorizing and other graphical helps
• provide a simple but powerfull UI/UX that focuses on log analysis
• support access for local, collected and remote journald logs (and do this only for journald)

Since my last blog post, the kjournald-browser application became part of the regular KDE gear releases and nowadays is packages by e.g. Fedora and Suse; unfortunately, it is still not packaged on Debian or Ubuntu yet — if you want to do it and need support please reach out to me! At the moment, also the packaging as Flatpak application on Flathub is ongoing. But already since a long time though, the KDE Flatpak nightly builds provide the latest state of the app.

With the last major release 25.12.0, a few new cool features were added:

• systemd differentiates between system service and user service and log messages are split. With the last release User Journals can be accessed in addition to System Journals.
• The search bar was reworked (more compact UI, additional case-insensitive search)) and now a history of recent search subjects is stored for faster access.
• KJournald-browser can not only used to load the log files from the local system but also to access arbitrary journald databases (e.g. collected from embedded devices for post-mortem analysis or from servers). For this loading mechanism, an improved UI database loading errors feedback is now available the validates access to loaded files.

One feature was slightly too late for this release, but is already ready for the next:

• systemd provides the feature to use service templates, which means that every service instance has its own ID. Especially for user services that is a much used feature and this clutters the UI much. A new service grouping feature allows to group service logs by template name (this is also the default, but behavior can be selected in UI).

Since 2026 is still young, there are a few features on the roadmap of this year. The two most important ones in my opinion are:

• adding access to the journald remote access protocol, which will be important to live-monitor servers or embedded devices that have a systemd-journal-remote service running
• introduce pre-filtering of processes and units for the selected boot id, which will improve usability for very long journals

Welcome to a new issue of This Week in Plasma!

Let’s thank Lubos Krystynek, Rafal Krawczyk, and John Veness for stepping up to help with this week’s issue. Thanks, guys!

This week, the first car running KWin won the “Car of the Year” award. Yes, really — KDE in the car! Here’s KDE’s Victoria Fischer talking about it at Qt World Summit 2023:

Almost all of these posts end with “KDE has become important in the world…” and I think this is a good reminder that it’s true, not just some empty platitude. KDE is important. And all of you building or using KDE’s software are important, too.

But KDE is not only important to cars; we’re incredibly important to computers! And on that subject, some really nice features and user interface improvements landed for the upcoming Plasma 6.6 release. The hard feature freeze is coming up soon, at which point we’ll move into full bug-fixing and polishing mode.

But until then, enjoy some juicy new goodies! Check it out:

Notable New Features

Plasma 6.6.0

You can now save your current visual settings as a new global theme! (Vlad Zahorodnii, plasma-desktop MR #6097)

Added a “Forget device” action to the Bluetooth system tray widget, allowing users to remove paired devices without opening System Settings. (Andrew Gigena, KDE Bug #434691)

You can now search for processes in System Monitor based on their full command-line invocation when the “Command” column is visible. (Alexey Rochev, KDE Bug #448331)

On supported systems, the logout screen now mentions when the system will restart into a different operating system or boot option after it reboots. (Nikolay Kochulin, plasma-workspace MR #5469)

Notable UI Improvements

Plasma 6.6.0

The Power and Battery widget now tells you what specific power management actions apps are blocking, instead of assuming that they’re all blocking both sleep and screen locking. (Jakob Petsovits, KDE Bug #418433)

System Settings’ Thunderbolt page now hides itself when the device doesn’t support Thunderbolt. (Alexander Wilms, plasma-thunderbolt MR #47)

When there are many windows open, the Task Manager widget will now scroll to the active one when you open its window thumbnail list. (Christoph Wolk, KDE Bug #499716)

Notifications no longer waste space showing the same icon in two places. (Kai Uwe Broulik, plasma-workspace MR #6151)

Spectacle now remembers the size (and on X11, also the position) of its main window across launches. (Aviral Singh, KDE Bug #499652)

Made multiple UI improvements to the “Configure Columns” dialog in System Monitor. (Arjen Hiemstra, plasma-systemmonitor MR #405)

In the Weather Report widget, when a weather station isn’t reporting the current wind speed, the widget now says it doesn’t know the wind speed, rather than claiming it’s “calm”. (Tobias Fella, kdeplasma-addons MR #969)

The Kickoff Application Menu widget now does a better job of handling a huge number of favorite apps. Now the favorites column eventually becomes scrollable, instead of letting icons overlap. (Christoph Wolk, KDE Bug #424067)

You can now find System Settings’ Wallpaper page by searching for “desktop background” and some other related terms. (Shubham Arora, plasma-workspace MR #6152)

Frameworks 6.23

Made it possible to see more items at once in the “Get New [thing]” dialogs. (Nate Graham, frameworks-knewstuff MR #380)

Open/Save dialogs now use relative-style date formatting for recent dates and times, which matches how Dolphin shows them. (Méven Car, frameworks-kio MR #2103)

Folders that show thumbnails of their contents now refresh the thumbnail immediately when any of those files are removed. (Akseli Lahtinen, KDE Bug #497259)

Notable Bug Fixes

Plasma 6.5.5

Fixed a strange issue that broke key repeat only in the Brave web browser. (Nicolas Fella, KDE Bug #513637)

Fixed an issue that could make the panel configuration dialog appear on the wrong screen with certain panel and screen arrangements. (Aleksey Rochev, plasma-workspace MR #6140)

Fixed two issues with the “Show Alternatives” popup: one that made it get cut off outside of the screen area for widgets positioned on certain areas of the desktop, and another that made it not disappear when it lost focus. (Aleksey Rochev, KDE Bug #511188 and KDE Bug #511187)

Plasma 6.6.0

Fixed an issue that made Plasma quit when you disconnected the last screen. (Xaver Hugl, KDE Bug #513003)

Fixed an issue with the Applications table on System Monitor’s Overview page being blurry with certain scale factors. We had already previously fixed this, but it turned out there were more remaining cases where it still happened, so this should take care of the rest! (Arjen Hiemstra, KDE Bug #445759)

Notable in Performance & Technical

Plasma 6.6.0

Implemented support in Plasma for the up-and-coming oo7 Secret Service provider. (Marco Martin and Harald Sitter, plasma-workspace MR #6109)

Fixed a hilarious issue that caused the wallpaper to bounce a tiny bit with certain fractional scale factors on secondary screens using direct scan-out while on a very recent kernel version. (Xaver Hugl, KDE Bug #513277)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by directly getting involved. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist.

For example, helping out to write these posts is warmly appreciated. Anyone interested in getting involved should check out the evolving documentation on the topic.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

QtNat is a lightweight C++ library built with Qt 6 that simplifies NAT port mapping using UPnP (Universal Plug and Play). It is designed to help developers easily expose local services to external networks without requiring manual router configuration for users.

By leveraging UPnP, QtNat automatically communicates with compatible routers to create port forwarding rules at runtime. This makes it particularly useful for peer-to-peer applications, multiplayer games, remote access tools, and any software that needs reliable inbound connectivity behind a NAT.

QtNat provides a simplified API to do all steps automatically: discovery and mapping. This has been tested on my local device. Feel free to test it and improve it.

Use it

    UpnpNat nat;

    QObject::connect(&nat, &UpnpNat::statusChanged, [&nat, &app]() {
        switch(nat.status())
        {
        case UpnpNat::NAT_STAT::NAT_IDLE:
        case UpnpNat::NAT_STAT::NAT_DISCOVERY:
        case UpnpNat::NAT_STAT::NAT_GETDESCRIPTION:
        case UpnpNat::NAT_STAT::NAT_DESCRIPTION_FOUND:
            break;
        case UpnpNat::NAT_STAT::NAT_FOUND:
            nat.requestDescription();
            break;
        case UpnpNat::NAT_STAT::NAT_READY:
            nat.addPortMapping("UpnpTest", nat.localIp(), 6664, 6664, "TCP");
            break;
        case UpnpNat::NAT_STAT::NAT_ADD:
            qDebug() << "It worked!";
            app.quit();
            break;
        case UpnpNat::NAT_STAT::NAT_ERROR:
            qDebug() <<"Error:" <<nat.error();
            app.exit(1);
            break;
        }
    });

    nat.discovery();

1. We create the object (l:0)
2. We connect to statusChanged signal to get notified (l:2)
3. When status is NAT_FOUND, we request the description (l:11)
4. When status is NAT_READY, we request the port mapping (l:14)
5. When status is NAT_ADD, It means the port mapping request has been added, It worked! The application quits.(l:17)
6. When status is NAT_ERROR, Error occured and display the error text. The application exits on error. (l:21)
7. We connect to error changed in order to detect errors. (l:14)
8. We start the discovery. (l:28)

Technical explainations

The discovery

Basically, we need to know if there is a upnp server around. To do so, we send an M-SEARCH request on the multicast address.

Here is the code:

#define HTTPMU_HOST_ADDRESS "239.255.255.250"
#define HTTPMU_HOST_PORT 1900
#define SEARCH_REQUEST_STRING "M-SEARCH * HTTP/1.1\n"            \
                              "ST:UPnP:rootdevice\n"             \
                              "MX: 3\n"                          \
                              "Man:\"ssdp:discover\"\n"          \
                              "HOST: 239.255.255.250:1900\n"     \
                                                            "\n"
void UpnpNat::discovery()
{
    setStatus(NAT_STAT::NAT_DISCOVERY);
    m_udpSocketV4.reset(new QUdpSocket(this));

    QHostAddress broadcastIpV4(HTTPMU_HOST_ADDRESS);

    m_udpSocketV4->bind(QHostAddress(QHostAddress::AnyIPv4), 0);
    QByteArray datagram(SEARCH_REQUEST_STRING);

    connect(m_udpSocketV4.get(), &QTcpSocket::readyRead, this, [this]() {
        QByteArray datagram;
        while(m_udpSocketV4->hasPendingDatagrams())
        {
            datagram.resize(int(m_udpSocketV4->pendingDatagramSize()));
            m_udpSocketV4->readDatagram(datagram.data(), datagram.size());
        }

        QString result(datagram);
        auto start= result.indexOf("http://");

        if(start < 0)
        {
            setError(tr("Unable to read the beginning of server answer"));
            setStatus(NAT_STAT::NAT_ERROR);
            return;
        }

        auto end= result.indexOf("\r", start);
        if(end < 0)
        {
            setError(tr("Unable to read the end of server answer"));
            setStatus(NAT_STAT::NAT_ERROR);
            return;
        }

        m_describeUrl= result.sliced(start, end - start);

        setStatus(NAT_STAT::NAT_FOUND);
        m_udpSocketV4->close();
    });

    connect(m_udpSocketV4.get(), &QUdpSocket::errorOccurred, this, [this](QAbstractSocket::SocketError) {
        setError(m_udpSocketV4->errorString());
        setStatus(NAT_STAT::NAT_ERROR);
    });

    m_udpSocketV4->writeDatagram(datagram, broadcastIpV4, HTTPMU_HOST_PORT);
}

The whole goal of the discovery is to get the description file from the server with all available devices and services. The result is stored in m_describeUrl.

Request Description file

Simple request using QNetworkAccessManager.

void UpnpNat::requestDescription()
{
    setStatus(NAT_STAT::NAT_GETDESCRIPTION);
    QNetworkRequest request;
    request.setUrl(QUrl(m_describeUrl));
    m_manager.get(request);
}

Parsing Description file

Your physical network device may act as several Upnp devices. You are looking for one of these device type:

• urn:schemas-upnp-org:device:InternetGatewayDevice
• urn:schemas-upnp-org:device:WANDevice
• urn:schemas-upnp-org:device:WANConnectionDevice

Those type are followed with a number (1 or 2), It is the Upnp protocol version supported by the device.

void UpnpNat::processXML(QNetworkReply* reply)
{
    auto data= reply->readAll();

    if(data.isEmpty()) {
        setError(tr("Description file is empty"));
        setStatus(NAT_STAT::NAT_ERROR);
        return;
    }

    setStatus(NAT_STAT::NAT_DESCRIPTION_FOUND);

    /*
     Boring XML parsing in order to find devices and services.
     Devices:
        constexpr auto deviceType1{"urn:schemas-upnp-org:device:InternetGatewayDevice"};
        constexpr auto deviceType2{"urn:schemas-upnp-org:device:WANDevice"};
        constexpr auto deviceType3{"urn:schemas-upnp-org:device:WANConnectionDevice"};

     Services:
        constexpr auto serviceTypeWanIP{"urn:schemas-upnp-org:service:WANIPConnection"};
        constexpr auto serviceTypeWANPPP{"urn:schemas-upnp-org:service:WANPPPConnection"};  
     */

     m_controlUrl = /* Most important thing to find the controlUrl of the proper service.*/

    setStatus(NAT_STAT::NAT_READY);
}

Send mapping Request

Sending a request is just sending HTTP request with the proper data.

I use inja to generate the http data properly.

This is the inja template.

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
  xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
  s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:AddPortMapping
      xmlns:u="{{ service }}">
      <NewRemoteHost></NewRemoteHost>
      <NewExternalPort>{{ port }}</NewExternalPort>
      <NewProtocol>{{ protocol }}</NewProtocol>
      <NewInternalPort>{{ port }}</NewInternalPort>
      <NewInternalClient>{{ ip }}</NewInternalClient>
      <NewEnabled>1</NewEnabled>
      <NewPortMappingDescription>{{ description }}</NewPortMappingDescription>
      <NewLeaseDuration>0</NewLeaseDuration>
    </u:AddPortMapping>
  </s:Body>
</s:Envelope>

Then, let’s create a json object with all data. As final step, we need to create a request, set its data, and then post it.

void UpnpNat::addPortMapping(const QString& description, const QString& destination_ip, unsigned short int port_ex,
                             unsigned short int port_in, const QString& protocol)
{
    inja::json subdata;
    subdata["description"]= description.toStdString();
    subdata["protocol"]= protocol.toStdString();
    subdata["service"]= m_serviceType.toStdString();
    subdata["port"]= port_in;
    subdata["ip"]= destination_ip.toStdString();

    auto text= QByteArray::fromStdString(inja::render(loadFile(key::envelop).toStdString(), subdata));

    QNetworkRequest request;
    request.setUrl(QUrl(m_controlUrl));
    QHttpHeaders headers;
    headers.append(QHttpHeaders::WellKnownHeader::ContentType, "text/xml;  charset=\"utf-8\"");
    headers.append("SOAPAction", QString("\"%1#AddPortMapping\"").arg(m_serviceType));
    request.setHeaders(headers);
    m_manager.post(request, text);
}

Finally, just check the answer

The reply has no error, it worked, the status changes to NAT_ADD. Otherwise, the status changes to error.

void UpnpNat::processAnswer(QNetworkReply* reply)
{
    if(reply->error() != QNetworkReply::NoError)
    {
        setError(tr("Something went wrong: %1").arg(reply->errorString()));
        setStatus(NAT_STAT::NAT_ERROR);
        return;
    }
    setStatus(NAT_STAT::NAT_ADD);
}

Don’t hesitate to test it on your own device. Just to validate, it works everywhere. Any comment or change request, please use Github for that.

Source code

December was quite an eventful month for me, with over 4,000 km travelled by train. This was in part caused by the holidays and visiting family, but also by the KDE PIM sprint in Paris and the 39th Chaos Communication Congress.

KDE PIM sprint in Paris

From the 12th to the 14th of December, I was in Paris. It was actually my first time there for more than a day trip, so I arrived a day earlier to explore the city a bit. I went on a walk across the city with Tobias and Nicolas, and I took some photos.

The weekend was also very productive. We advanced our goal of making KMime a proper KDE Framework; made Message-IDs in emails more privacy-conscious; and discussed various important topics such as the retirement of the Kolab resource and the switch to SQLite as the default backend for Akonadi.

Huge thanks to enioka Haute Couture for having us in their office in Paris.

The sprint being in Paris also allowed me to afterward go visit my grandma, 350 km further south of Paris, so this was particularly convenient.

39th Chaos Communication Congress (39c3)

Another event I went to was 39c3, which is the third year in a row that I attended, and this year again we had an assembly as part of the Bits und Bäume umbrella, thanks to Joseph.

I love the vibe of this event. It’s not very dry or only tech-focused, but also has a big artistic and political aspect to it. And while the number of attendees is very large, at the same time it’s very chill and I don’t feel overwhelmed, unlike at FOSDEM.

At the KDE assembly, we met a lot of interested users, some GNOME friends, and since a bunch of KDE devs were there, we managed to work on a few productive things, like switching the map backend from Itinerary to MapLibre.

And this year, I even managed to go on national TV for a few seconds to speak about Nextcloud. My German grandma called me the day afterward, very happy to have seen me.

With the start of the new year, I am very happy to announce the release of version Kraft 2.0.0.

Kraft provides effective invoicing and document management for small businesses on Linux. Check the feature list.

This new version is a big step ahead for the project. It does not only deliver the outstanding ports to Qt6 and KDE Frameworks 6 and tons of modernizations and cleanups, but for the first time, it also does some significant changes in the underlying architecture and drops outdated technology.

Kraft now stores documents not longer in a relational database, but as XML documents in the filesystem. While separate files are more natural for documents anyway, this is paving the way to let Kraft integrate with private cloud infrastructures like OpenCloud or Nextcloud via sync. That is not only for backup- and web-app-purposes, but also for synced data that enables to run Kraft as distributed system. An example is if office staff works from different home offices. Expect this and related usecases to be supported in the near future of Kraft.

But there are more features: For example, the document lifecycle was changed to be more compliant: Documents remain in a draft status now until they get finalized, when they get their final document number. From that point on, they can not longer be altered.

There is too much on the long Changes-List to mention here.

However, what is important is that after more than 20 years of developing and maintaining this app, I continue to be motivated to work on this bit. It is not a big project, but I think it is important that we have this kind of “productivity”-applications available for Linux to make it attractive for people to switch to Linux.

Around Kraft, a small but beautiful community has built up. I like to thank everybody who contributed in any way to Kraft over the years. It is big fun to work with you all!

If you are interested, please get in touch.

A new whiteboard app, Vector-based map rendering in Itinerary, and new releases

Welcome to a new issue of "This Week in KDE Apps"! Every week (or so) we cover as much as possible of what's happening in the world of KDE apps.

We kick off the year with everything that's new in the KDE App scene. Let's dig in!

Travel Applications

KDE Itinerary Digital travel assistant

Jonah Brüchert added a MapLibre-based backend to Itinerary maps views. This allows us to render vector-based tiles, which means they can be displayed at any size without visible pixels. Zooming in and out should also be much smoother. Another advantage is that the map now shows labels in the local language as well as English. This makes the map much more useful in case you cannot read a locally used script. In the future, we might even be able to use map tiles that can display labels in your preferred language. (26.04.0 - pim/itinerary MR #454)

Carl Schwan ported multiple dialogs to a convergent dialog/bottom drawer style (26.04.0 - pim/itinerary MR #413 and pim/itinerary MR #464).

Volker Krause added support for marking reservations as cancelled in your timeline, so that these reservations are not counted in your yearly statistics (26.04.0 - link).

Luca Weiss updated the KLM boarding passes extractor to also extract the boarding group (25.12.1 - pim/kitinerary MR #205). Thomas Arrow added an extractor for KLM's "Ticket for your trip" emails (25.12.1 - pim/kitinerary MR #206).

Tobias Fella added support for extracting GOMUS annual tickets (25.12.1 - pim/kitinerary MR #207).

PIM Applications

KMail A feature-rich email application

Albert Astals Cid made KMail's system tray icon also work when KMail is run inside Kontact (26.04.0 - pim/kmail MR #187).

Office Applications

Okular View and annotate documents

Cody Neiman fixed the extreme downscaling of custom stamps, which resulted in pixelated stamp annotations (25.12.1 - graphics/okular MR #1280).

Creative Applications

Drawy Your handy, infinite brainstorming tool

Thanks to Prayag Jain, KDE has a new whiteboard app called Drawy! It combines a simple interface with an infinite canvas, giving users the freedom to think and draw without limits.

Some of its features are:

• An infinite canvas with no drawing constraints
• Support for drawing tablets and touchscreens
• Tools to group and ungroup items on the canvas
• A text tool for typing notes

Drawy is still under development, but you can already download a nightly flatpak. You are invited to test the app and share feedback to help shape Drawy as your handy, infinite brainstorming tool!

Since the incubation started, Prayag Jain has been fixing various performance issues (graphics/drawy MR #108 and graphics/drawy MR #115), and Laurent Montel did a lot of code cleanup to follow KDE best practices more closely (link).

Utilities Applications

Konsole Use the command line interface

Leonardo Malaman added a new "Force New Tabs" option to Konsole. This forces Konsole to open a new tab in an already open Konsole window instead of opening a new window (utilities/konsole MR #1112).

Kate Advanced text editor

Christoph Cullmann added out-of-the-box support for neocmakelsp, an LSP server for CMake (26.04.0 - utilities/kate MR #1974).

KAIChat AI Chat

Laurent Montel released KAiChat 0.6.0. This release introduces Wikipedia and weather integration, the capability to copy block code to the clipboard, and a quick search widget.

Network Applications

NeoChat Chat on Matrix

Károly Veres unified the space selection logic, so that using the quick switcher or clicking on a notification to jump to a room will now switch to correct space (26.04.0 - network/neochat MR #2551).

Nate Graham improved the hamburger menu button. Now the menu opens right beneath the button, the button has a pressed state while the menu is open, and the menu will close when clicking on the button again. (26.04.0 - network/neochat MR #2553)

Azhar Momin added a button to cycle through unread highlights (26.04.0 - network/neochat MR #2552).

Joshua Goins re-arranged the profile dialog and grouped similar actions together (26.04.0 - network/neochat MR #2544). And he made it possible to view the profile dialog when receiving an invitation (26.04.0 - network/neochat MR #2548).

Tobias Fella added some fixes for the new version of Matrix rooms (26.04.0 - network/neochat MR #2550).

Kaidan Modern chat app for every device

Melvin Keskin released Kaidan 0.14.0. This release allow you to resend failed messages via the context menu, cancel and restart uploads, join group chats or add contacts by their XMPP URIs, and improves compatibility for servers using LDAP.

System Applications

KCron Task Scheduler

Alexander Wilms fixed running commands containing spaces in their path (26.04.0 - system/kcron MR #46).

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out This Week in Plasma, which covers all the work being put into KDE's Plasma desktop environment every Saturday.

For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.

Get Involved

The KDE organization has become important in the world, and your time and contributions have helped us get there. As we grow, we're going to need your support for KDE to become sustainable.

You can help KDE by becoming an active community member and getting involved. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer either. There are many things you can do: you can help hunt and confirm bugs, even maybe solve them; contribute designs for wallpapers, web pages, icons and app interfaces; translate messages and menu items into your own language; promote KDE in your local community; and a ton more things.

You can also help us by donating. Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general just keep KDE bringing Free Software to the world.

To get your application mentioned here, please ping us in invent or in Matrix.

A few days ago I attended the 39th Chaos Communication Congress (39C3) in Hamburg, Germany, as part of the KDE presence there.

KDE

Like at 38C3 in the previous year we had a small KDE assembly as part of the Bits & Bäume Habitat.

There were two talks with KDE contributors in the main program:

• Bettina, Caro and Joseph from KDE Eco presented their work on the “End of 10” campaign.
• Shinjo spoke about security breaches at South Korean telco operators.

The End of 10 campaign also had organized a meetup and a install party.

As Jonah has already reported we got very positive feedback from attendees about KDE’s work.

Itinerary

Itinerary was a frequent discussion topic for me, both with the KDE team and attendees in general.

• The MapLibre-based vector tile map integration got pushed over the finishing line (see also Jonah’s report).
• Reaching the end of the year and people being interested in their travel wrap-up, a few issues regarding handling of cancelled reservations in the statistics got fixed. And as people’s trip lists are growing longer and longer that also got a better grouping.
• We talked about possible ways to improve the stop picker, in particular the country selector which is becoming increasingly annoying to use as it gets longer and longer as Transitous coverage keeps expanding.
• Ideas for a better first-start onboarding page.
• We need to investigate whether we handle Zügli’s ticket revocations correcty that were mentioned in the Deutschlandticket fraud investigation talk.

Android

I also had the opportunity to talk to developers of F-Droid and other FOSS Android applications, who share a lot of the pain we are also dealing with in bringing KDE applications to Android.

A big concern especially for people not associated with a bigger umbrella organization is the upcoming requirements by Google for developer verification. While KDE might be less affected by this directly, any negative effect on the larger FOSS ecosystem is of course also bad for us. The continuous close-down of AOSP development is also not helping, making it significantly harder for Google-free Android variants.

None of that is entirely surprising, and it increases the pressure on fully open Linux systems becoming a viable alternative on more mobile devices. Both that as well as collaboration on adjacent infrastructure such as fully open push notification infrastructure has been making good progress in 2025 fortunately.

Transitous

We had a Transitous meetup on the last day at Wikimedia’s assembly, hosted by Jonah, Julius and myself. We should organize and announce this earlier next time, but the space was nevertheless full. Meeting notes are in the wiki.

We had quite a few conversations around Transitous beyond this as well:

• It looks like we should be able to get SIRI-FM data for a number of operators in Germany in Q1 2026. That’s facility monitoring information such as current or planned elevator outages, something highly relevant for wheelchair routing.
• We talked about finding better ways to maintain data augmentation than the currently used MOTIS Lua scripts. While there’s options on where to store such information (e.g. Wikidata or OSM), the main challenge is matching GTFS data lacking stable identifiers to such an external data set.
• We met with the team behind esel.ac, a community-run bike sharing system in Aachen. It’s using OpenBike and produces a GBFS feed that we now also have in Transitous. Community-run mobility services and a community-run routing service are of course the perfect match, and I’d like us to use those cases to showcase what the whole stack of open standards, open hardware and open software can do together. We discussed possible extensions to the GBFS feed such as booking links, geo fencing zones and return constraints for this.
• There was some prototyping towards using Wikidata as a source of “temporary POIs” for Transitous. That’s events that are tied to a specific location (e.g. a conference) which then can be used as a destination for routing. We managed to produce an abomination of a SPARQL query that resulted in a technically valid set of events. However we haven’t found a proper solution yet for reliably excluding events we would not want in there, such as those of fascist parties.
• There’s people working on implementing deck layouts in NeTEx. While motivated by accessibility and seat booking, this could provide us with train coach layouts as a byproduct as well. There’s public transport operators involved, so this is hopefully not just theory but also going into production in the not too distant future.

It also looks like we might have another iteration of the Transitous Hack Weekend in Berlin, next weekend already (January 9-11). That’s very short notice and not entirely finalized yet. If you are interested in joining please get in touch in the Transitous Matrix channel.

OSM

The OSM assembly was conveniently directly next to the KDE one, so I could easily drop into conversations about indoor mapping, indoor routing or indoor positioning there. Interest in all parts of this seems to be increasing, we probably should improve the introduction material for this a bit.

There’s also a plan to have an (offline) meeting in the next months to get some of the pending tagging proposals and open questions e.g. around “thick” walls, stairs and fractional levels sorted out and over the finishing line.

We also had the opportunity to discuss the FOSSGIS e.V. becoming a possible umbrella organization for Transitous and/or the Open Transport Community Conference. Especially the latter is becoming slightly more pressing as we got a few sponsorship offers while looking for a venue, and that’s something we can only make use of with an organization behind us that can actually handle money.

Weather and Emergency Alerts

I also met with FOSSWarn to discuss the next steps on the public alert distribution server:

• Better monitoring to notice system failures, task queue backlogs, source feed outages, increasing parser or push notification submission error rates, or suspiciously large subscription areas. As a byproduct this might also provide interesting insights in the alert data.
• Better ways to deal with rate limits on push servers. This needs to be ultimately resolved at those servers, as public alerts are very prone to produce notification bursts. This is also a blocker for scaling this up further and e.g. deploying this in a default KDE Plasma installation.
• Performance improvements for the alert area vector tile generation. That wasn’t a focus initially as this was meant purely as a diagnostic tool, but it has become popular to the point that FOSSWarn wants to integrate this directly into the app. This will probably require geometry simplification on ingested “inline” CAP geometry, which would benefit everyone by smaller and cheaper to parse/render CAP data.

You can help!

Events like Chaos Communication Congress are enormously useful for bringing together, connecting and enabling collaboration between people from different areas or initiatives. The sheer size and diverse set of attendees help a lot with that.

Attending events however incurs cost for travel, accommodation and entrance. Your donation to organizations like KDE e.V. or FOSSGIS e.V. support such activities.

This post will show the NixOS way of adding a custom package and explain the benefits of this approach in the context of system immutability.

Plasma Pass

KDE Ni! OS recently got a new package installed by default – Daniel Vrátil’s Plasma Pass applet.

Plasma Pass is a Plasma applet to access passwords from pass, the standard UNIX password manager. You can find more information about the applet in Dan’s blog post.

As NixOS doesn’t currently offer Plasma Pass in its repositories, the package is installed in Ni! OS from the sources as in some other BTW, I use … distributions.

In NixOS, this is easily done via overlays. We can create an overlay that defines the plasma-pass package so that it can be installed as if it were a real NixOS package.

Package definition

This is the overlay definition used in Ni! (ni/packages/plasma-pass.nix):

self: prev: {
  kdePackages = prev.kdePackages.overrideScope (kdeSelf: kdeSuper: {
    plasma-pass = kdeSelf.mkKdeDerivation rec {
      pname = "plasma-pass";
      version = "1.3.0-git-59be3d64";

      src = prev.fetchFromGitLab {
        domain = "invent.kde.org";
        owner = "plasma";
        repo = "plasma-pass";
        rev = "59be3d6440b6afbacf466455430707deed2b2358";
        hash = "sha256-DocHlnF9VJyM1xqZx/hoQVMA/wLY+4RzAbVOGb293ME=";
      };

      buildInputs = [
        kdeSelf.plasma-workspace
        kdeSelf.qgpgme
        self.oath-toolkit
      ];

      meta = with prev.lib; {
        description = "Plasma applet for the Pass password manager";
        license = licenses.lgpl21Plus;
        platforms = platforms.linux;
      };
    };
  });
}

Most of this file is self-explanatory (except for the strange looking syntax of the Nix language :) ).

Since Plasma Pass is a KDE project, we want it visible as a part of kdePackages collection, and as it uses the common build setup that all KDE projects use (or should use), it uses mkKdeDerivation to define the plasma-pass package. This defines some basic dependencies, commonly used by KDE projects and adaptations needed for them to work properly in NixOS. For non-KDE-friendly packages, you’d base your package on the standard mkDerivation instead.

The project sources are located on the KDE’s GitLab instance at invent.kde.org, therefore the package definition uses fetchFromGitLab to retrieve the sources. It is also possible to clone repositories on GitHub, fetch and use source tarballs, etc. All fetchers are described at NixOS Manual > Fetchers.

The rev field in the fetchFromGitLab command is the GIT revision that you want to install, and hash you can get by using the nix-prefetch-git command:

nix shell nixpkgs#nix-prefetch-git
nix-prefetch-git https://invent.kde.org/plasma/plasma-pass \
    --rev 59be3d6440b6afbacf466455430707deed2b2358

The buildInputs part defines additional dependencies needed by Plasma Pass, and meta defines some meta information about the package such as the description and the license.

Using the definition

After defining the package, we have to add it to nixpkgs.overlays in any of our NixOS configuration files. In the case of Ni! OS, this is done in ni/modules/base.nix which defines the UI software that Ni! OS installs by default.

nixpkgs.overlays = [
    (import ../packages/plasma-pass.nix)
  ];

With this overlay, plasma-pass can be used as if it was a normal NixOS package.

environment.systemPackages = with pkgs; [
  ...
  kdePackages.plasma-pass
  ...
  ];

When plasma-pass gets added to the nixpkgs repository, the only action that will be needed in Ni! OS to switch to the official version is to remove the import...plasma-pass.nix from the overlays (this is the reason why we explicitly placed it in kdePackages collection – otherwise, we could have just put it top-level).

Custom packages and immutability

The main point of this post is not really to announce that a single new package is added to the Ni! OS setup. Even if it is a cool one like Plasma Pass.

The point is to show how a custom package that is not available in the vast collection of nixpkgs can be added to a NixOS-based system.

The custom package becomes a proper regular Nix package and gets all the benefits of Nix’s particular approach to immutability. If Plasma Pass gets broken after an update (either if new Plasma version breaks Plasma Pass, or if the new version of Plasma Pass no longer works as expected), you can always boot into the version before the bad update.

With distributions with immutable core and custom applications installed as Flatpaks, downgrading is possible, but a bit more involved and relies on 3rdparty keeping the old package versions still available for download.

With NixOS, all the previous versions remain on your system until you decide to remove them.