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.
Excellent piece. I’m feeling unease at this widespread confusion between european ownership and digital freedom. What we collectively need is the latter. There’s no sovereignty to be had in a proprietary ecosystem, be it owned by an European company or not.
No the technology we use isn’t neutral… In this case it directly funds fascists. Whatever the technical merits from the Mullvad VPN, such ties disqualify them to be used.
This is a very good declaration and call to actions from the mathematics field. I wish we’d have something well thought out like this for computer science and software engineering as well.
Interesting study which measures our propensity to be more confident while being more wrong when using LLMs to answer questions. Those models really tap into our cognitive bias to mistake linguistic fluency for competence.
In other words: the security boundaries of coding agents are very porous and not where you expect. Handle with extreme care until they have a proper security model.
Little reminder that a got forge doesn’t and shouldn’t need much. Sprinkle gitolite if you need to manage rights, maybe gitweb and then you’re all set.
Quite a few nice Postgres tips. The first ones are rather basics the less common tips are toward the end. Could have a few more details at times, but that’s a good starting point.
Wondering how the graphics pipeline works for 3D rendering? This is a nice lecture on how to implement a purely software one. If gives a good idea of what needs to happen.
This is too often forgotten by developers. Our job isn’t only about the technical side of things, we must also understand the domain the users are working in. It’s a part of the craft.
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.
When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.
You might also notice the absence of a warranty, or silence about responsibility for bug reports.
So let’s return to the question:
Who’s responsible for bug reports on old software versions?
An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:
Trademark
Trademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.
Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.
But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.
Which brings me to what I think is the most important part:
Doing only the legal minimum
“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”
These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?
I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.
What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.
Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.
Applying the social contract to this situation
Let’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?
If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.
No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.
But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.
That’s the power of respecting the social contract that exists between us.
But what is the FOSS social contract?
Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:
Using FOSS
If you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.
Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.
Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.
If you don’t like the software you’re using, use something else.
Bug reporting
Endeavor to report bugs in the right place, to the best of your ability.
Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.
If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.
Software development
Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.
Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.
Don’t piss off too many of your users. You’re doing this for them, not just for yourself.
Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.
Software distribution
Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.
Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.
Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.
Minuet is a KDE's application for music education. It helps students and musicians train their ears with exercises for intervals, chords, scales, and rhythms. Minuet 26.08 is shaping up to be a particularly exciting release, with new ways to practice, a redesigned interface, and support for more platforms. We would love your help testing these changes before the final release. Try the exercises described below, explore the application on your devices, and tell us about any problems you find.
CI builds are beta snapshots rather than finished releases, so please do not rely on them for important work. Installation instructions are at the end of this post.
A redesigned, responsive interface
Minuet has a new interface built to work well on both desktop and mobile screens. The home page and navigation drawer make exercise categories easier to find, while the exercise browser presents each activity as a card with a short description. Your current category remains highlighted, and the new search field filters exercises by their translated names and descriptions. Exercise pages have also been reorganized to use the available space better on narrow windows and phones.
Things to test:
Browse every category from the drawer and return to the home page.
Search using full and partial exercise names, descriptions, different letter cases, and your system language.
Check the empty-search-results message and clear the search afterward.
Resize the window from very wide to very narrow and look for clipped controls, overlapping text, unnecessary scrollbars, or lost navigation state.
Try keyboard, mouse, and touch input where available, as well as both light and dark color schemes.
Answer questions correctly and incorrectly and check the answer animation, keyboard, staff, and controls.
The new exercise browser with several descriptive cards visible and a search term entered in the drawer
Guides for first-time users
The first melodic, rhythmic, singing, or clapping exercise you open now offers a short interactive guide (based on new Kirigami-addons onboard module). Each guide points out the controls and feedback relevant to that type of practice. You can decline the guide, finish or cancel it, and open it again later with the Help button.
Things to test:
Accept and complete each of the four guides: melodic, rhythmic, singing, and clapping.
Choose Not Now, leave the exercise, and confirm that Minuet does not repeatedly interrupt you.
Cancel a running guide and check that the exercise returns to its normal state.
Start a guide again from the Help button after completing or declining it.
Check that callouts point to the correct controls at different window sizes.
An exercise page with an onboarding callout highlighting the answer controls
More control over practice and sound
The new settings page gathers Minuet's everyday controls into Practice, Sound, and Microphone groups. You can change exercise speed, rhythm tempo, the number of rhythm patterns, test length, playback volume, melodic instrument, and percussion sound. Singing and clapping settings include the microphone input, voice class, pitch tolerance, timing tolerance, and calibration guidance. A collapsed Advanced section exposes detection algorithms and thresholds for difficult microphones or noisy rooms, with an option to restore the defaults.
Settings are persistent, so your choices should still be present the next time Minuet starts.
Things to test:
Change each basic setting and confirm that the next exercise uses the new value.
Select instruments from different General MIDI groups and try several percussion sounds.
Restart Minuet and confirm that your choices were saved.
Test microphone selection with no input device, one device, and multiple devices if possible.
Expand and collapse the Advanced section, adjust its controls, and use Reset to Defaults.
Check helper text, control labels, ranges, keyboard navigation, and layouts on narrow screens.
The settings page showing the basic controls sections
New melodic-interval exercises
Minuet previously separated ascending and descending melodic intervals. The new Melodic intervals collection mixes both directions, requiring you to identify the interval itself rather than anticipate its direction. It includes focused groups such as seconds or sixths, combinations such as fourths and fifths, and broader challenges covering compound intervals all the way through the fifteenth.
Things to test:
Confirm that questions include both ascending and descending intervals.
Work through focused, mixed, and compound-interval groups, including Second to 15th.
Replay questions and compare what you hear with the piano keyboard and staff.
Check enharmonic spellings, accidentals, ledger lines, answer choices, and scoring.
Start and stop a test run and verify that its length matches the configured number of exercises.
A compound melodic-interval question with its notes visible on both the staff and piano keyboard
Read and sing
Intervals and scales can now be practiced with your voice. After you choose Read and sing, Minuet plays a count-in and a reference note, listens through the microphone, and compares your pitch and timing with the target. The exercise view provides live input, pitch, and onset feedback. Scale exercises extend the same feedback across a complete sequence of notes.
Things to test:
Sing intervals and scales in each voice class: soprano, alto, tenor, and bass.
Try accurate notes, notes that are deliberately sharp or flat, early or late entries, and incomplete scales.
Change the pitch tolerance and confirm that the result becomes stricter or more forgiving.
Calibrate silence in a quiet room and with moderate background noise.
Try built-in, USB, and Bluetooth microphones where available, including switching devices while Minuet is running.
Deny and later grant microphone permission on platforms that request it.
Check that the interface remains responsive while audio is being analyzed.
A scale-singing exercise showing the target notes, live input meter, and pitch feedback
Read and clap
Rhythm exercises now offer a Read and clap mode. Minuet displays a rhythm, gives you a four-beat count-in, records your claps, and compares their onsets with the expected beats. The view includes an input meter, silence calibration, and timing feedback, while the settings let you tune the accepted timing tolerance.
Things to test:
Clap easy and medium patterns at slow, moderate, and fast tempos.
Try clapping exactly on the beat, near the tolerance boundary, and deliberately early or late.
Add, omit, or double a clap and check that the feedback identifies the mistake.
Change the timing tolerance and verify that scoring changes accordingly.
Calibrate in quiet and noisy environments and watch the input-level meter.
Check that the count-in finishes before Minuet begins evaluating your claps.
A completed clapping exercise with the rhythm cards, input meter, and timing feedback visible
Rhythms with rests
New Easy with rests and Medium with rests categories mix sounded notes with silent positions. You can identify these patterns by ear or read and clap them. In listening mode, Minuet avoids presenting answer choices that would sound identical; in clapping mode, every note-and-rest combination remains available.
Things to test:
Listen to easy and medium patterns and verify that notes and rests occur in the displayed positions.
Check that the available listening answers are audibly distinct.
Clap through the rests without adding sounds and confirm that silent beats are evaluated correctly.
Replay patterns, vary the rhythm tempo and pattern count, and try both single questions and test runs.
Look for incorrect rest symbols, spacing, playback duration, or answer evaluation.
An Easy rhythm question containing several clearly visible rests
Minuet on more devices
Minuet's interface and audio stack have been made more portable. Android builds now use FluidSynth and share the same streamlined interface as the desktop version. macOS builds are available for both Intel and Apple Silicon, with fixes for application data, translations, icons, audio, and microphone permissions. This cycle also introduces initial iOS build support, although iOS packages are not yet published by the CI pipeline.
Things to test:
Install, launch, close, and reopen Minuet on as many supported devices as possible.
Check the application icon, splash screen, About page, system language, light/dark theme, and screen rotation where applicable.
Run listening, singing, and clapping exercises and check playback, latency, recording permissions, and device selection.
On mobile, test drawer gestures, the on-screen keyboard, compact layouts, safe areas, and back navigation.
On macOS, compare Intel and Apple Silicon builds if both kinds of hardware are available.
Minuet's home shown side by side with desktop and mobile form factors
Under the hood
The visible changes are backed by a substantial technical update. Staff rendering now follows the Standard Music Font Layout (SMuFL) metadata from the Bravura music font, improving the placement of noteheads, stems, accidentals, ledger lines, clefs, and braces. FluidSynth support has been improved across platforms, while Aubio microphone analysis runs in a worker thread to keep the interface responsive. The QML and C++ code has also been split into more focused controllers and components, and automated coverage has grown for exercise evaluation, rests, audio analysis, and settings.
Things to test:
Inspect simple and dense notation, including chords, accidentals, compound intervals, ledger lines, treble and bass staves, and narrow layouts.
Listen for missing notes, wrong instruments, stuck sounds, timing drift, or audio that continues after leaving an exercise.
Navigate rapidly between exercises and settings while audio is playing or the microphone is active.
Run long singing and clapping sessions and watch for freezes, delayed feedback, excessive CPU use, or crashes.
Check that existing chord, scale, interval, rhythm, test, replay, and give-up workflows still behave as they did before.
A dense staff containing a chord, accidentals, and stems
Installing a CI build
Open the list of successful release/26.08 pipelines and select the newest pipeline. On its Jobs page, find the deployment job for your platform and use its download-artifacts button. Extract the downloaded ZIP archive before following the platform-specific steps below.
Artifacts are temporary: the Windows, macOS, and Android packages normally expire after three days, and the Flatpak packages after seven days. If a download is no longer available, return to the pipeline list and choose a newer successful pipeline. These packages are development snapshots and may trigger warnings about installing software outside an app store.
Linux
Download the artifact from the flatpak-amd64 job. The archive is named Flatpak_artifacts.zip.
Extract the archive and open a terminal in the extracted directory.
Launch Minuet from your application menu or run:
flatpak run org.kde.minuet
To test translations, also install the locale bundle:
flatpak install --user ./minuet-locale.flatpak
Install the application bundle:
flatpak install --user ./minuet.flatpak
The archive also contains minuet-debug.flatpak, which is useful for debugging but is not required for normal testing.
Windows
Download the artifact from craft_windows_qt6_x86_64.
Extract the archive and open its kde-ci-packages directory.
Run the included Minuet installer and follow its prompts.
If Windows displays a security warning for the development build, review the publisher and file details before choosing to continue.
The CI package targets 64-bit Windows on x86-64 processors.
NOTE: audio drivers are particularly worse on Windows, you can find some false negatives on such platform when compared to Linux, Android, and macOS.
macOS
Choose the job that matches your Mac:
craft_macos_qt6_arm64 for Apple Silicon Macs;
craft_macos_qt6_x86_64 for Intel Macs.
Download and extract the artifact, open kde-ci-packages, then open the included Minuet disk image or package and install the application. Because this is a development snapshot, macOS may show a Gatekeeper confirmation the first time you open it. Please also check that Minuet requests microphone access when starting a singing or clapping exercise.
Android
Choose the package matching your device:
craft_android_qt611_arm64 for most current phones and tablets;
craft_android_qt611_x86_64 for a compatible x86-64 device or emulator.
Download and extract the artifact, locate the Minuet APK in the package directories, and open it on the device. Android may ask you to permit installations from the application that opened the APK. Review the prompt, install Minuet, and disable that permission again afterward if you do not normally sideload applications.
Alternatively, developers with Android platform tools can connect a device or emulator and run:
adb install /path/to/minuet.apk
If an older development build is already installed and Android rejects the update because its signature differs, uninstall that build first. This removes its local Minuet settings and data.
iOS and FreeBSD
The 26.08 branch contains initial iOS support and is checked by the FreeBSD CI build, but the pipeline does not currently publish an installable package for either platform. The download instructions above therefore cover Linux, Windows, macOS, and Android only.
Send us your results
Please report bugs through KDE's Minuet bug tracker. Include the pipeline or commit you tested, your operating system and hardware architecture, clear steps to reproduce the problem, and what you expected to happen. For singing, clapping, or sound problems, microphone and audio-device details are especially helpful. Screenshots, short screen recordings, and relevant terminal output can make layout and audio issues much easier to diagnose.
A special shoutout and thanks to the KDE Sysadmin team for handling dependency additions, regenerating the CI images, and providing support with all the required CI/CD infrastructure.
Thank you for helping us make Minuet 26.08 a solid release for music learners everywhere!
This post has been long overdue, but let’s say I’ve been busy and the reason will be obvious in this short piece. ☺
As you might have heard a couple of months ago, the Sovereign Tech Fund did a large investment in KDE software development. From the announcement the details can be a bit sparse on what it actually entails. Especially regarding the part which says “the frameworks underlying its communication services”. It turns out this is what enioka Haute Couture is contracted by KDE e.V. to work on. Let me bring a bit more details about it.
What? Why?
The overarching theme of the investment is to make the KDE ecosystem more desirable for enterprise and public institution uses. The desktop shell (Plasma) and having a strong base to distribute it (KDE Linux) obviously comes to mind, but it’s also about the Personal Information Management (PIM) space. Nowadays a good chunk of the institutional life (public or otherwise) is to deal with email, contacts and calendars. So we set sail to strengthen Kontact, KMail, Korganizer and friends. More specifically, we want to strengthen its underlying infrastructure: Akonadi and its resources.
OK, OK, you’re still here? So read on for a few more details even though I obviously don’t want to steal their thunder.
There are three axis we’re focusing on:
Quality
Protocol support and modernisation
Ease of use and deployment
Quality
Those who know me also know what it means: more tests!!!
To be fair on the Akonadi server and resources side, we’re not too bad in terms of unit tests. The underlying protocol libraries as well have some unit test. The DAV side is maybe a bit weak and we hope to fix that, but on the IMAP side things aren’t too shabby.
That being said, we didn’t really have a test suite which would cover all the components integrated together. Those are more expensive and less fun to develop, so we’d be working on that by adopting a proof of concept done by Dan Vratil a while ago. It changed quite a lot but is becoming stronger with a comprehensive test suite covering IMAP and DAV.
Unsurprisingly it uncovered quite a few bugs we didn’t know about before starting the work, and gave us a nice environment to reproduce long known bugs that we had a hard time to chase down previously.
Of course, we’re working through the list of failing tests to fix everything we can. Some of my long hated bugs are already gone! Well, I use the master branch… so I live in the future from you dear readers, and the future is definitely better here.
Protocol Support and Modernisation
Our PIM suite supports many protocols… but in the case of enterprise use in a sovereign context (so having some control on the server side, and using open protocols), IMAP4, CalDAV, and iTIP (for invitations) are kings. So we’re focusing on modernising our support for them.
In particular we’re aiming at better support of IMAP4rev2 enabled servers, but also QRESYNC. This should bring a better use of network resources and faster resync.
On the DAV side, we’re looking at supporting push notifications. This is currently not completely standardised but we’ll be ready as soon as it is. Everything will be in place to track the specification as it matures. Thanks to this work, we’ll also improve the syncing code of the DAV resource, again using less network bandwidth.
Obviously iTIP support benefits from both. It also highlights issues on the DAV support which we’re fixing as we find them.
Ease of Use and Deployment
The architecture of Akonadi means that a user setup of the solution has quite a few components to configure. This is not necessarily a problem in itself, but we could make things easier and at times it’s mostly about configuring each protocol manually and separately.
Of course, there’s a specification proposed to support autoconfiguration based on just an email and a password. We got some partial support for it in KMail, but we’ll work on completing this and bringing it closer to System Settings. Couple that to some device management facilities in say… KDE Linux and that starts to look like a strong proposal for enterprise.
Finally, we’ll look into the Flatpak version of our PIM suite and see how to make it easier to integrate in the desktop. The possibilities are fairly limited for now and we’d like to make it first class going forward.
What to Expect
Obviously for the time being we can expect more activity in KDE PIM which is good. We have quite a few patches in the PIM repositories at this point and some of the improvement will be released really soon as part of 26.08! Some more will come in the next release (26.12) of course but it still required too much QA and missed the freeze. No matter, it’s not a long wait.
Also, we hope that it’ll be easier to deploy and setup when we get to tackle the Flatpak related tasks. Really looking forward to this! We hope to deliver this by the end of the year or early 2027. Which would mark the end of the project for us.
Later on, I hope this infrastructure work will attract more users and contributors again. Indeed, there’s still interesting work needed on the application side of things, but if the protocol support and quality of the base system is stronger, it makes it easier to try new things with the applications, less pieces to fight with will make the whole endeavour more desirable.
@xevrion:matrix.org
GSoC
ngraham
