I attended the GSoC Alumni Camp in Delhi, it was an amazing opportunity to make people who are already familiar with open source aware of KDE Community
and I was actually able to do that. The event itself was from 8:00 A.M. to 10:30 P.M. at night.
The event started off with a formal opening session.
Soon after was the scavenger hunt (we were hunting people!)
it was a 5x5 grid where you needed to get signatures of people who fit the question in the box.
A few of them were :
I was born in July (I signed a lot of them )
I have held a koala
I know 3+ languages
I can juggle
I prefer go/Rust
and so on.
In all honesty it was an amazing ice breaker and something to get to know people.
After that there were a few unconferences followed by lunch and then more unconferences till 6:00 P.M. after that lightning talk sessions started and fortunately I got to represent KDE.
Unconference Session – From GSoC Student to Maintainer/Mentor
I also hosted one of the first unconference sessions titled:
From GSoC Student to Maintainer/Mentor
I wasn't expecting a large audience, but at one point the room was at its capacity around 40 attendees.
The audience included:
GSoC Organization Administrators
Mentors
Open source employees
Existing contributors
Google code-in students
The discussion focused on contributor retention after GSoC and how organizations can better support contributors beyond the program.
It led to some interesting discussions where we found out what some organisations are doing.
Discussion Points (Noted by an org admin)
Leverage Contributors as Subject Matter Experts
GSoC contributors naturally become subject matter experts for the components they build. When new issues, bug reports, or pull requests relate to their work, proactively invite them to participate in the discussion or review. This helps contributors feel that their expertise is valued and keeps them engaged with the project beyond GSoC.
Improve Communication Around Pull Request Reviews
Complex pull requests often require focused reviews and may take longer than isolated bug fixes. While taking the necessary time for a thorough review is important, mentors should acknowledge review requests and, where possible, communicate an expected timeline. Even a brief acknowledgment improves the contributor experience.
Using Organization Stipends for Contributor Retention
Explore using the GSoC organization stipend to support promising contributors after the program ends. This could fund continued maintenance or feature development through a transparent platform such as Open Collective, allowing contributors to invoice for their work and remain actively involved with the project.
Recognizing Mentor Contributions
Mentoring requires a significant investment of time in reviewing code, guiding contributors, and providing technical support. Consider allocating a portion of the organization stipend to compensate mentors, recognizing their efforts and encouraging long-term participation.
KDE's Community Support
Another topic that generated considerable interest was KDE's support for its contributors.
I talked about how KDE sponsors some students to attend Akademy, and how I was also sponsored to attend the event, which a lot of people agreed organizations should've done (some did, a lot didn't) but a lot of people agreed that when an organization consider these things contributors stay.
After all the unconferences ended a lot of people came up to me saying mine was the best and I managed and engaged everyone in the best way possible ( I was on cloud 9).
Lightning Talk
One of the highlights was being selected to give a lightning talk. Only 18 participants were chosen, and I was one of them.
My GSoC project Join KDE is an advertisement for KDE itself, so the project itself became an easy conversation starter. It was a great opportunity to introduce KDE and make more people aware of the organization.
Although I did fumble the last part of my presentation it was more of me being confused where my slide went (some slides were misplaced) aside from that it went as any other informative talk but hey I was funny on the stage (refer to the pics) so people remember me! You win some you lose some, oh well.
Conversations Throughout the Event
Outside the sessions, I had some interesting discussions with contributors from different organizations. Some contributors showed interest in working wwith us while some showed interest in our eduction/science side but honestly it's hard to bring contributors over as they're in different domains, org admins/mentors or they're busy with their careers.
SU2 Foundation
I had a conversation with a maintainer from the SU2 Foundation, whose work focuses on computational fluid dynamics.
We discussed KDE's scientific and educational initiatives, including KDE for Scientists and several education-related projects. I also shared the KDE For You website as an introduction to the wider KDE ecosystem.
After Party
The conversations continued during the after-party on the following day.
I met a group of students who had become interested in open source after interacting with contributors throughout the event. They had originally attended as friends of another contributor.
One of them is now actively looking for a project to begin contributing to within KDE. YAYYY!
New Contributors
Several first-time contributors approached me asking about projects suitable for beginners.
I introduced them to a number of KDE projects and explained possible contribution paths.
But the same issue they're busy with the beginning of their careers.
Overall Thoughts
The Alumni Camp was one of the best ways to make people aware of KDE and I tried my best while i had fun ( we played uno there! Will bill the cards to the organization jkjk), a lot of people seemed intrigued and asked me to share some stuff about KDE to them or they'll try it on their own. Met someone from GNOME (they didn't get any lightning talk HA! I know, I know no inter project fighting that's bad) had some good conversations, teased the person from GNOME, had breakfast with them, and tried to make the most of the unconference session and the lightning talks to at least get people to know the name KDE!
Today we're releasing Krita 5.3.3 and 6.0.3, containing many bugfixes and improvements across the board.
Android Donations and Supporter benefits
On Android, version 5.3.3 lets you support Krita's development directly through the application. This goes through the Play Store, so if you have a device without Google services or are using a debug or nightly version of Krita, it won't be available and instead will show you donation links.
In return for supporting Krita, you'll be able to download resource bundles directly in the application, including the paid Digital Atelier bundle. The splash screen and welcome page will also tell you about the supporter packs or donation links. You are not required to make any purchases, no features are locked behind a paywall and you won't get nagged about it while you're actually working. You can also of course still manually import resource bundles, the downloads are just a convenience feature.
Special thanks to Freya Lupen and Elena Sagalaeva, for multiple bug fixes, as well as the many newcomers who contributed to this release (named in the changelog).
Don't free hold frame undo command at scope exit (Bug 520732)
Added get started, community, website and source code icons (Thanks to Arkady Flury)
Try removing shell=True from the python calls on Windows
Get rid of division by zero in the KisMplTest.( Thanks to Elena Sagalaeva)
[android] All animation export and import functionality has been removed for now. Mostly because these functions didn't do anything. We're working on a properly working replacement for Android specifically.
Delete QuaZipFile before deleting the archive (Bug 520362)
Fix layers getting deselected when starting transform (Bug 517590)
Ensure a layer is activated for new views (Bug 518465 , Thanks to Gregg Jansen van Vuren)
Fix FFmpeg 7.0+ to render HDR animations (Bug 520669)
Fix Out-of-Bounds-Selection-Inversion (Bug 518235, Thanks to Ricky Ringler)
Fix Display Selection action check stats
Fix crash on null event pointer in Abstract Input Action (Bug 520581)
Force non-var vertical metrics to use default vertical caret. (Bug 517717)
Fix font-family sorting for fonts with wwsWithoutName set mixed.(Bug 518874)
Try to deduplicate font family names better, so we don't get sql errors. (Bug 517361)
Fix bug 522430. Switching between frames should always complete. (Bug 522430)
Fix deadlock when doing perspective transform (Bug 520602)
Expose tool and brush change signals to PyKrita (Thanks, Moritz Staudinger)
Various fixes to the selection action panel, including the ability to stick it to the sides of the canvas by pressing the "pin" icon.
Various fixes to the comic panel editing tool functionality.
Allow higher resolution of thumbnails on Welcome Screen.
⚠️ Warning
We consider Krita 5.3.3 suitable for productive work; 6.0.3 is, because of the many changes from Qt5 to Qt6 more experimental.
Download 5.3.3
Windows
If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.
The Linux AppImage and the source tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).
Download 6.0.3
Windows
If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.
There is a bug in KDE's bug tracker that is almost as old as some of our
contributors: bug 342056,
"Ridiculously slow file copy (multiple small files)", reported by Alexander
Nestorov back in 2014. The report is blunt: copying a 15 GB folder of roughly 3
million small files took 5 to 10 hours in KDE, versus about 20 minutes with
rsync. One commenter summed up the mood:
I generally use cp and rsync instead of dolphin for anything more than a few files.
That bug has been stuck in my head for a while, so this post is about finally
fixing it. I have been working on KIO's copy path, and I want to walk
through where the time was going, some history that explains why, and show
numbers across KIO versions including a plain cp for reference.
At with any optimization, let's measure first:
Where a KIO 6.28 copy of 5000 small files spends its blocking time, and there
is no single hotspot. Each file blocks in a burst of short syscalls: reading the
mount table (/proc/self/mountinfo), opening the source and destination, and
round-tripping a command to the worker over an internal socket. The socket
round-trips, the send and receive plus the waits for each reply, are the frames
highlighted in red, about 15% of the blocking here, spread as thin slivers
across both threads because every one of the thousands of files pays them. The
frames in green are the real filesystem work the copy cannot avoid: the statx
and openat calls, copy_file_range moving the bytes, and the ext4 metadata
updates beneath them. That per-file storm, not any single call, is what the rest
of this post discusses.
(Off-CPU flame graph from sched:sched_switch, weighted by number of blocking
switches; click to open the full SVG.)
A little history
KIO is the layer behind almost every file operation in KDE software, from Dolphin's copy
and paste to the network transparency that lets you open sftp:// or smb://
URLs as if they were local. Its design goes back to the KDE 2 days, around the
year 2000. Back then the answer to "how do I do I/O without freezing the UI" was
not a thread but a separate process: a worker (we used to call them kioslaves)
is launched for a protocol and talks to the application over a socket. This
predates usable threading on Linux (Native POSIX Thread
Library only landed
in Linux 2.6 in 2003), so processes plus socket IPC was the portable, robust
choice, and it still is for network protocols today: if an smb:// worker
crashes, your file manager does not go down with it.
The flip side is cost. Every request and its reply are serialized and sent over
that socket, with an event-loop hop on each side. For file:// that overhead
buys you nothing, because there is no untrusted network on the other end, just
the local disk.
In 2022 David Faure changed that: Implement running KIO workers in-process
using a thread landed in Frameworks 5.95. Since then the file worker runs on a thread inside
the application instead of as a separate process (other protocols stay
out-of-process for robustness). That removed process launch and context-switch
cost.
No socket between the thread and the app (6.29)
There was still a catch that had been hiding in plain sight: even in-process,
the worker thread and the application talked to each other over a socketpair,
serializing every command as if they were separate processes. Once the thread
was used, that socket was pure overhead.
That's the red highlight in the first flamegraph.
So in-process workers now use a real in-memory transport instead of a loopback
socket. A new ThreadConnectionBackend handles commands, and for reads the actual
data buffer, straight to the peer thread, with no serialization and no syscall,
which makes in-process file reads zero-copy. This is the biggest single jump in
the numbers below, and it has landed on master for 6.29
(kio!2279).
Next: batching the copy and the stat (under review)
The changes above make each command cheap. The remaining cost is that there are
still so many of them: copying N files is N separate file_copy jobs, each one
going through the job scheduler and taking its own round-trip to the worker. For
many small files that fixed per-file cost, not the data, is what dominates.
CopyJob can dispatch a whole batch of plain local-to-local files to the worker
in one command, and the worker copies them (using copy_file_range,
and reflink on filesystems like Btrfs or XFS that support it). Each file still
gets its progress signal, its byte accounting, its undo entry, and anything
the worker cannot do blindly — an existing destination, an unreadable source, a
rename or skip decision — is handed back to the normal per-file path. The gate is
conservative on purpose so a hung mount can never freeze the batch
(kio!2282).
The same copy on 6.29 with batch-copy: the red socket round-trips are gone. Two
things removed them: the in-memory transport from the previous section (no
socketpair at all) and batch-copy folding a whole run of files into one command
instead of one round-trip each. What is left is real filesystem work: the green
frames are the copy itself, copy_file_range moving the bytes, the openat and
statx calls, and the ext4 metadata beneath them. The wide plateau that is not
green is the benchmark loop deleting each pass's files before the next run
(unlink), which is teardown rather than part of the copy.
Before copying, CopyJob stats every source, which is another per-file
round-trip. The follow-up batches the stat phase over the same in-process lane.
This is the batch-copy-stat column below.
Both of these are under review and targeted at a release after 6.29, so treat
their columns in the table as a preview of what is coming rather than something
you can install today.
Numbers
Methodology: a 13th-gen Intel Core i7-1365U laptop, everything built
RelWithDebInfo without any sanitizer, copying onto a real ext4 volume (so no
reflink shortcut, copy_file_range moves real bytes). Each KIO version supplies
both its own libKIOCore and its own kio_file worker. Times are the median of
5 runs (3 for the large set) after a discarded warm-up, so caches are warm and
equal for every version. cp -r --preserve=mode,timestamps is included as the
floor, since that is what the bug reporter reached for instead of Dolphin.
5000 files of 4 KB each (the many-small-files case from the bug):
Version
Median time
cp -r (coreutils)
81 ms
KIO 6.28.0
1616 ms
KIO 6.29-dev (master)
396 ms
KIO 6.29-dev + batch-copy
88 ms
KIO 6.29-dev + batch-copy-stat
93 ms
1000 files of 5 MB each (bulk data, where the copy is I/O-bound):
Version
Median time
cp -r (coreutils)
1312 ms
KIO 6.28.0
1997 ms
KIO 6.29-dev (master)
1687 ms
KIO 6.29-dev + batch-copy
1506 ms
KIO 6.29-dev + batch-copy-stat
1454 ms
The small-files case is the story. KIO 6.28 was about 20x slower than cp,
which is exactly the ratio the 2014 report complained about. Removing the socket
for in-process workers, together with no longer probing the destination
filesystem once per file, takes it from about 1.6 s to 0.4 s (roughly 4x).
Batching the copy takes it to 88 ms, essentially cp speed and about 18x faster
than 6.28. That "I use cp instead of dolphin" line finally has an answer.
The large-file case was already well covered before any of this work, and the
table shows it: the copy is bound by moving the bytes, so even KIO 6.28 stayed
close to cp there, and the per-file optimizations barely move the number
(batch-copy lands within about 15% of cp). That is the whole reason this
effort targets many small files instead, where the fixed per-file cost, not the
data, is what dominates.
batch-copy and batch-copy-stat come out tied here: the benchmark copies a single
directory, so its entries arrive in one listing and batch-stat has nothing to
batch. It helps the other case, copying a large selection of individual files
that would otherwise be one stat round-trip each. Since it removes the
round-trip and not the stat call, the win is largest when stats are cheap, not
when the disk is slow. Read the two as equal on this test.
And cp will almost certainly stay a little ahead, by design: KIO does more
than copy the bytes. It reports per-file progress, can be paused and cancelled,
keeps an undo record, preserves permissions and timestamps, resolves conflicts,
and tells any open file manager what changed so its view refreshes. That work is
not free, and the goal was never to beat cp, only to make the local case fast
enough that reaching for cp instead of Dolphin stops being the obvious choice.
Caveats and what is next
These are laptop numbers on one ext4 disk with warm caches, meant to compare
versions, not to be absolute. On Btrfs or XFS the batch path reflinks instead of
copying, which changes the large-file picture entirely. The batch fast path only
engages for plain local-to-local copies on a responsive filesystem; anything
else (network, FAT/NTFS, conflicts needing a dialog) falls back to the existing
per-file path, unchanged.
Thanks to David Faure for the in-process worker threads that made all of this
possible, to Frank Reininghaus for the earlier listing fixes, and to Alexander
Nestorov for a bug report that aged well enough to still be worth closing.
Months ago, some distributions accidentally removed cryfs and encfs
from Vaults dependencies (temporarily). And some distributions are
removing them intentionally from their package repositories (at least,
for the time being).
It might be a good idea to switch your vaults to gocrtyptfs.
There is no automatic process for this, just create a new vault (it
will be gocryptfs-based – other backends have been removed from the UI
in the latest versions) and copy the data from the old one there.
Some context
To avoid users thinking there is something serious going on, this is
some background on changes:
Plasma Vault creation wizard supports only gocryptfs since plasma-vault/-/merge_requests/62 as it is
the most maintained upstream project, and to avoid “confusing the
users”.
Some distro packagers thought this means Vault no longer supports
cryfs and encfs and they removed them from the package dependencies.
This change was quickly reverted as there are existing users that
already have cryfs and encfs-based Vaults.
Some distros are cleaning up FUSE2-based file systems and going
FUSE3-only. Some of them ship a FUSE3-based CryFS, and some seem to be
waiting for an official FUSE3-supporting release (see
github.com/cryfs/cryfs/issues/419).
So, nothing important has happened. Your vaults are as safe as they
always were.
It is just that it might bring you a headache if the backend you use
for your vaults disappeared after you update your system.
And headaches for me when I get bug reports that Vaults no longer
support encfs or cryfs :)
This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor.
Gradient widget merged
MR !911 went through one more round of review, Jean-Baptiste caught a small inconsistency in how the 32-stop limit was applied and fixed it directly (c2d7a3d2, "Use limit everywhere"). After that, the Gradient widget merged. Two of the three widgets from the proposal are now in master.
One known issue flagged during review: MLT's gradientmap filter doesn't currently support alpha in its gradients, that's a bug on MLT's side, not the widget. Jean-Baptiste merged anyway to make the 26.08 window, with a plan to either disable alpha or fix it upstream before the final 26.08.0 release.
Speed Ramp: starting the third widget
With Gradient shipped, moved on to Speed Ramp. My original proposal described free-draggable bezier handles on the remap timeline's connector lines. Investigation before writing any code turned up a real problem with that: MLT has no bezier keyframe type to serialize a time map into, only preset easing types (linear, smooth, cubic, exponential, and more, as suffix characters on keyframe positions).
Checked with Jean-Baptiste. Turns out free bezier handles in MLT had already been investigated a few years ago and found difficult to integrate. His suggestion: use the same keyframe type system Kdenlive already uses for effects like volume and brightness, letting users pick a type from MLT's existing list rather than dragging custom handles.
Finding the right pattern to reuse
Kdenlive already has a widget that draws real keyframe curves in a plain QWidget, KeyframeCurveEditor, used in the effect stack for other parameters. It samples MLT's interpolated value per pixel and draws the result, no QML involved. That became the reference pattern for adding a curve to the remap dialog (RemapView).
Before building on it, tested MLT directly to confirm non-linear keyframe types are actually honored during playback, not just valid syntax. They are, sampled values matched the exact easing formulas. One gotcha found along the way: the keyframe type suffix has to go on the segment's starting keyframe, not the ending one, otherwise it's silently treated as linear.
Implementation
Four commits, each built clean before the next:
Added per-keyframe type storage (m_keyframeTypes) alongside the existing keyframe position map, synced across all 30+ places the position map gets mutated
Switched keyframe serialization and parsing to use MLT's own animation API instead of hand-formatted strings, so type suffixes are always placed correctly
Added a per-pixel sampled curve, drawn additively in the existing dual-ruler layout, nothing existing removed or changed
Added a keyframe type selector, starting with a curated list (Linear, Smooth, Cubic In, Cubic Out); the full MLT list includes bounce and elastic types, which cause the source time to briefly go backward on a time map, that's a product decision still pending, so it's left out for now
Manually verified: linear playback is unchanged, curve shape follows the selected type, old projects load correctly as all-linear, undo/redo works through type changes, and types survive keyframe drags and clip resizes.
What's next
Speed Ramp branch is local, not yet pushed. Bringing results to Jean-Baptiste before pushing and opening an MR.
With the main proposal items completed, I spent the last 2-3 weeks working on open issues in the KeepSecret tracker, fixing bugs and improving the overall experience.
Added a minimal user handbook for KeepSecret in DocBook format — the standard format used by KDE applications. The guide covers the main features: wallets, managing entries, generating passwords, importing and exporting, and locking. It's accessible via the Help menu. Writing it also involved adding the CC-BY-SA-4.0 license to the repo, which triggered a kirigami-app-components 1.0.1 release (more on that below).
Added the Find Action entry Ctrl+Alt+I to the global drawer. This opens the Actions Explorer dialog — a standard KDE dialog that lets users search through all available actions in the app by name. During testing, I discovered that kirigami-app-components 1.0.0 had a bug where FindAction wasn't working. Marco Martin fixed it and released 1.0.1.
Fixed a UX bug in 3-column mode: when switching wallets, the entry panel from the previous wallet stayed open. The fix was a single line — calling App.secretItem.close() when a wallet is clicked in the sidebar.
Added the Delete key as the default keyboard shortcut for deleting secrets. Since there's already a confirmation dialog, binding Delete directly is safe.
If anybody had told me I'd end up working on the very Linux desktop environment I've been daily-driving for the past three years, I probably wouldn't have believed them.
This summer, I got to learn and work on the main Network Manager component used by default in KDE, the desktop environment relied on by millions of users worldwide (source). Looking back, this has been the most challenging, and by far the most rewarding, journey of my open-source career so far.
How It All Started
I started looking for open-source projects to contribute to way before GSoC even announced its list of participating organizations. Back in October, I began contributing to major projects like OpenTelemetry, Lima-VM, and WasmEdge, repos I'm still active in today.
Somewhere along the way, I decided to explore the KDE ecosystem and give it a shot. That decision changed the trajectory of my year. From that point on, my co-mentors and I were actively working through a number of open-source issues together, including bugs in KClock, the native clock application used across KDE, long before the official GSoC coding period even began. That early groundwork ended up being exactly what prepared me to take on Network Manager as my actual project.
The Project
My GSoC project is titled "Make network related KCMs feature complete with desktop equivalent," under Plasma Mobile, mentored by Carl Schwan and the rest of the Plasma Mobile team.
Here's the core problem: Plasma Desktop and Plasma Mobile each ship their own, completely separate networking settings modules. The desktop KCM (kcm_connections) is mature and feature-complete, with full Wi-Fi security support (WPA/WPA2/WPA3, 802.1x Enterprise, various EAP methods), VPN configuration, and more. Plasma Mobile's networking KCMs, on the other hand, are QML/Kirigami-based and touch-friendly, but only support the basics (WPA/WPA2 Personal, essentially). Because the desktop editor lives in libs/editor/ as Qt Widgets, it can't be dropped into the mobile UI as-is, Widgets and Kirigami don't mix, so mobile has ended up stuck maintaining its own thinner reimplementation instead of reusing the desktop's mature backend logic.
My project is to close that gap: pull the shared backend logic in libs/ out from underneath the Qt Widgets layer, rebuild the connection editor in QML (in a new libs/editorqml/) using Kirigami, and get both the desktop and mobile KCMs consuming the same backend through QML property/signal bindings. This way, a feature added once (say, WPA3 Enterprise or a new VPN protocol) works identically on both form factors instead of being implemented twice. The work is broken into phases: project setup, the Wi-Fi/security connection-editor foundation, additional connection types (wired, hotspot, VPN, bonds/bridges/teams/VLANs), refactoring the KDED popup dialogs (like the Wi-Fi password and PIN prompts) from Widgets to QML, and finally integration testing plus writing proper architecture documentation for plasma-nm, which currently has very little of either.
The Challenge
The biggest hurdle, by far, was getting a real grip on QML and the architecture of the broader codebase.
Coming in, I understood C++ reasonably well, but plasma-nm's UI layer is written almost entirely in QML, a declarative language that describes what the interface should look like rather than how to build it step by step. On top of that, plasma-nm isn't a single self-contained app, it's a plugin-based system that sits on top of NetworkManager (the system daemon), talks to it over D-Bus, and exposes that state through a KDED module and a Plasmoid applet that the QML frontend binds to. Understanding which layer owned a given piece of logic, the daemon, the backend plugin, or the QML view, took real time.
Some of the specific things I had to work through:
Signal/property bindings in QML: tracing how a change in connection state on the backend actually propagates up through C++ signals into a QML property binding, and where things could silently break if a binding wasn't wired correctly.
The plugin architecture: plasma-nm supports different connection types (Wi-Fi, VPN, mobile broadband, etc.) via separate plugins, each with its own QML + C++ pairing, so I had to learn to navigate a fairly large, distributed codebase rather than one monolithic file.
Key Contributions
Here is the list of MRs that are merged in upstream as of this date:
Beyond the technical skills, QML, Network Manager core concepts, and plugin architectures, this project taught me a lot about contributing to a codebase that real people depend on every day. KDE isn't a toy project, it's a software that is used by millions of people to connect Wi-Fi and manage their networks without thinking twice about it. That changes how carefully you write and review code.
Thanks
A huge thank you to my mentors, Devin Lin and Carl Schwan, for the patience and guidance through the pre-GSoC Phase. And thanks to the broader KDE community and Plasma Mobile for being as welcoming as it is to newcomers navigating a genuinely large codebase for the first time.
This week saw a bunch of work on some core infrastructure components, like the RDP server, login greeter, and screen configuration tooling. That’s in addition to lots of other good work, too:
Notable new features
Plasma 6.8
You can now configure Plasma’s built-in remote desktop server to automatically lock the session after the last connected RDP client disconnects. (Nick Haghiri, krdp MR #211)
Discover’s transaction progress view now shows items in groups, with the ones currently in progress in a group at the top. (Aleix Pol Gonzalez, discover MR #1219)
On multi-screen setups, the existing Meta + 1-9 shortcuts for jumping straight to a task now target the panel on the screen you’re actively using, rather than always going to the primary monitor’s panel. This matches the behavior added to last week’s new task-switching shortcuts. (Salman Farooq, plasma-desktop MR #3884 and plasma-workspace MR #6848)
You can now find languages in Plasma Setup by searching for their locale code, localized name, or English name. (Tiziano Gaia, plasma-setup MR #109)
Frameworks 6.29
Further improved the visual fidelity of small icons drawn with the Kirigami.Icon component. (Méven Car, kirigami MR #2127)
Notable bug fixes
Plasma 6.6.7
Fixed an issue that made KWin crash on login for newer NVIDIA GPUs using the latest NVIDIA drivers in conjunction with various color management features. (Xaver Hugl, KDE Bugzilla #523287)
Restored the ability to play full-screen video in Chromium-based browsers on a virtual screen, such as those used when screen recording. (Xaver Hugl, Bugzilla #523353)
Fixed an issue that could make Plasma freeze and then take down apps as well after you switched activities with unusual values in your Plasma config file. (Shouvik Kar, KDE Bugzilla #522039)
Fixed two visual glitches affecting the Digital Clock widget: one that made the layout overflow on a panel right after turning on the “always show seconds” setting, and another one that made the time zone label fail to use the systemwide font family. (Hunter White and Nate Graham, KDE Bugzilla #523010 and KDE Bugzilla #523164)
When an image used in a slideshow in the Media Frame widget is changed on disk, the widget now notices it properly, rather than replacing it with a blank frame. (David Wild, KDE Bugzila #521538)
Plasma 6.7.4
Fixed a weird bug that could break Plasma Login Manager after you unplugged a screen and plugged it back in while on the login screen. (Oliver Beard, KDE Bugzilla #523313)
Fixed a bug that could make KWin crash on login on various laptops. (Xaver Hugl, kwin MR #9632)
Fixed a case where System Settings could crash when Fanatec racing pedals were plugged in. (Sebastian Sauer, KDE Bugzilla #522886)
Restored the ability to change the wallpaper and apply Plasma settings to Plasma Login Manager for users who upgraded from Plasma 6.6. (David Edmundson, KDE Bugzilla #517081)
Frameworks 6.29
Fixed a surprisingly common yet random-seeming way that Plasma could crash. (Shouvik Kar, KDE Bugzilla #519614)
QML-based KDE apps once again remember whether they were maximized or not across launches. (Nate Graham, KDE Bugzilla #522205)
Worked around a Qt bug that made some keyboard shortcuts in Kirigami-based apps not get assigned when using the app in certain languages other than English. (Manuel Alcaraz Zambrano, kirigami MR #2124)
Icons drawn by the Kirigami.Icon component now use the correct aspect ratio for portrait-orientation images when they’re being rounded to standard icon sizes. (Méven Car, kirigami MR #2126)
Notable in performance & technical
Plasma 6.8
We have created a new kscreenctl tool, intended as a future replacement for the old kscreen-doctor tool. It includes more features, more robustness, and a more conventional usage method. (Vlad Zahorodnii, kscreen MR #487)
Discover is now faster to load icons for Flatpak apps. (Aleix Pol Gonzalez, discover MR #1366)
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.
Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!
Beyond that, you can help KDE by directly getting involved in any other projects. 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.
You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.
To get a new Plasma feature or a bug fix mentioned here
Hello everyone! Once again, I am here to share my fun experiences incorporating new features for Mankala.
Problem
This time I have built a bot server for Mankala where you can automate the entire game process of playing the game moves by using the server endpoints present in the bot. This Mankala bot can be run in various ways, and for the easiest to understand, can be an example in Python, which I have used in our process.
Approach
To build this bot, I built a minimal HTTP server using Qt’s own QTcpServer. The BotApiServer class listens on port 8080 and handles raw HTTP requests by parsing the method and path manually, and when these requests are synced from the terminal, the changes can be observed in the GUI, showing a change in the number of shells.
The API exposes two endpoints:
GET /api/status — Returns the full game state as JSON: whose turn it is, the seeds in every pit, each player’s store, whether the game is over, and who won.
POST /api/move — Accepts a JSON body with player (“player1” or “player2”) and pit_index (0-indexed), validates the move, executes it, and returns the updated state.
A list of documentation with all the endpoints present has also been added as part of the Help section present in the game, which also contains predefined scripts to run 1 bot or even 2 bots simultaneously, automating the entire game.
OpenAPI documentation:
openapi: 3.1.0
info:
title: Mankala Bot API
description: API to programmatically control and play Mankala.
version: 1.0.0
paths:
/api/status:
get:
summary: Get the current game status
description: Retrieves the full state of the board, scores, and turn information.
responses:
"200":
description: OK
content:
application/json:
schema:
type: object
required: [in_progress, game_over, winner, turn, variant, pit_count, player1_pits, player2_pits, player1_store, player2_store, board]
properties:
in_progress: { type: boolean }
game_over: { type: boolean }
winner: { type: string, enum: ["", "player1", "player2"] }
turn: { type: string, enum: ["player1", "player2"] }
variant: { type: string, enum: ["Bohnenspiel", "Oware", "Pallanguli"] }
pit_count: { type: integer, minimum: 1 }
player1_pits: { type: array, items: { type: integer, minimum: 0 } }
player2_pits: { type: array, items: { type: integer, minimum: 0 } }
player1_store: { type: integer, minimum: 0 }
player2_store: { type: integer, minimum: 0 }
board: { type: array, items: { type: integer, minimum: 0 } }
/api/move:
post:
summary: Make a move
description: Executes a move for the specified player at the given pit index.
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [player, pit_index]
properties:
player: { type: string, enum: ["player1", "player2"] }
pit_index: { type: integer, minimum: 0 }
responses:
"200":
description: OK
content:
application/json:
schema:
type: object
required: [status, turn, game_over]
properties:
status: { type: string, enum: ["ok"] }
turn: { type: string, enum: ["player1", "player2"] }
game_over: { type: boolean }
winner: { type: string, enum: ["", "player1", "player2"] }
"400":
description: Bad Request (Invalid Move, Not Your Turn, Invalid JSON)
content:
application/json:
schema:
type: object
properties:
error: { type: string }
Here we can observe a Python script for a player vs bot game:
import urllib.request, json, time
API = "http://localhost:8080/api"
def status():
return json.loads(urllib.request.urlopen(f"{API}/status").read())
def move(player, pit):
req = urllib.request.Request(f"{API}/move",
data=json.dumps({"player": player, "pit_index": pit}).encode(), method="POST")
req.add_header("Content-Type", "application/json")
return json.loads(urllib.request.urlopen(req).read())
# Bot plays as player2, waits for human player1
while True:
st = status()
if st["game_over"] or not st["in_progress"]:
print(f"Game Over! Winner: {st['winner']}")
break
if st["turn"] != "player2":
time.sleep(0.5) # wait for human
continue
pits = st["player2_pits"]
# pick first non-empty pit
pit = next((i for i, v in enumerate(pits) if v > 0), -1)
if pit == -1:
break
print(f"Bot moves pit {pit}")
move("player2", pit)
time.sleep(1.5) # animation delay
For the above code, we can adjust the localhost port and the animation speed based on our needs and save it.
Challenges I faced:
I would say the synchronization of the GUI with the server was hard. So to make the GUI animations correctly incorporated, I made the apiMoveMade signal using which the change in game state was listened in GameWindowLandscape.qml and GameWindowPortrait.qml files.
This was something really new that I have done till now and was a fun experience for me.
As May came to an end, so did KDE Eco's "Opt Green: Sustainable Software For Sustainable Hardware" (German: Nachhaltige Software Für Nachhaltige Hardware) project. Read the announcement from 2024 at the project's start. It has been a full and exciting two years. Together with a wonderful team at KDE, dozens of supportive communities, and thousands of volunteers, we really achieved a whole lot. Highlights include: The project organized stands at environmental festivals, markets and the Long Night of the Sciences. We did outreach at international conferences. We hosted install parties for adults and children, as well as taught upcyclingcourses in high school. We published ads, advertorials, and articles in Free & Open Source Software (FOSS) and eco-consumer magazines, and even co-authored an academic paper. We built new networks between FOSS and repair communities. And we mobilized volunteers worldwide to offer in-person Linux support in a global campaign against e-waste driven by Microsoft's software policies.
I only wish we had another two years!
End Of 10 campaign in a German environmental magazine. Eco-consumers are a new demographic for KDE and Free & Open Source Software and one of the main target groups of the Opt Green project. Since publishing this ad in early 2026, Microsoft has again extended the end of support for Windows 10 until 12 October 2027. (Image from KDE published under a CC BY-SA 4.0 license. Design by Anita Sengupta.)" src="https://eco.kde.org/blog/images/2026-07-22-ad-werde.png"
style="max-width: 100%; height: auto"
/>
I will not attempt to write a retrospective of everything the project did. Instead, I would like to focus on two aspects of the project which I believe will result in the main goals of the project not only continuing, but thriving well beyond the project's end. This post will be published in two parts. Here, in Part I, I will present Opt Green's activities in networking and collaborating with Repair Cafés. In Part II, to be published soon, I will take a closer look at the End Of 10 campaign and what comes next after the unexpected two-year extension of Windows 10 support.
Networking With Repair Cafés
Repair collectives provide community spaces to fix stuff. There exist many groups offering workshops to make and repair things, such as Hackerspaces, Makerspaces, FabLabs, and Linux User Groups. Repair Cafés will be the focus here, though. Free & Open Source Software, and the role it plays in keeping computers in use after vendor support ends, is for the most part a new topic for these communities. Moreover, Repair Cafés generally serve a different demographic than Hackerspaces, Fablabs, LUGs, etc. Working with Repair Cafés provides a great opportunity to reach people well outside the FOSS bubble.
Repair Cafés are a place to repair objects used in everyday life, such as clothing, electronics, bicycles, and so on. The first Repair Café was launched in Holland in 2009 by Dutch journalist Martine Postma. Since then thousands have popped up around the world with support from organizations such as Repair Cafe International (started by Martine Postma), the Restart Project (creators of Right To Repair and Open Repair Alliance), iFixit, anstiftung, among others.
Netzwerk Reparatur-Initiativen website. Those little sunny dots on the right show the location of Repair Cafés around Germany." src="https://eco.kde.org/blog/images/2026-07-22-anstiftung.png"
style="max-width: 100%; height: auto"
/>
From Skepticism, To Support
The project's outreach to Repair Cafés in Germany started at the end of 2024 and early 2025. We were initially met with some skepticism. Software was simply not seen as being of interest to repair communities. Hardware, yes; anything related to real physical objects, sure. But software, not so much.
One of Opt Green's goals was to raise awareness about how software is as important to hardware longevity as physical components like batteries, cables, and screens. The repair motto "Repair Instead Of Throw Away" (in German: "Reparieren statt Wegwerfen") was perfectly in line with Opt Green's goals. The project had even adopted mottos with similar messages: "The most environmentally-friendly device is the one you already own!" and "You don't need a new computer—you just need the right software!" So we kept at it.
The project's first major platform to reach the German repair community was at an online presentation in March 2025 organized by Opt Green with the repair organization anstiftung. In the talk, we underscored how software drives e-waste along with other forms of energy and resource consumption. We showed how software repair—which FOSS licenses make possible—could extend the operating life of devices to reduce the environmental harm of hardware production, transportation, and disposal.
Around 180 Repair Café volunteers participated … and we were pleasantly suprised to learn that a handful of volunteers were already offering FOSS support in their Repair Cafés!
The first meetup was such a success that together with anstiftung we organized a follow-up webinar in May with End Of 10 contributors Varut & Herbert. A heartfelt thank you to both for presenting! What a joy to see at the second event again over 100 Repair Café volunteers interested to learn how to install and use FOSS on their own devices.
It seems that software is indeed of interest to repair communities!
As of July 2026, a little over one year after that second webinar, on the End Of 10 website there are 85+ places and 170+ events listed from Repair Cafés, Linux Cafés (i.e., repair cafés focused specifically on Linux), and similar organizations like IT-Cafés, Technik-Cafés, etc. (Once you include the Makerspaces, Hackerspaces, Fablabs, LUGs, and other initiatives that stepped up to help out, there are over 1180 places and events in total on the End Of 10 website—more on that in Part II.) Moreover, Repair Café International, an End Of 10 supporting organization, now lists 40 Linux Repair Cafés on their website. And the Restart Project published their own "End Of Windows 10 toolkit" to promote FOSS among repair groups as a way to keep unsupported Windows devices in use.
One End Of 10 contributor came up with a slogan which I feel captures this connection between repair and Free & Open Source Software beautifully, namely:
"FOSS Instead Of Toss!"
CC BY-SA 4.0 license. Redesign by Aaron Rainbolt.)" src="https://eco.kde.org/blog/images/2026-07-22-foss-instead-of-toss.png"
style="max-width: 100%; height: auto"
/>
Let's Bring FOSS and Repair Communities Together
In order to further strengthen the ties between FOSS and repair communities, the Opt Green project organized three in-person workshops from December 2025 to March 2026 with support from the funders UBA and BMUKN. The idea was to bring together local Repair Cafés, Fablabs, Linux User Groups, and related communities for a skills and information exchange. Each event took place in a different part of Germany: Hannover (middle), Nürnberg (south), and Dessau (east). Half of participants at each event were repair community members, half FOSS enthusiasts, and some belonged to both communities.
In the workshops a wide range of topics were covered, such as:
How can the FOSS community support Repair Cafés, and vice versa?
What are the barriers to adoption of Linux? What do new users need to succeed?
After installation, how much support can Repair Cafés realistically offer? Would user support fit into regular opening times? Could more technical problems be directed to collaborators in local FOSS groups?
How can Linux be promoted in local communities? What are the target groups? How does one reach them?
What platforms are there for Repair Café volunteers to exchange tips and support each other?
And more.
Before the workshops, we also held an install event for Repair Café volunteers new to Linux. That way they could roll their sleeves up and get some hands-on experience.
Clearly there is not one right answer to any of the above questions, while just having two days for an exchange between locally-networked groups was as important as any one comment or reply. Even though there is, as always, room for improvement, the feedback from these workshops from all involved was overall very positive. If you live in an area with active Repair Cafés and Linux User Groups I strongly recommend organizing similar cross-community workshops in your town. Don't hesitate to be in touch if you want some guidance!
Since March, several exciting updates have made it into our inbox.
We learned that four repair cafe volunteers from Repair-Café Wendelstein who attended the workshop have now started offering Linux support. Also, attendees from Reparatur Café Helmstedt have organized two install events and one Linux User Training in their café since the workshops. The Repair Café at the neighborhood cultural center Haus Drei in Hamburg now holds regular Linux installation workshops as well.
What is more, Repair Café Hilpoltstein, one of the groups that was already offering Linux support (their website is full of helpful information), has launched a Discourse forum (in German) to provide community support for Repair Café volunteers. If you help out at a Repair Café and want some guidance with Linux, this will be an excellent resource!
We also brought KDE Eco materials to the workshops in order to distribute them to interested groups around Germany and Austria. So it was great to see that Repair Café Hilpoltstein had an info stand at a local market in May, featuring among other things the "Environmentally-Friendly Software" leaflet (German version) from the Opt Green project.
The Repair Café workshops also led to other outreach opportunities. The Hilpoltstein group organized an info-meetup for FOSS in Volunteer Work in the Nürnberg region in June, with KDE Eco as a presentation partner. They are planning more local outreach in the near future as well, especially since Bavaria announced in June that no new deals will be made with Microsoft, at least for now.
FOSS and repair go together—and it is exciting to see FOSS and repair communities connect and grow. I am proud of the work Opt Green did in contributing to this. If there are Repair Cafés in your town or city, reach out to see how you can support their work!
Keep your eyes on this blog for the second installment about End Of 10, the global campaign started by Opt Green to promote FOSS as a way to prevent e-waste. As some of us in the community are saying: "FOSS instead of toss!"
When you need to buy new hardware, look into one of many Linux-supported devices on the market. That way you can use the computer for as long as the hardware keeps working. With devices made for Linux you will have a better out-of-the-box experience too, with less tinkering and fewer workarounds needed to get pesky proprietary-software components working.
If you instead decide to buy a new computer with Microsoft pre-installed but plan to install Linux instead, check out the Refund 4 Freedom initiative. Here you can learn how to get a refund for that Windows license you paid for even when you did not want it.
If you buy used hardware, you may also want to head over to the h-node project to learn how well that hardware will work with Free & Open Source Software.
Contact
We would love to hear from you! Sign up, say hello, and let us know what you are interested in.
The Code of Conduct for KDE communication channels can be found here.
Funding Notice
The Opt Green project was funded by the Federal Environment Agency (UBA) and the Federal Ministry for the Environment, Climate Action, Nature Conservation and Nuclear Safety (BMUKN1). The funds are made available by resolution of the German Bundestag.
The publisher is responsible for the content of this publication.
@anshs-lab:matrix.org
meven
GSoC
