Updates in the project in 2024 and the first half of 2025

The Plasma Mobile team is happy to announce the developments in the project over the past few months!

Housekeeping

This blog post was completed much later than originally planned. In the meantime, several releases have taken place:

• Plasma 6.1 (June 2024) changelog
• Plasma 6.2 (October 2024) changelog
• Plasma 6.3 (February 2025) changelog
• Plasma 6.4 (June 2025) changelog

This blog post is already quite long, so it will omit changes merged for Plasma 6.5 (releasing in October, to be announced in a future post).

With the Plasma 6.2 release, we moved Plasma Dialer and Spacebar to the Plasma release cycle, allowing us to have consistent releases of the two apps. This completes our year long move to having all Plasma Mobile related projects released as part of wider KDE releases, streamlining the work for distributions and taking a load off us on having to maintain a separate release cycle!

In other news, a Fedora spin for Plasma Mobile was released! It will only be targeting devices that can currently boot Fedora (i.e. not ARM phones), but is very exciting nonetheless! Read more about it here, and get it here.

Plasma Sprint

In May, we attended the Plasma developers' sprint in Graz, Austria! Read more about what we did from the blogs below:

• Bhushan Shah's blog post
• Devin Lin's blog post
• Luis Büchi's blog post

NGI0 Core (NLnet) funding

Bhushan recently received funding through the NGI0 Core Fund to work on the power management stack on Plasma Mobile (and Plasma as a whole)!

You can read more about this on his blog. The project details are described here.

CI

Bart added an Alpine CI to KDE infrastructure, allowing for KDE projects to ensure they build correctly for Alpine before release!

Plasma

Work continues on from the Plasma 6 release! Only major features and improvements are described below, see the Plasma release notes for the full list of changes.

Task Switcher

Luis worked on bringing back gestures to the task switcher! The implementation now uses KWin's gesture API, and has several new features over the Plasma 5 implementation:

• Swiping up fast from the bottom of the screen minimizes the app and goes to the homescreen.
• Swiping up and holding from the bottom of the screen keeps the task switcher open.
• Swiping left and right on on the bottom of the screen allows for scrubbing through the currently opened apps.
• Haptic feedback occurs during the opening gesture if releasing will open the task switcher.

(Luis Büchi, Plasma 6.2, Link 1, Link 2, Link 3, Link 4, Link 5, Link 6)

Micah further improved and refined the task switcher and gesture tracking, polishing the flow of animations and activation thresholds. (Micah Stanley, Plasma 6.2.1, Link)

Devin added support for the tasks to be sorted by last activation. (Devin Lin, Plasma 6.2, Link)

Luis added support for double tapping on the task switcher button to switch between the two most recently used apps. (Luis Büchi, Plasma 6.3, Link)

Lockscreen

The lockscreen keypad design was overhauled to use a more traditional PIN layout. It is much simpler to render and is also easier to use with one hand. (Devin Lin, Plasma 6.2, Link)

Various issues with input unresponsiveness were also fixed, as well as support for passwordless login. (Devin Lin, Plasma 6.2, Link 1, Link 2, Link 3)

The clock design was also overhauled to be larger and blend better with the wallpaper. (Micah Stanley, Plasma 6.2, Link)

Quick action buttons were also added, which are configurable to allow actions (ex. flashlight toggle) be easily accessed while the device is locked. (User8395 & Micah Stanley, Plasma 6.4, Link 1, Link 2)

Notifications

Popup notifications were fully implemented, with a refreshed look and the capability to show multiple notifications in a "stack". (Micah Stanley, Plasma 6.3, Link)

Scrolling through an overflowing notifications list was fixed. (Micah Stanley, Plasma 6.4, Link)

Various issues with the notification widget were also fixed:

• Job notifications now show up properly and are dismissable.
• Notification contents are now properly clipped as they are being dismissed.

(Devin Lin, Plasma 6.2, Link)

Homescreen (Folio)

Work continued on fixing and polishing issues in the default homescreen introduced in Plasma 6, here are some highlights:

• A search bar was added to the applications list. (Devin Lin, Plasma 6.2, Link)
• Support for touchpad interaction was added. (Devin Lin, Plasma 6.2, Link)
• An option was added to be able to lock the homescreen layout from editing. (Micah Stanley, Plasma 6.4, Link)
• State being shared between multiple displays was fixed. (Devin Lin, Plasma 6.1.3, Link 1, Link 2)
• The settings view is now closed when the home button is pressed. (Devin Lin, Plasma 6.1.5, Link)
• A button was added in the wallpaper selector to see the full wallpaper config window. (Devin Lin, Plasma 6.1.2, Link)
• A dialog was added to ask the user to confirm when deleting a folder. (Devin Lin, Plasma 6.2, Link)
• Application icons resizing to only predefined sizes was fixed. (Devin Lin, Plasma 6.2, Link)
• When an application gets deleted, user placed icons of it are also removed. (Devin Lin, Plasma 6.4, Link)
• Haptics were added to various actions on the homescreen. (Micah Stanley, Plasma 6.4, Link)
• Widgets no longer activate a popup when being held to be edited. (Florian Richer, Plasma 6.4.1, Link)

Homescreen (Halcyon)

Devin fixed situations where the favourited applications may not activate when tapped. (Devin Lin, Plasma 6.1.4, Link)

Action Drawer

An expanded mode to the music widget when tapped was added, that allows for the song position to be changed. (Florian Richer & Micah Stanley, Plasma 6.2, Link 1, Link 2, Link 3)

The action drawer can now be opened even when an application is fullscreen. (Micah Stanley, Plasma 6.3, Link)

An "overscroll" animation when the panel is fully open and the finger overshoots was added. (Micah Stanley, Plasma 6.2, Link)

A marquee for quick setting titles was added, fixing eliding with certain languages. (Athozus, Plasma 6.2, Link)

Quick settings are now hidden when they are not applicable, such as for mobile data when there is no modem. (User3895, Plasma 6.3, Link)

The order of quick settings after being adjusted from the settings is now fixed. (Florian Richer, Plasma 6.4.1, Link 1, Link 2, Link 3)

The action drawer panel now hides when screen brightness is adjusted, making it easier for the user to gauge the brightness they would like. (Micah Stanley, Plasma 6.3, Link)

A quick setting was added to be toggle whether all applications are shown in fullscreen (panels can be shown when swiping from the top/bottom). (Micah Stanley, Plasma 6.4, Link)

The screen recording quick setting is now properly ported to Plasma 6 and has been brought back. (Florian Richer, Plasma 6.2, Link)

Status Bar

The status bar height can now be resized in the settings. (Sebastian Kugler, Plasma 6.3, Link)

The status bar can now be swiped down to be shown when in a fullscreen application. (Micah Stanley, Plasma 6.3, Link)

A config option was added to toggle showing the battery percentage label. (Micah Stanley, Plasma 6.4, Link)

An optional setting to also show the date in the status bar along with the time was added. (Athozus, Plasma 6.2, Link)

Volume Popup

The design of the volume popup was overhauled, and now made to not take away focus from the currently shown application window. (Micah Stanley, Plasma 6.3, Link)

Manual Rotation Button

A button was added to the navigation panel to manually rotate the screen to the current orientation when auto-screen rotation is disabled. (Devin Lin, Plasma 6.3, Link)

A floating button with the same functionality was added to gesture mode. (Micah Stanley, Plasma 6.4, Link)

Startup Feedback

Devin overhauled the startup feedback implementation, which is the animation that shows when an application is opening:

• Windows states are now being tracked to determine when to close it, fixing issues where it would close prematurely due to losing focus.
• Startup feedback now shows up in the task switcher as a window.
• A spinner was added which is shown when applications take longer to load.
• Multiple displays are now properly supported.
• The background color algorithm was improved to tint colors darker in dark modes, avoiding a blinding flash when application icons are bright.

(Devin Lin, Plasma 6.2, Link 1, Link 2, Link 3)

Settings

The settings application is now organized into categories. (Devin Lin, Plasma Settings v25.02, Link)

A toggle was added to force showing all settings modules, even ones that are not for mobile. (Devin Lin, Plasma Settings v25.06, Link)

A traffic monitor was added to the Wi-Fi settings module for the current network connection. (Sebastian Kugler, Plasma 6.3, Link)

A vendor information card was added to the Information settings module. (Sebastian Kugler, Plasma 6.3, Link)

Some issues with setting up mobile data connections with iPv6 were fixed. (Florian Richer, Plasma 6.2, Link)

Other

Windows will not longer be able to be unmaximized outside of docked mode, especially applicable to GTK applications. (Devin Lin, Plasma 6.3, Link)

There is now an option for distributions to manually disable the logout button from the shutdown screen. (Sebastian Kügler, Plasma 6.3, Link)

Applications

Most major announcements for applications are now covered in the This Week in KDE Apps series on the main blog.

However, some mobile specific updates will still be shared here!

Angelfish (Web Browser)

Micah greatly overhauled the tab list and search bar UI/UX on mobile! New features include:

• Swiping up on the search bar now opens the tab list.
• Swiping up again closes the tab list.
• The tab list is now a fullscreen grid, with improved opening and closing animations.
• The search bar now gives a URL preview when minimized during scrolling, and touching it maximizes it.

(Micah Stanley, KDE Gear 24.08, Link 1, Link 2)

Dialer

Bhushan investigated and worked with KWin maintainers to fix a major issue where a ghost dialer window would sometimes be on top of the lockscreen. (Vlad Zahorodnii & Bhushan Shah, Plasma 6.3.5, Link)

Bhushan and Luis investigated and fixed an issue where a single incoming call may be treated as multiple calls on dual-SIM devices. (Bhushan Shah, Plasma 6.3.5, Link)

Spacebar (SMS Messenger)

Various lockup and sending/receiving issues were fixed by having the client communicate to the database solely through the server, rather than having the server and client simultaneously access it. (Devin Lin, Plasma 6.2.1, Link)

Outgoing messages sending a notification to the user was fixed. (Devin Lin, Plasma 6.3, Link)

A message in the UI now shows up if the Spacebar daemon is not running. (Devin Lin, Plasma 6.2.1, Link)

A ModemManager mocking program for SMS was created to more easily develop Spacebar without a working modem setup (as Devin encountered). (Devin Lin, Plasma 6.3, Link)

The "new chat" page UX was redesigned to be easier to understand. (Devin Lin, Plasma 6.3, Link)

SMS chat conversations can no longer be started with contacts that have no phone numbers. (Florian Richer, Plasma 6.2, Link)

Discover (Application Store)

The apk backend (for Alpine/postmarketOS) was integrated into the project, which was previously carried as a large patch downstream. This allows it to be more easily iterated on and to be improved in the future. (Devin Lin, Plasma 6.2, Link)

An Alpine CI was added to KDE infrastructure, and hooked up the apk backend to be tested. (Bart Ribbers, Plasma 6.2, Link)

QMLKonsole (Terminal)

The modifier panel can now be manually enabled/disabled by the user, regardless of whether they are on mobile or desktop. (Om Mehta, KDE Gear 25.08, Link)

The warning for closing a tab with a running task was fixed for window closing events. (Mason Jiao, KDE Gear 24.08, Link)

The keyboard not popping up when tapping the terminal area, and the keyboard button were both fixed. (Devin Lin, KDE Gear 24.08, Link)

Clock

Kai took a deep dive into the app, adding new features and polishing the UX! Here are some highlights:

• Timers now have a persistent notification to indicate status when the app isn't open. (Kai Uwe Broulik, KDE Gear 25.08, Link)
• Timers can now be edited directly without having to be recreated. (Kai Uwe Broulik, KDE Gear 25.08, Link)
• Timers can now be started, paused and reset from KRunner. (Kai Uwe Broulik, KDE Gear 25.08, Link)
• The time page now has an analog clock. (Kai Uwe Broulik, KDE Gear 25.08, Link)

Contributing

Do you want to help with the development of Plasma Mobile? We are a group of volunteers doing this in our free time, and are desperately looking for new contributors, beginners are always welcome!

See our community page to get in touch!

We are always happy to get more helping hands, no matter what you want to do, but we especially need support in these areas:

• Telephony (Calling and SMS)
• Camera
• App development (Photo Viewer, Browser, Audio Recorder, Games, etc.)
• Shell work
• You can also check out our Plasma Mobile issue tracker for more details.

Even if you do not have a compatible phone or tablet, you can also help us out with application development, as you can easily do that from a desktop!

Take Plasma Mobile for a spin! Check out the device support for each distribution and find the version which will work for your device.

If you have any further questions, view our documentation, and consider joining our Matrix channel. Let us know what you would like to work on or where you need support to get going!

Our issue tracker documentation also gives information on how and where to report issues.

This project began as a casual college game I developed in my second year, using Pygame. The idea was simple. You’re driving a car, and your job is to survive enemy attacks, collect energy to stay alive, and shoot down as many opponents as you can. The more you destroy, the higher your score.

The core gameplay loop was designed in Pygame and includes:

• A player car that moves left and right.
• Opponent cars that spawn and rush toward the player.
• Energy pickups that keep your car alive.
• Bullets using which you take down enemy cars.

Each component is managed by its respective class: MyCar, Opponent, Fire, and Explosion.

The original version used keyboard input for movement and shooting. The objective was to survive as long as possible while scoring points by destroying opponents.

While building the game, I found myself knee-deep in things I hadn’t anticipated—like why a car would randomly vanish mid-frame, or why every collision either did nothing or ended in total chaos. I spent hours tweaking bounding rectangles, trying to get explosions to appear in the right place, and making sure enemy cars didn’t spawn on top of each other. Most of my time went into figuring out how to reset things properly after a crash or making sure the game didn’t freeze when too many things happened at once. It was messy, confusing, and at times exhausting, but weirdly satisfying when everything finally came together.

Recently, I revisited this project with the idea of automating it. I wanted to see if the car could make its own decisions—to dodge, shoot, or stay put—all without human input. That’s where Monte Carlo Tree Search (MCTS) came in. Being a decision-making algorithm, it’s particularly useful in many strategic games when the search space is large and rewards are sparse or delayed—perfect for a chaotic survival game like mine.

Implementation Details

The first step was to abstract the game state into a simplified object. I created a GameState class in mcts_car_shooter.py that captures:

• My car’s x position.
• Remaining energy and current score.
• Positions and energy levels of alive opponents.
• Fire coordinates (optional) and energy pickup position.

This allowed the MCTS algorithm to run without needing to interact with the actual rendering or physics code.

In the main game loop, every 5 frames, I pass the current game state to the MCTS engine:

if frame_counter % 5 == 0:
    state = get_game_state_from_main(mycar, energy, score, list(opponent))
    action = mcts_search(state, computation_time=0.05)

The result is one of four possible actions: "left", "right", "shoot", or "none".

Once the decision is made, the game responds accordingly:

if action == "left":
    mycar.move("left")
elif action == "right":
    mycar.move("right")
elif action == "shoot":
    fire_sound.play()

So here’s what’s actually going on behind the scenes every time the AI makes a move. The MCTS algorithm starts by traversing the existing tree of game states to find the most promising node to explore—this is the selection step. Once it lands on that node, it simulates one new possible action from there, which is the expansion phase. From that new state, it plays out a few random steps of the game using a basic policy (like “shoot if you see enemies” or “don’t move if energy is low”)—this is the simulation part. And then finally, based on how well or badly that rollout went, it backpropagates the reward back up the tree so that decisions that led to good outcomes get reinforced and are more likely to be chosen in the future. Each loop tries to balance exploration (trying out new stuff) and exploitation (doing what’s already known to work), and this constant balance somehow ends up producing surprisingly smart behavior out of nothing but random simulations and reward math.

After integrating MCTS, the game now plays itself. The car intelligently avoids enemy fire, conserves energy, and shoots at the right moments. It’s not perfect—but it’s good enough to survive for a few minutes and rack up a decent score.

However, one limitation of the current setup is that the AI doesn’t retain any memory of past games—it starts from scratch every time the game restarts. The MCTS algorithm only simulates forward from the current state and doesn’t learn or adapt across episodes. So while it can make fairly smart decisions in the moment, it has no long-term strategy or evolving understanding of what works best over time. There’s no persistence of experience, which means it can’t build on previous runs to improve future performance. This makes it efficient for one-off decisions but not ideal for learning patterns or refining behavior over multiple plays.

Next, I’m planning to take things a bit further. I want to train a policy network on the trajectories generated by MCTS so the model can learn from past simulations and make better long-term decisions without needing to simulate every time. I’m also thinking of adding a simple GUI to visualize how the MCTS tree grows and changes in real time—because watching the AI think would honestly be super fun. And eventually, I’d like to give players the option to toggle between AI-controlled and manual play, so they can either sit back and watch the car do its thing or take control themselves. You can find the full implementation on my GitHub. Thanks for reading!

Back in my second year of college, I had just started exploring functional programming. I was picking up Haskell out of curiosity - it felt different, abstract, and honestly a bit intimidating at first. Around the same time, I was also diving into topics like context-free grammars, automata theory, parse trees, and the Chomsky hierarchy - all the foundational concepts that explain how programming languages are parsed, interpreted, and understood by machines.

Somewhere along the way, it hit me: what if I could build something with both? What could be more fun than writing an interpreter for an imperative programming language using a functional one? That idea stuck - and over the next few weeks, I set out to build a purely functional monadic interpreter in Haskell.

I designed the grammar for the language myself, mostly inspired by Python. I wanted it to support loops, conditionals, variable assignments, print statements, and basic arithmetic, boolean, and string operations. It even has a “++” operator for string concatenation. Writing the grammar rules involved figuring out how to model nested blocks, expressions with precedence, and side-effect-free evaluation. I built the entire thing using monadic parser combinators—no parser generators or external libraries, just Haskell’s type system and some stubbornness.

Here’s a rough look at the grammar that powers the interpreter:

Block 
    : { Part }

Part 
    : Statement Part
    | IfStatement Part
    | WhileLoop Part
    | Comment String Part
    | epsilon

Statement 
    : var = AllExpr;
    | print( AllExpr );

AllExpr 
    : Sentences ++ AllExpr
    | Sentences

Sentences
    : string
    | LogicExpr

IfStatement
    : if ( LogicExpr ) Block else Block

WhileLoop
    : while ( LogicExpr ) Block 

LogicExpr
    : BoolExpr && LogicExpr
    | BoolExpr || LogicExpr
    | BoolExpr

BoolExpr 
    : True
    | False
    | ArithBoolExpr

ArithBoolExpr
    : Expr > Expr
    | Expr < Expr
    | Expr == Expr
    | Expr != Expr
    | Expr

Expr 
    : HiExpr + Expr
    | HiExpr - Expr
    | HiExpr

HiExpr 
    : SignExpr * HiExpr
    | SignExpr / HiExpr
    | SignExpr % HiExpr
    | SignExpr 

SignExpr
    : int
    | ( AllExpr )
    | var

The interpreter parses the source code using this grammar, builds an abstract syntax tree, and evaluates it by simulating an environment. There’s no mutation—it just returns a new environment every time a variable is assigned or a block is executed.

Running it is simple enough. After compiling with GHC, it reads the program from stdin and prints the resulting variable bindings and any output generated by print() statements.

ghc -o interpreter interpreter.hs
./interpreter

Here’s a sample program to show how it works:

  
    { 
        i = 5;
        a = (4 < 3) || 6 != 7;
        print(a);

        # First While! #
        while(i != 0 && a) 
        { 
            print(i); 
            i = i - 1; 
        }

    }

    Output : a True
             i 0
             print True 5 4 3 2 1 

Once I had the interpreter working, I wanted to make it a bit more fun to interact with. So I built a small GUI in Python using tkinter. It’s nothing fancy—just a textbox to enter code, a button to run it, and an output area to display the result. When you click “Run,” the Python script sends the code to the Haskell interpreter and prints whatever comes back.

The entire thing—from parsing to evaluation—is written in a purely functional style. No mutable state, no IO hacks, no shortcuts. Just expressions flowing through types and functions. It’s probably not the fastest interpreter out there, but writing it did teach me a lot about how languages work under the hood.

This is the release schedule the release team agreed on

https://community.kde.org/Schedules/KDE_Gear_25.08_Schedule

Dependency freeze is in around 2 weeks (July 3) and feature freeze one
after that. Get your stuff ready! 

🎉 New Clazy Release: Stability Boost & New Checks!

We’re excited to roll out a new Clazy release packed with bug fixes, a new check, and improvements to existing checks. This release included 34 commits from 5 contributors.

🔍 New Features & Improvements

• New Check: readlock-detaching
  Detects unsafe and likely unwanted detachment of member-containers while holding a read lock. For example, when calling .first() on the mutable member instead of .constFirst()

• Expanded Support for Detaching Checks
  Additional methods now covered when checking for detaching temporary or member lists/maps. This includes reverse iterators on many Qt containers and keyValueBegin/keyValueEnd on QMap. All those methods have const counterparts that allow you to avoid detaching.

• Internal Changes With this release, Clang 19 or later is a required dependency. All older versions needed compatibility logic and were not thouroughly tested on CI. In case you are on an older Version of a Debian based distro, consider using https://apt.llvm.org/ and compile Clazy from source ;)

🐞 Bug Fixes

• install-event-filter: Fixed crash when no child exists at the given depth.
  BUG: 464372

• fully-qualified-moc-types: Now properly evaluates enum and enum class types.
  BUG: 423780

• qstring-comparison-to-implicit-char: Fixed and edgecase where assumptions about function definition were fragile.
  BUG: 502458

• fully-qualified-moc-types: Now evaluates complex signal expressions like std::bitset<int(8)> without crashing. #28

• qvariant-template-instantiation: Crash fixed for certain template patterns when using pointer types.

Also, thanks to Christoph Grüninger, Johnny Jazeix, Marcel Schneider and Andrey Rodionov for contributing to this release!

From Refactor to Functioning Plugin

Hi again! Week two was all about turning last week’s refactored EteSync resource and newly separated configuration plugin into a fully working, stable component. While the initial plugin structure was in place, this week focused on making the pieces actually work together — and debugging some tricky issues that emerged during testing.

Removing QtWidgets Dependencies with KNotification

While testing, I discovered that the original EteSync resource code used QDialog and KMessageBox directly for showing error messages or status updates. These widget-based UI elements are too heavy for a background resource and conflict with the goal of keeping the resource lightweight and GUI-free.

To address this, I replaced them with a much cleaner approach: creating KNotification instances directly. This allows the resource to send system notifications (like “EteSync sync successful” or error messages) through the desktop’s notification system, without relying on any QtWidgets. As a result, the resource is now fully compatible with non-GUI environments and no longer needs to link against the QtWidgets library.

Refactoring Settings Management for Plugin Compatibility

Another major change this week involved how the resource handles its settings.

Previously, the configuration was implemented as a singleton, meaning both the resource and its configuration plugin were sharing a single instance of the settings object. This worked in the old, tightly-coupled model, but caused conflicts in the new plugin-based architecture.

To fix this, I updated the settings.kcfgc file to set singleton=false. This change allows the resource and the configuration plugin to maintain separate instances of the settings object, avoiding interference. I also updated both etesyncclientstate.cpp and etesyncresource.cpp to properly manage their respective configurations.

Solving the “Zombie Window” Issue

One final issue emerged after separating the UI: the configuration wizard now appears in a separate window from the main Akonadi configuration dialog. When the wizard is completed and closes, the original configuration window — now empty and disconnected — remains open.

Clicking buttons on this leftover window causes terminal errors, since it no longer communicates with a valid process. This results in a confusing and potentially buggy experience for users.

What’s Next?

My next task is to figure out a clean way to close the original parent window when the wizard completes, ensuring a smooth and error-free configuration flow. In addition to that, I’ll begin testing the full integration between the EteSync resource and its configuration plugin to ensure everything works correctly — from saving and applying settings to triggering synchronization. This will help verify that the decoupling is both functionally solid and user-friendly.

I had mentioned a number of new Transitous features in a previous post. As those largely depend on the corresponding data being available, here’s an overview of how you can help to find, add and improve that data.

Transitous

Transitous is a community-run public transport routing service build on top of the MOTIS routing engine and thousands of datasets from all over the world. Transitous backs public transport related features in applications like GNOME Maps, KDE Itinerary or Träwelling.

Just like OpenStreetMap this needs people on the ground identifying issues or gaps in the data, figuring out where things go wrong and who to talk to at the local operators to get things fixed.

The first step to help is just comparing data you get from Transitous with the reality around you, ie. does the public transport schedule match what’s actually happening, and are all relevant services included?

If there’s things missing or outdated, a list of the types of datasets consumed by Transitous, and how to inspect and add those, follows below.

The central part in this are a bunch of JSON files in the Transitous Git repository, which define all the datasets to be used as well as a few parameters and metadata for those. Once a day those are then retrieved, validated, filtered and post-processed for importing into MOTIS by Transitous’ import pipeline.

Public transport schedules

The backbone of public transport routing is static GTFS schedule data, that’s the bare minimum for Transitous to work in a region. GTFS feeds are essentially zip files containing a set of CSV tables, making them relatively easy to inspect, although especially nationwide aggregated feeds can get rather large.

GTFS feeds ideally contain data for several months into the future, but can nevertheless receive regular updates. Transitous checks for updates daily, so for this to work practically we also need a stable URL for them (that might seem obvious to you, but apparently not to all feed providers…).

We currently have more than 1800 of those, from 55 countries. The Transitous map view gives you an impression how well an area is covered, each of the colored markers there is an (estimated) current position of a public transport vehicle.

If your area is incomplete or not covered at all, the hardest part to change that is probably finding the corresponding GTFS feeds. There’s a few places worth looking at:

• The public transport operators themselves, they might just publish data on their website.
• Regional or national open data portals, especially in countries with regulation requiring public transport data to be published. In the EU, those are called “National Access Point” (NAP).
• GTFS feed registries such as Mobility Database and Transitland.
• Google Maps having public transport data in your region is a strong indicator whether GTFS feeds even exist, as they use those as well.

Adding a GTFS feed to Transitous is then usually just a matter of a few lines of JSON pointing to the feed. In rare cases it might require a bit more automation work, such as in France where there’s hundreds of small feeds to manage.

And every feed is welcome, no matter whether it’s a nation-wide railway operator or a single community-run bus to help people in a rural area, as long as it’s for a service open to the general public.

Realtime data

So far this is all static though. For properly dealing with delay, disruptions and all kinds of other unplanned and short-notice service changes we also need GTFS Realtime (RT) feeds. Those are polled once a minute for updates.

GTFS-RT feeds come in three different flavors:

• Trip updates, that is realtime schedule changes like delays, cancellations, etc.
• Service alerts, that is textual descriptions of disruptions beyond a specific connection, such as upcoming construction work.
• Vehicle positions, that is geographic coordinates of the current position of trains or busses.

MOTIS can handle the first two so far. Support for vehicle positions is also on the wishlist, and not just for showing current positions on a map, vehicle positions could also be used to interpolate trip updates when those are not available.

Adding GTFS-RT feeds to Transitous is very similar to adding static GTFS feeds, however GTFS-RT feeds usually only work in combination with their respective static equivalent. Combining a smaller realtime feed of a single operator with a nationwide aggregated static feed will thus usually not work out of the box. There’s ways to exclude certain operators from a larger static feed though, so with a bit of puzzle work this can usually be made to work as well.

GTFS-RT feeds use Protocol Buffers, but there’s nevertheless simple way to look at their content:

curl https://the.feed.url | protoc gtfs-realtime.proto --decode=transit_realtime.FeedMessage | less

The Protocol Buffers schema file needed for this can be downloaded here.

To see the realtime coverage available in Transitous, you can toggle the color coding of vehicles on its map view in the upper right corner. A green/yellow/red gradient shows the amount of delay for the corresponding trip, while gray vehicles have no realtime information.

Shared mobility data

Transitous doesn’t just handle scheduled public transport though, but also vehicle sharing, which can be particularly interesting for the first and last mile of a trip.

The data for this is provided by GBFS feeds. This includes information about the type of vehicles (bikes, cargo bikes, kickscooters, mopeds, cars, etc) and their method of propulsion (human powered, electric, etc), where to pick them up and where to return them (same location as pickup, designated docks of the provider, free floating within a specific area, etc) and most importantly where vehicles are currently available.

Adding GBFS feeds to Transitous is also just a matter of a few lines of JSON. We currently don’t have a built-in UI to see the results, showing all available vehicles on the map is certainly on the wishlist though. GBFS is relatively easy to inspect manually, the entry point is a small JSON manifest that contains links to JSON files with the actual information, generally split up by how often certain aspects are expected to change.

Same as for GTFS feeds, any service accessible to the general public is welcome here, whether it’s a small community run OpenBike instance or a provider with hundreds of vehicles.

On-demand services

Somewhere between scheduled transport and shared mobility are on-demand services. That is, services that require some form or booking beforehand and might be anything from an on-demand bus that still follows a somewhat fixed route with pre-defined stops to something closer to a taxi with a more flexible route that picks up or drops off passengers anywhere in a given area.

These services are often used in times and/or areas with fewer demand, thus making them often the only mobility option then/there. That makes it all the more important to have those covered as well.

Modeling on-demand services is challenging, given the variety on how those services work and their inherently very dynamic nature. There’s the relatively new GTFS-Flex standard covering this, which MOTIS supports since v2.0.66.

GTFS-Flex feeds might be included in static GTFS data or provided separately, and adding them to Transitous works again by just a few lines of JSON.

There’s one caveat though, the validator we use in pre-processing, gtfsclean, doesn’t support GTFS-Flex yet, so those feeds are currently imported without any sanity checking or validation. Therefore we need to be extra careful with adding such feeds until that is fixed. If you know a bit of Go and want to help with that, get in touch!

For GTFS-Flex data there’s some diagnostic visualization in the map view in debug mode, when zooming in far enough.

OSM

A crucial dataset for all road-based and in-building routing is OpenStreetMap. While that is generally very comprehensive and up-to-date, there’s one aspect that more often needs fixes, the floor level separation. That’s not visible in most OSM-based maps and thus is easy to miss while mapping. For Transitous this is particularly important for in-building routing in train stations.

When zoomed in enough the map view of Transitous will offer you a floor level selector at the lower right. That can give you a first indication if elements are misplaced (showing up on the wrong level) or not assigned to a floor level at all (showing up on all levels). For reviewing smaller elements indoor= can also be useful, and for fixing things JOSM has a built-in level selector on the top left.

In most cases adding or fixing the level tag is all that’s needed. Elements allowing to move between levels (stairs, ramps, elevators, escalators, etc) are especially important for routing.

And more

All of the above is just the current state, there’s much more to look at though, such as:

• Unused information in the existing datasets, such as fare information or the remaining range of sharing vehicles.
• Expanding the GTFS standard to cover things currently not modeled. Starting from relatively simple things like car ferries or car transport trains to highly detailed information about a bus or train interior with regards to accessibility.
• Convert other data formats to GTFS, such as NeTEx, SIRI or SSIM.
• Generate GTFS-RT trip updates from realtime vehicle position data.
• Extend the import pipeline to augment and normalize GTFS feeds, e.g. by injecting line colors and logos from Wikidata or accessibility information and missing paths from OSM, or to normalize train names.
• Considering elevation data for street routing. MOTIS has initial support for this meanwhile, but even the relatively coarse global 30m SRTM grid data would require an extra 50-100GB of (fast) storage, with quadratic growth with smaller grid sizes (1m or 2m grids are available in a number of regions).

In other words, plenty of rabbit holes to explore, no matter whether you are into code, data, math, trains, busses, IT operations or lobby work :)

You can help!

Check around you whether information from Transitous matches the reality on the ground, join the Transitous Matrix channel, join the Transitous Hack Weekend in a few weeks and join the Open Transport Community Conference in October!

Welcome to a new issue of This Week in Plasma! Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This week we finished polishing up Plasma 6.4 for release, and started to turn our heads to bigger topics — notably including Wayland protocols and accessibility!

Notable New Features

Plasma 6.5.0

Implemented support for an experimental version of the Wayland picture-in-picture protocol that allows apps also implementing it (such as Firefox) to finally display proper PiP windows in advance of the upstream version of the protocol eventually being merged. (Vlad Zahorodnii, link)

Notable UI Improvements

Plasma 6.3.6

Reduced the rate at which the “visual bell” accessibility feature can flash the screen so there’s no way it can cause seizures. (Nicolas Fella, link)

Plasma 6.4.0

Made the Kicker Application Menu widget able to horizontally scroll for searches that return results from many KRunner plugins, so you have the opportunity to see them all. (Christoph Wolk, link)

Plasma 6.4.1

Improved text contrast for labels used in subtitles or other secondary roles throughout Plasma. (Nate Graham, link 1, link 2, link 3, link 4, link 5, link 6, and link 7)

Discover’s search field now trims all whitespace, to prevent errors when copy-pasting text that ends in a space or something. (Nate Graham, link)

Plasma 6.5.0

In System Settings, moved the Invert and Zoom settings into the Accessibility page, which is a more sensible place for them than the Desktop Effects page was. (Oliver Beard, link 1, link 2, and link 3)

Merged KWin’s Background Contrast effect into the Blur effect, since neither makes sense to turn on or off without the other. (Marco Martin, link 1 and link 2)

On Wayland, virtual desktops can now be re-ordered from the Pager widget, and re-ordering them in the Overview effect’s grid view now re-orders them in the Pager widget too. (Marco Martin and Vlad Zahorodnii, link 1, link 2, and link 3)

Spectacle now makes it clearer that you can end a screen recording by pressing the same keyboard shortcut you used to start it, by telling you this in the notification and also by using clearer names for the global shortcuts. (Noah Davis, link)

The Breeze application style’s animated effects for clicking checkboxes and radio buttons now work in QtQuick-based apps and System Settings pages as well. (Kai Uwe Broulik, link)

The Disks & Devices, Networks, and Bluetooth widgets now use standard-style section headers. (Nate Graham, link 1, link 2, and link 3)

Improved the searching UX in the Emoji Selector app: now the search field is always visible, and doing a search will always search through the full set of all emojis if there aren’t any matches on the current page. (Nate Graham, link 1, link 2)

The Display Configuration widget and OSD no longer thinks your primary screen is always connected to a laptop; now it uses more generic terminology. (Nate Graham, link)

Notable Bug Fixes

Plasma 6.3.6

Using a non-default font or font size no longer causes the selection rectangles for files or folders on the desktop to be displayed at the wrong size and cause subtle layout and positioning glitches. (Nate Graham, link)

Plasma 6.4.0

Fixed several more cases where putting a widget on a huge panel could cause Plasma to freeze. (Christoph Wolk, link 1, link 2, link 3, link 4, link 5, link 6, and link 7)

Fixed a case where Discover could crash while offering you the replacement for an end-of-support Flatpak app. (Akseli Lahtinen, link)

Fixed a bug that caused the Open/Save dialogs invoked from Flatpak-based browsers (or when forcing the use of portal-based dialogs) to sometimes not allow the preview pane to be opened. (David Redondo, link)

Fixed a weird bug that could cause a standalone Folder View widget on the desktop to become visually glitchy when you drag files or folders to it from Dolphin. (Akseli Lahtinen, link)

Fixed a bug that broke printing at the correct sizes in Flatpak-packaged GTK apps. (David Redondo, link)

Installing or uninstalling an app no longer unexpectedly clears the search field and results view in Kicker or Kickoff if they happened to be visible at the moment the transaction completed. (Christoph Wolk, link)

Frameworks 6.15

Fixed a cause of crashes in apps and Plasma system services using System Monitor charts. (Arjen Hiemstra, link)

Frameworks 6.16

Fixed an intermittent source of crashes in System Monitor when switching process views. (Arjen Hiemstra, link)

Fixed a weird issue that could cause Open/ Save dialogs to close when hovering over certain files. (David Redondo, link)

KDE Gear 25.04.3

Fixed an issue that could cause the thumbnailer to crash on X11 when using certain widget styles. (Nicolas Fella, link)

Other bug information of note:

• 3 very high priority Plasma bugs (same as last week). Current list of bugs
• 23 15-minute Plasma bugs (up from 21 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.4.0

Improved startup speed for System Monitor by loading the column configuration dialog’s content on-demand, rather than at launch. (David Edmundson, link)

Made sure that the Environment Canada data source for weather reports keeps working, since the provider is changing their data format soon and we needed to adapt. (Ismael Asensio, link)

Frameworks 6.15

Improved startup speed for System Monitor by loading the tree view indicator arrows on demand, rather than at launch. (David Edmundson, link)

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 becoming an active community member and getting involved somehow. 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:

• Triage and confirm bug reports, maybe even identify their root cause
• Contribute designs for wallpapers, icons, and app interfaces
• Design and maintain websites
• Translate user interface text items into your own language
• Promote KDE in your local community
• …And a ton more things!

You can also help us by making a donation! 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 a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

Let’s go for my web review for the week 2025-24.

Google’s nightmare: How a search spinoff could remake the web

Tags: tech, web, google, search, monopoly, economics

There’s clearly something tempting about a web index somehow separated from Google. It always felt like a natural monopoly and so a type of public service. Now that push arrives a tad late so the impacts are unclear. Overall I still think this would be a net positive if there are more web search companies built onto such an index.

https://arstechnica.com/google/2025/06/googles-nightmare-how-a-search-spin-off-could-remake-the-web/

How much EU is in DNS4EU?

Tags: tech, dns, privacy

Early days for that service. Let’s hope it improves infrastructure wise.

https://techlog.jenslink.net/posts/dns4eu/

Trusting your own judgement on ‘AI’ is a huge risk

Tags: tech, ai, machine-learning, gpt, copilot, programming, cognition, scam, criticism

An excellent piece which explains well why the current “debate” is rotten to the core. There’s no good way to engage with those tools without reinforcing some biases. Once the hype cycle is over we have a chance at proper research on the impacts… unfortunately it’s not happening now when it’s badly needed.

https://www.baldurbjarnason.com/2025/trusting-your-own-judgement-on-ai/

Avoiding generative models is the rational and responsible thing to do – follow-up to “Trusting your own judgement on ‘AI…’”

Tags: tech, ai, machine-learning, gpt, copilot, programming, cognition, scam, criticism

A nice followup which acts as a TL;DR for the previous piece which was fairly long indeed.

https://www.baldurbjarnason.com/2025/followup-on-trusting-your-own-judgement/

Poison everywhere: No output from your MCP server is safe

Tags: tech, ai, machine-learning, gpt, copilot, security

OK, this is definitely concerning for the use of tools with so called coding agents. The trust model is really not appropriate at this stage and that opens the door to a wide range of attacks.

https://www.cyberark.com/resources/threat-research-blog/poison-everywhere-no-output-from-your-mcp-server-is-safe

How we decreased GitLab repo backup times from 48 hours to 41 minutes

Tags: tech, gitlab, git, complexity, profiling, optimization

Nice simple fix in Git but with a large impact on backups. A good proof that profiling and keeping an eye on algorithmic complexity can go a long way in improving software.

https://about.gitlab.com/blog/2025/06/05/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/

Sandboxing Adoption in Open Source Ecosystems

Tags: tech, unix, system, sandbox

Interesting paper about the use of sandboxing in several ecosystems. It’s not used much directly but there are clear differences in term of complexity to set them up.

https://arxiv.org/abs/2405.06447

Curate your shell history

Tags: tech, tools, shell

Interesting thinking and trick. We clearly pile up too much noise in our shell history.

https://esham.io/2025/05/shell-history

magic namerefs

Tags: tech, shell, scripting

Didn’t know bash got this feature now. I’m torn between “it looks so cool” and “we’ll never see the end of debugging issues which use this”.

https://gist.github.com/izabera/e4717562e20eb6cfb6e05f8019883efb

Too Many Open Files

Tags: tech, unix, system, filesystem

Need to play with file descriptors on Unix systems? This is a fun and gentle introduction.

https://mattrighetti.com/2025/06/04/too-many-files-open

Is Rust faster than C?

Tags: tech, rust, c, performance

Or why this kind of question never have an absolute answer.

https://steveklabnik.com/writing/is-rust-faster-than-c/

Patterns for Modeling Overlapping Variant Data in Rust

Tags: tech, programming, rust, type-systems, data

Interesting selection of options to model data structure with some variability in Rust.

https://mcmah309.github.io/posts/patterns-for-modeling-overlapping-variant-data-in-rust/

GPU Memory Consistency: Specifications, Testing, and Opportunities for Performance Tooling

Tags: tech, gpu, memory, performance

The memory models for GPU programming are complex. This isn’t easy to squeeze more performance without introducing subtle bugs.

https://www.sigarch.org/gpu-memory-consistency-specifications-testing-and-opportunities-for-performance-tooling/

The Concurrency Trap: How An Atomic Counter Stalled A Pipeline

Tags: tech, multithreading, caching, cpu, rust

A good example of how you can get bitten by cache coherency algorithms in the CPU.

https://www.conviva.com/platform/the-concurrency-trap-how-an-atomic-counter-stalled-a-pipeline/

Malleable software: Restoring user agency in a world of locked-down apps

Tags: tech, programming, ux, design

A long essay but contains a lot of interesting insights. There’s definitely more to do design wise to produce software people can really bend to their needs.

https://www.inkandswitch.com/essay/malleable-software/

Write Unit Tests, Don’t Waste Our Money!

Tags: tech, tests, business

This is one way to frame it I guess. Code is indeed an investment, tests are here to protect it.

https://www.yegor256.com/2025/06/08/pull-request-without-test.html

Test Contra-variance

Tags: tech, tdd, tests, design

A good reminder of the reasons why the organization of your tests shouldn’t necessarily match the organization of the application code. You don’t want fragile tests, do you?

https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html

Pinning Tests

Tags: tech, legacy, tests

I’m using the term regularly when dealing with legacy code. Finally remembered when I saw it first.

https://wiki.c2.com/?PinningTests

Analyzing Metastable Failures in Distributed Systems

Tags: tech, failure, safety, distributed

Interesting paper about metastable failures and novel approaches to try to analyse them. It’s early days but we would need to get toward better prevention.

https://muratbuffalo.blogspot.com/2025/06/analyzing-metastable-failures-in.html?m=1

How I structure my apps (in Rust and other languages)

Tags: tech, architecture, design, rust

Of course, don’t take everything at face value here. Still this gives good ideas on how to combine some design and architectural ideas together. The whole thing is not really Rust specific.

https://dpc.pw/posts/how-i-structure-my-apps-in-rust-and-other-languages

ADRs

Tags: tech, architecture

Nice little post helping advocate for the use of Architectural Decision Records.

https://www.beflagrant.com/blog/adrs

Beck Design Rules

Tags: tech, xp, design

Nice and short explanation on the design rules Kent Beck had in mind when devising XP. It still generally applies in my opinion.

https://martinfowler.com/bliki/BeckDesignRules.html

Tech debt can’t be solved as a roadmap item. It needs to be part of your daily routine

Tags: tech, quality, technical-debt, project-management

Definitely this, too often I see projects treating the technical debt as one-off large tasks. Really it’s something you should deal with bite sized and over time.

https://software.rajivprab.com/2025/05/10/tech-debt-cant-be-solved-as-a-roadmap-item/

The Real Cost of Change

Tags: tech, agile, technical-debt, planning, risk

It will fluctuate with time so it needs to be kept in check. Indeed, some things are commodities so can be decided upfront, but the rest of the functional envelope will change over time. Also make sure you drive the project by risks to have early feedback where it matters most.

https://lizkeogh.com/2012/01/30/the-real-cost-of-change/

Blameless PostMortems and a Just Culture

Tags: tech, failure, culture, management

Mistakes happen, but shrugging them off with blaming people or pushing them to be more careful is counter-productive. Instead, you want to find the organizational issues which made them possible in the first place.

https://www.etsy.com/codeascraft/blameless-postmortems/

Building An Impact Brewery: A Toolkit for R&D Leaders to Drive Impact

Tags: tech, research, leadership, tech-lead, organization

Not fond of the metaphor used here which leads to quite some noise. Still, this article contains interesting ideas to try to push R&D initiatives forward. Definitely needed to improve any kind of organisation.

https://medium.com/panorays-r-d-blog/building-an-impact-brewery-a-toolkit-for-r-d-leaders-to-drive-impact-f2336d51109e

Elephant Carpaccio facilitation guide

Tags: tech, agile, tests, tdd, teaching

This is one of those workshops I like to do with teams from time to time. Didn’t do it for a while. I wish this resource was on a safer space than google docs.

https://docs.google.com/document/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub

5 People Who Destroy Your Culture

Tags: management

This kind of articles are always a bit caricatural. Still there is some good advice in there. Keep an eye open for the harmful behaviors.

https://blog.eladgil.com/p/5-people-who-destroy-your-culture

Bye for now!

Learn how to use Cucumber-CPP and Gherkin to implement better black box tests for a C++ library. We developed a case-study based on Qt OPC UA.

Continue reading Improved Black Box Testing with Cucumber-CPP at basysKom GmbH.