Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• kdeconnect: Fix orientation of an arrow within the plasmoid (Commit, fixes bug #524889)
• kongress: Fix opening the room map from a talk (Commit)
• okular: Fix a crash when saving documents (Commit, fixes bugs #477153 and #505130)

Distro and app store packagers should update their application packages.

• 26.08 release notes for information on tarballs and known issues.
• Package download wiki page
• 26.08.1 source info page
• 26.08.1 full changelog

10 Sep 2026 12:00am GMT

Wednesday, 9 September 2026

KDE today announces the release of KDE Frameworks 6.30.0.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version

09 Sep 2026 12:00am GMT

Its been a minute since my last posts when I went over plasma-keyboard and its new diacritics feature, and the mega-sprint in Graz.

Overview​

I've been busy with a whole lot of things, but here's a brief highlight:

• Tons of bugfixes for plasma-keyboard and the diacritics feature after some distros set plasma-keyboard to be on by default. This unexpected new batch of testers found a host of bugs that warranted a bunch of frenetic bugfixing after the launch of Plasma 6.7; thankfully these were successful and the flow of bug reports slowed
• Improved the plasma-keyboard documentation for new contributors
• Added a bunch of unit tests for plasma-keyboard; a few months ago we had 0% test coverage and now we have 57% of C++ code covered by tests (would prefer it higher, but progress!)
• Added apidox to some difficult kwin code
• plasma-setup maintenance (we've had new contributors 🎉, bugs, proposals, etc)
• In relation to the STF grant to KDE, I've been doing technical review on behalf of the e.V. for all the changes being done (spoiler alert: a massive amount of amazing work has been/is being done!)
• A whole bunch of gardening, reviews, bug triage/fixing, etc - not so much of the fun stuff I would like such as the new plasma-keyboard features I have planned, but important work that has been needful
• Fixed the OSK (on-screen keyboard) button on the lock screen, and added a matching one to plasma-login-manager
• Hopefully being merged in time for 6.8: redesigned/fixed up system tray applet for plasma-keyboard

ci-healthcheck​

I created a utility to check the health of KDE CI along with a web dashboard to visualize the results, and began making weekly updates on the state of all Plasma's CI health on the mailing list.

In the beginning we regularly had a dozen or more repos with CI failing on master, dozens of repos whose CI hadn't been run in months or in a few cases years, and 14% of repos configured to report failing tests in the MR view.

Now we usually never have more than 1 or 2 repo with failing CI in master any given week and even had a few weeks in a row with no failing CI, every Plasma repo runs its CI against master at least once a week to catch issues, and fully 94% of Plasma repos are configured to report failing tests in the MR view.

I consider this a massive success! 🎉🎉🎉

Still more that can be done to improve the reports and CI health, but kudos to everyone for helping trim the fat and keep our software stack healthy and reliable! 🍪

plasma-morekeys​

There have been requests for plasma-keyboard to support full-sized keyboard layouts, however there has been debate about if that is appropriate to have in plasma-keyboard; such a feature seems like it would be rather niche, while adding a fair amount of complexity and maintenance burden.

Full-sized layouts wouldn't add any benefit for the vast majority of users who want a way to type in a search, a text message, etc - it seems like a much rarer user who would want to perform desktop keyboard shortcuts, use vim in a terminal, change tty from their OSK instead of a real keyboard, etc.

The super talented Aleix created plasma-morekeys as a solution for those who want a full keyboard layout that simply emulates a real keyboard and can do all of the above mentioned things like keyboard shortcuts, and more.

This is intended as a test; it was put together quickly so those who need this feature can try it and provide feedback. If it proves successful then we can transition it to an official project, perhaps provide integration with plasma-keyboard to make choosing/using it seamless.

If you are one of the people with interest in a full-size keyboard layout for your OSK, please give it a try:

• Install the plasma-morekeys flatpak (consider this alpha software!):

curl -L -o /tmp/plasma-morekeys.flatpak "https://nextcloud.merritt.codes/s/x4gqrs596NPYarF/download" && flatpak install --user --or-update --bundle /tmp/plasma-morekeys.flatpak

• Test out how it works for your usecases
• If you encounter bugs or find it isn't quite working how you require, report it and tell us what's wrong and what your usecase is so we can try and address it

Akademy​

Its just over a week until Akademy!! I'm looking forward to seeing a whole bunch of my KDE family again in Graz, and the chance to get some important work done together.

I have a bit of face blindness, so please don't be offended if I can't recognize everyone on sight! (I often rely on other cues like mannerisms, hair style, voice, etc)

I will try my best to be outgoing, but if I come across as a very anxious wallflower please know that I am friendly and super happy to see you all, and I appreciate the social butterflies pulling me into the mix! 😆

See you soon! 👋👋👋

08 Sep 2026 12:00am GMT

Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.7.5.

Plasma 6.7 was released in June 2026 with many feature refinements and new modules to complete the desktop experience.

This release adds a month's worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

View full changelog

08 Sep 2026 12:00am GMT

I tagged v0.0.11 last night. Or this morning. I've stopped keeping track of which side of midnight things happen on.

Most of what's in this tag I already went on about on Monday, in the weekly update: the harp swapping, the Guitar Pro files, the pitch detectors that turn out not to hear chords. Go read that one if you want the long version, and it is a long version, I checked. This is only about the four things that landed after I wrote it.

Four things. Well. Three things, because one of them was me deleting a line out of a TODO file, and I'm not going to make you read a paragraph about that.

The harmonica I made up

So there was this line in my TODO list, and it said my chromatic harmonica was modelled as reaching less of its range than a diatonic, which is backwards. Chromatics are the ones that get all the notes. That's the deal with a chromatic. You press the little button on the side and you get the notes in between, that is the entire pitch of the instrument, that's why it costs four times as much as the other one.

So I went in to fix it, expecting to add a missing technique somewhere, and what I found instead was that the layout in my code was not a chromatic harmonica. It was not a harmonica at all. It was a C major scale going up one note per hole. C D E F G A B C D E F G, straight up, like somebody had typed a scale into an array and gone to lunch, which, in fairness, is exactly what happened, and the somebody was me.

A real 12-hole chromatic is solo tuned. It goes C E G C, then D F A B, and that four hole group repeats up the instrument for three octaves. That repeating is the whole point of it. That's what makes one fingering work in every octave, that's the thing you're buying. Mine repeated nothing. Mine also stopped at A5 instead of C7, so fourteen of the thirty seven semitones between C4 and C7 weren't reachable at all, on an instrument whose one job is reaching all of them.

Fourteen out of thirty seven. On the chromatic. The one that gets all the notes.

Nobody noticed, and here's the bad part

Now you'd think somebody would have noticed, and here is why nobody did, and it's the part that actually bothers me.

Both of the chromatic charts I ship had the made up layout copied into them. Both of them. So they agreed with the code perfectly, and the code agreed with them, and everybody in there was consistent and confident and describing an instrument nobody owns.

One of those two charts, and I want you to appreciate this with me, one of those two charts is the lesson that teaches you the chromatic slide.

So if you had gone out and bought a real chromatic harmonica, an actual physical one, made of metal, by a company, and you'd sat down to learn the slide from my game, the hole numbers would have been wrong. Every one of them. And nothing anywhere would have told you why, and you would have assumed the problem was you, because when you're learning an instrument you always assume the problem is you, and about nine times in ten you're right, and this was the tenth time.

Both charts are re-fingered onto the real instrument now. The music didn't change, and it couldn't, because every event already recorded the pitch it sounds and those pitches were fine. It was only ever the hole numbers that were imaginary. So I re-resolved each event from its note instead of its hole: thirty three of them in Für Elise, sixteen in the lesson. Not one note moved.

The slide lesson does now teach ten slides instead of fourteen, because on a real solo tuned harmonica more of those notes just sit on a plain reed and don't need the button. Which is fine. Ten slides is plenty of slides.

And the test that would have caught this doesn't compare the charts to themselves, because as established they were extremely happy with themselves. It compares them against a tuning this codebase can actually build.

The staff was lying too, only quietly

Two smaller ones, both in the notation strip along the top.

Accidentals were drawn per note instead of per bar. So if a tune leans on one altered note, and blues tunes do, a second position blues leans on its F# all day long, you got the same sharp redrawn in front of every single note. Which looks silly, but it's worse than silly, because each one is about eleven pixels wide and an eighth note only has seventeen pixels to give in the first place.

They hold for the rest of the bar now, like they do on paper. And every note that cancels one gets a real natural sign, because just skipping the repeats would have left a later plain F in that bar reading as an F#, and I'd have gone from drawing something redundant to drawing something false, which is a worse trade than it sounds.

The staff itself was a fixed thirty four pixels per beat, and a notehead plus the accidental in front of it wants about twenty one, and a sixteenth note was getting eight and a half. They overlapped. Of course they overlapped. It works out the spacing from each song's own density now, with a cap on it, because otherwise one busy bar shrinks how far ahead you can see down to about a bar and a half, and then you can't read the thing at all.

That's v0.0.11. Still 0.0.x, still early, still on GitHub, still, as of this week, no longer shipping an instrument that does not exist.

08 Sep 2026 12:00am GMT

I'm getting old (though, not as old as the image below), and I miss the good old days when using Linux was more difficult, but when every system in a Linux desktop session was simple.

This was before polkit, systemd, … Even before DBus and PulseAudio. All of these systems are cool and all, but I sometimes miss the simplicity of "everything can be a shell script".

I've been playing around with something that made me investigate how the Plasma session is started, and if I can replicate it without significant issues with a simple shell script or something else.

It turns out it is not that difficult of a process, just a bit convoluted.

Your chosen display manager starts startplasma. A DBus session is created and startplasmacompositor (and kwin_wayland) is started. Then plasma_session starts. And it starts kded6 and ksmserver. There are a few other things that are started as well (like kactivitymanagerd), but they are started automagically by DBus when another component tries to use their DBus API.

Moving to a shell script

In the old days, there was just a simple shell script called startkde which set the environment variables and started all the needed processes for a working KDE (and later Plasma) session. It wasn't pretty, it wasn't efficient, but it did what it needed to.

Se I decided to try to reimplement a rudimentary version of that script for the new Plasma.

These are the basic environment variables you'd want set before running a Plasma session (or other UI applications):

# XDG
export XDG_SESSION_TYPE=wayland
export XDG_CURRENT_DESKTOP=KDE
export XDG_SESSION_DESKTOP=KDE

# Qt
export QT_QPA_PLATFORM=wayland
export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_WAYLAND_RECONNECT=1
export QSG_RHI_BACKEND=vulkan

# KDE
export DESKTOP_SESSION=plasma
export KDE_FULL_SESSION=true
export KDE_SESSION_VERSION=6

I placed this into a seaprate script called env.sh as it is useful for testing to be able to initialize the same environment in a shell outside of startkde.

Apart from these, if you have some custom installation paths for Qt or KDE things, you should also set PATH, XDG_DATA_DIRS, XDG_CONFIG_DIRS, QT_PLUGIN_PATH, QML2_IMPORT_PATH and QT_QUICK_CONTROLS_STYLE_PATH.

If you have any custom environment variables defined in ~/.config/plasma-workspace/env, you should add them here as well (or source all the files from that directory).

For the main script, just source env.sh, run dbus-update-activation-environment --all and start all the session components mentioned above:

source env.sh
dbus-update-activation-environment --all
kwin_wayland --drm &
KWIN_PID=$!
sleep 1

export WAYLAND_DISPLAY=wayland-0
kactivitymanagerd &
ksmserver &
kded6 &
plasmashell &
krunner &
# other things you want started along with Plasma

wait $KWIN_PID

The sleep 1 is evil and there are better ways to check if wayland-0 became available, but this is a quick and dirty script after all. And the original startkde script also had some sleeps in it.

The only thing remaining is to create a session file that your display manager can use, and you're good to go (/usr/share/wayland-session/shellscript-based-startplasma.desktop)):

...
Exec=dbus-run-session -- /path/to/the/script.sh
...

This seems to work without important issues, it just skips the splash screen which I can live without (wow, ksplashqml is 15 years old…).

I didn't test it for too long, as I quickly replaced this shell script with a dinit-based setup, but more on that in the next post.

07 Sep 2026 8:10am GMT

Gwenview has been KDE's flagship image viewer for over 25 years. It works, it's feature-packed, and it's been modernized repeatedly. Gwenview has served generations of KDE users faithfully and well.

So… why build a replacement?

Well, over the years Gwenview has fallen behind in some areas that can't easily be retrofitted without rewriting half of it anyway - like better performance with large image libraries, GPU acceleration, mobile-friendliness, and the kind of enjoyably hackable QtQuick UI that would make it easier to modernize and engage a new generation of contributors.

Either by way of illustration or as a result of the above, community contributions of features, bug fixes, and UI improvements to Gwenview have dried up in recent years. It would appear that Gwenview's technical architecture has reached the limit of what people are willing to do with it.

Something new

Meet Photos (originally named "Koko"):

Actually I lied: Photos is not a new app. Its first release was five years ago, after extended development dating at least back to 2017. But it was always somewhat niche, because it began as a mobile app and couldn't match Gwenview in raw functionality and desktop-friendliness.

So over the past year, Techpaladin Software (full disclosure: I'm the CEO) has sponsored a bunch of development with the explicit goal of bringing Photos to parity with Gwenview as a first-class desktop app. Oliver's recent blog post contains lots of interesting details about the process.

Techpaladin folks will continue to contribute maintenance for a while, but our hope is that we've managed to bootstrap the app to the point where the KDE community can generally take over for further feature and UI development on the desktop side. Therefore…

Give it a try!

I'd like to invite users to try using Photos, and invite distros to consider replacing Gwenview with it - either soon, or in the future.

I'm sure it won't be perfect. Gwenview has had an extra 15 or so years in the metaphorical oven. But at this point Photos has pretty much all of the relevant features, plus some added goodies:

• Much better performance, especially with large photo libraries and high DPI screens
• Mobile-friendly UI that's also capable of being used as a very small window
• Shares Spectacle's amazing annotation system
• You can mark images as favorites
• Timeline, location, and "just show me all my images" views

So give it a try! The current 26.08 release is pretty good, and the upcoming 26.12 release will add a few more improvements.

If you find any bugs, sources of UI awkwardness, or missing features compared to Gwenview that you actually need and care about, feel free to report them on the Bugzilla page. And changes can be contributed via merge request on Photos' invent.kde.org page.

Let us know what you think! And if you like it, consider helping out with development or bug triaging. It takes a village to raise a child maintain an app.

07 Sep 2026 4:53am GMT

This is a weekly update, which means I did a week of things and now I'm going to tell you about them, and I should say up front that most of the week went on two problems that sound small when you write them down. You had to own the exact harmonica a chart was written for. And the chart had to be in my file format, the one I invented, the one nobody else has ever written anything in.

The one harmonica you own

Here's the thing about harmonicas. A diatonic is built in one key. Not tuned to one key, built in it, the reeds are physically cut for it, and if the chart says C and the harp in your pocket says G then you can't play that chart. Not badly, not with effort. You sit there and nothing you do produces the note.

And people learning have one harmonica. One. Whichever one turned up. So the situation where you open my game, pick a song, and discover it wasn't written for the only instrument you own isn't an edge case, it's Tuesday.

There are two honest answers to this and they go in opposite directions. You keep the tab and let the music move: same holes, same breath, different key. Or you keep the music and let the tab move: same tune, different holes. Both are defensible, I couldn't pick, so I built both and put them on a little screen that turns up after you choose a song.

That screen also tells you the damage. Something like "5 need a bend · 2 need an overblow · 9 can't be played". The nine is the number I built the screen for. If swapping your harp in quietly eats a fifth of the melody, I'd rather say it out loud and let you decide than hand you a chart with holes in it and let you assume you're the problem.

The test that went looking for one thing

The remapping code has a property test on it. It walks twelve source keys against twelve target keys, both harmonica families, every hole, both breath directions, in both of those modes I just described, and for every single combination it checks that anything the code calls playable is a pitch that harmonica can physically produce.

That check is the entire reason the test exists. If it fails, my game is sitting there listening for a note you cannot make, and then marking you down for not making it, and you'd have no way of knowing which of you was broken.

It told me I was wrong three times, and each time the code was right, which is why I wrote a test instead of trusting myself. A G harp is pitched below C, not above, so G4 sits on hole 4 and not hole 1. A#4 isn't on an F harp at all, and I had to go find a Bb before I could test the case I actually wanted. And transposing a chart onto its own harmonica isn't the no-op I'd assumed, because hole 3 blow and hole 2 draw are both G4 on a C harp, so resolving by pitch alone was quietly rewriting one into the other and telling me it had done nothing.

But that's not the interesting part.

The interesting part is that the same test, which I wrote to check transposition, sat down and told me about a bug that has nothing to do with transposition at all. The set of notes my scorer will accept from your microphone was built out of blow reeds, draw reeds and bends. Not overblows. Not overdraws. On a C harp, seven of the eight over-pitches simply were not in that set, which means any chart asking for an overblow could never be scored. Ever. Not once. And nothing on screen would have told you why.

Nobody hit it because none of the charts I ship use one. It was going to sit there until somebody wrote something advanced, and then it was going to look like a microphone problem, and they'd have spent an evening buying a better microphone.

Later in the week I found the same kind of thing pointing the other way. My table of how far each hole bends had every hole capped at a semitone and a half, which is just wrong. A bend pulls a reed toward the other reed in the same hole, so how far you can go is however much room is between them. Three full semitones on hole 3, which is the note you buy a harmonica in order to play. Nothing at all on holes 5 and 7. The table says that now, and there's a test comparing it against the physical layout, because two descriptions of one physical fact will come apart eventually and I'd rather find out from CI.

Somebody else's files

Harmonicon reads Guitar Pro now, gp3 through gp7, and MuseScore, and MusicXML, and MIDI. Drop one in a song folder and it gets found and converted and played.

Parsing them was the easy half. The hard half is that a tab file is a whole band. Bass, comp, melody, usually drums, and I have to work out which of those you meant. So every track gets converted on its own and fitted to its own harmonica, because the right harp for a melody is almost never the right harp for a bass line, and then you get a list telling you what you'd actually be able to play. "Track 1: 6 notes, 0% playable. Track 2: 100%."

If a track is called Harmonica it wins automatically, and I learned two exceptions to that by breaking things. A bass line called Harmonica handed me a chart with no playable notes in it at all, so being named right no longer beats being playable. And drum tracks now report zero notes on purpose, because their frets are drum kit indices, and if you read those as pitches you get a part that looks entirely reasonable, wins the picker, and then plays nothing whatsoever resembling the song.

The word "harp" on its own is deliberately not in my list of names to look for. It matches an orchestral harp. A harp part converted to harmonica is precisely the unplayable soup the list exists to prevent, and the arithmetic isn't close: missing a track called Harp costs you one click, matching a real one costs you a chart nobody alive can play.

All seven of them sit behind one trait in a new crate, so the next format is a module and a match arm. It cost more than I wanted. That crate went from 5 dependencies to 94, almost all of it zip and everything zip drags along behind it. I wrote the tradeoff down and slept on it before deciding, which I mention because I nearly didn't, and the thing that decided it was that zip is what MuseScore and the newer Guitar Pro containers genuinely need, so it buys three formats rather than propping up one.

Which of my detectors can hear a chord

Chord scoring has been in there for ages. It wants every pitch of the chord present at the same time, which is a reasonable thing to want. What I had never once checked is whether the pitch detectors can actually deliver it.

So I measured, on a real chord out of a real chart. FFT, which is the default, hears both notes. NMF hears both notes. YIN, pYIN and MPM hear neither.

And the three that fail don't fail quietly. pYIN and MPM both report an F4, confidently, a note which is not in the signal, which simply happens to sit between the two notes that are. So it isn't a chord going unscored. It's a wrong note strolling into the scorer with its hands in its pockets.

None of which was visible from inside the game. Choosing pYIN in the options made every chord in every chart unhittable and told you nothing. The picker says "pYIN, single notes only" now, and if the song you loaded has chords your detector can't hear, a banner says so.

While I was in there: unplugging your microphone in the middle of a song used to leave the game convinced it was still connected. Your notes just stopped scoring, forever, silently. Which is the exact failure I'd built a warning overlay for the week before, reachable by the more likely route the entire time, and I'd like it on the record that I found this myself before anybody else did.

Three hundred gigabytes

Now this next part isn't about the game at all and you can skip it, except that it ate two days, so.

My build directory had reached 300 gigabytes.

Two separate reasons, both boring, both mine. A debug binary was 2.41 GB, of which about ninety percent was debug information for dependencies I have never once stepped into. And cargo doesn't delete the old ones. So there were ninety-nine files of over a gigabyte each, sitting there, going back to August, every one of them a complete binary from some build I'd long since stopped caring about.

A few profile settings and a sweep later a debug binary is 287 MB, and a clean build plus the entire test suite leaves the whole tree at 7.1 GB.

While I was in the mood I also found the version number written in four different places that disagreed with each other, which meant the version the game showed you in Help / About was one that no release has ever actually carried. One script bumps all four now, and CI fails in about three seconds if the tag and the manifest disagree, rather than after four platform builds have finished uploading.

So: you can play a chart on the harmonica you own, or on the one it was written for, and either way it'll tell you what that's going to cost you before you start. And you can hand it a Guitar Pro file, and it'll work out which part of the band you meant.

1306 tests passing. Still 0.0.x, still early, still on GitHub.

07 Sep 2026 12:00am GMT

The past few weeks have been about turning my initial exploration of KDE NetworkManager into actual code.

I've been working on refactoring the VPN and other virtual connections, digging through the existing Plasma NM, NetworkManager, Qt, and its code to understand how everything fits together.

Why this needs doing

Plasma-NM is the part of Plasma that talks to NetworkManager. Most users encounter it through the network applet in the system tray, but the part I have been working on lives in the Connection Editor in System Settings-the place where you can add a Wi-Fi network, configure a static IP address, or set up a VPN.

The Connection Editor is built using Qt Widgets and .ui files, which follows a traditional Qt architecture. The .ui file describes the structure of the interface and is compiled by Qt's uic tool into C++ code. The resulting View owns and lays out the widgets that make up the interface, while the widgets handle user interaction and communicate with the underlying Model through methods and Qt's signal/slot mechanism.

Here is the flow chart for this

Image credit: Kevin Ottens

QML follows a somewhat different approach. Instead of the View directly owning and managing every UI widget, QML commonly uses a Model-View-Delegate architecture.

The Model provides the data that needs to be displayed. The View is responsible for displaying a collection of that data, while the Delegate defines how each individual item from the model should look and behave.

Now moving to the technical details of my implementation.

First and foremost, the folder structure. The current work lives in two places. A library holding the settings models and the QML views, and a KCM that ties them together:

 libs/editorqml/
├── settings/ C++ models, one per settings group
│ ├── generalSettings/
│ ├── wificonnectionsettings/
│ ├── wifisecurities/ Wi-Fi security and the shared 802.1x model
│ ├── wiredconnectionsettings/
│ ├── ipv4settings/
│ ├── ipv6settings/
│ └── vpn/
│ ├── openvpn/ openconnect/ l2tp/ pptp/ sstp/ ssh/
│ ├── vpnc/ strongswan/ libreswan/ iodine/ fortisslvpn/
│ └── wireguard/
└── qml/ the views, mirroring settings/
├── components/ one page per connection type
├── generalSettings/
├── wificonnectionsettings/
├── wifisecurity/ plus authentication/ and its EAP methods
├── wiredconnectionsettings/
├── ipv4/ ipv6/
└── vpn/<type>/
kcms/kcm_connections_qml/
├── kcm.cpp / kcm.h owns one instance of every settings model
└── ui/main.qml the connection list and the editor panel

Both editors live in the same source tree, separated by a build flag.

Everything new is behind -DBUILD_EDITORQML=ON flag, which is off by default. The flag gates exactly two directories, libs/editorqml and kcms/kcm_connections_qml.

Here is the detailed refactoring for the WifiConnectionType.

Wi-Fi is the largest of the connection types, having six tabs: Status, General, Wi-Fi, Wi-Fi Security, IPv4, and IPv6.

The straightforward half

WifiSetting is the model behind the Wi-Fi tab: a QObject exposing the fields the form edits (ssid, mode, bssid, band, channel, macAddress, clonedMacAddress, mtu, hidden), with three methods doing all the talking to NetworkManager. loadConfig() reads a WirelessSetting into those properties, setting() writes them back as a QVariantMap, and isValid() says whether they could be saved.

The QML then never mentions NetworkManager at all:

QQC2.TextField {
text: root.setting.ssid
onTextEdited: root.setting.ssid = text
}

WifiSetting does more than just store data. It also exposes availableSsids, availableBssids, macAddresses, and channels, which are not part of the connection at all. They come from the wireless hardware and fill the drop-downs, so you can pick a network rather than typing an SSID. The channel list even changes with the selected band. Putting them on the same object means the QML gets a value and its choices from one place.

The half that is actually interesting

Wi-Fi Security is not one form. It is ten, and a single enum decides which one you see:

enum SecurityType {
 None, WepHex, WepPassphrase, Leap, DynamicWep,
 WpaPsk, WpaEap, SAE, Wpa3SuiteB192, OWE
};

In the widget version, this was a stack swapped by index. In QML, it is a combo box and sub-forms whose visibility is bound to the selection:

QQC2.ComboBox {
currentIndex: root.wifiSetting.securityType
onActivated: root.wifiSetting.securityType = currentIndex
}
WpaPersonal {
visible: root.wifiSetting.securityType === WifiSecuritySetting.WpaPsk
|| root.wifiSetting.securityType === WifiSecuritySetting.SAE
}

Three of the ten (DynamicWep, WpaEap, Wpa3SuiteB192) have no fields of their own and hand the job to 802.1x, which is its own tree of seven EAP methods. This is where splitting the models paid off in a way I did not plan for.

802.1x is not a Wi-Fi thing; wired uses it too. Because Security8021xSetting is a plain QObject rather than a widget owned by a Wi-Fi tab, the wired editor binds to the same model and reuses the same seven QML files.

Validity forwards the same way, so the Save button ends up gated on an EAP form several levels down without anything in between knowing:

case WpaPsk:
 return NetworkManager::wpaPskIsValid(m_psk) || m_pskOption == AlwaysAsk;
case WpaEap:
 return m_8021xSetting->isValid();

Note the check comes from NetworkManagerQt rather than a regex written here, a rule I tried to keep throughout.

Wiring it together

The KCM is the piece that connects the two halves. kcm.cpp constructs one instance of every settings model and exposes each as a property:

Q_PROPERTY(WifiSetting *wifiSetting READ wifiSetting CONSTANT)
Q_PROPERTY(IPv4Settings *ipv4Settings READ ipv4Settings CONSTANT)

CONSTANT because the pointers never change. Only their contents do. That is what lets any QML file reach a model without being handed one:

PlasmaNMQ.WifiConnectionSettings {
setting: kcm.wifiSetting
}

Loading a connection walks the models in one direction. Selecting a row calls loadConnectionSettings(), which hands the NetworkManager settings to each model's loadConfig() in turn, then fires requestSecrets() over D-Bus.

Secrets come back later and asynchronously, so a small hash maps a setting name to the model that wants it:

m_secretsHandlers = {
 {"802-11-wireless-security", [this](auto setting) {
 m_wifiSecurity->loadSecrets(...);
 }},
 {"vpn", ...},
};

Each model's setting() returns a QVariantMap, applyTypeSettings() assembles the ones the current connection type needs into an NMVariantMapMap, and that single map goes to the Handler, which is the only place D-Bus writes happen. The editor never talks to NetworkManager itself.

Two more signals are present. Every model emits validChanged, which the KCM aggregates into one connectionValid property that the Save button binds to, so a malformed key three levels down inside an EAP form greys out the button. The same signals mark the KCM dirty, which is what makes the Apply button light up.

Which page appears is decided by one property. kcm.connectionType comes straight from the connection, and a Loader switches on it:

switch (kcm.connectionType) {
case PlasmaNM.Enums.Wireless: return wireless;
case PlasmaNM.Enums.Wired: return wired;
case PlasmaNM.Enums.Vpn: return vpn;
case PlasmaNM.Enums.WireGuard: return wireguard;
}

For VPNs, there is a second switch inside that one, based on the service type, which picks the right page from qml/vpn/. This nested lookup replaces the VpnUiPlugin mechanism, since the old contract returned a QWidget, which is incompatible with the QML-based approach.

What is left

The editor now covers Wi-Fi, wired, IPv4 and IPv6, all eleven VPN types, WireGuard, and importing and exporting VPN profiles. That is most of what a person meets day to day, but it is not everything the widget editor does.

Connection types still on widgets

Mobile broadband is the big one, and it is not just a settings page. Adding a GSM or CDMA connection runs a whole wizard that asks for the country, provider, and plan, backed by a provider database.

Then there are the virtual types: bond, bridge, VLAN, and team. These are the ones that let you build an interface out of other interfaces. DSL, Hotspot and the shared PPP settings are also in the list.

Flows around the editor

Creating a connection is in progress: the type chooser and per-type defaults work, and the Save button is now gated on real validation rather than a non-empty name, but it still needs finishing.

Export works for OpenVPN and vpnc, which is not a limitation of the port but of the plugins, since the other nine never implemented it. WireGuard import still needs its own path because it does not go through a VPN plugin like the others.

The dependency that is outside of the KCM

This is the part I had not expected. Finishing the QML editor does not mean the widget library can be deleted, because the widget editor is reachable from more than just the KCM.

libs/CMakeLists.txt has the core library linking to the editor library, not the other way around, which means Handler can open a ConnectionEditorDialog itself. That is how the applet raises the full editor for a WPA-Enterprise network it cannot join with a password alone, and kded links the same library for the secret-agent prompt. The pindialog, password dialog and secret agent from Kded also need refactoring.

So the port has a second half that has nothing to do with System Settings: those call sites need a QML equivalent before anything can be removed.

The finish line is deleting libs/editor, removing the widget KCM, and dropping the build flag, so that there is one editor again rather than two. Everything above is what stands between here and there.

Thanks, see you soon.

06 Sep 2026 4:37pm GMT

Last week I attended this year's State of the Map (SotM) in Paris, France, OpenStreetMap's annual conference. This was actually my first time making it to SotM since I started working with OSM data for KDE Itinerary eight years or so ago.

All links to talks below go the their abstracts, video recordings are still being added to the OSM FR Peertube instance at the time of writing.

Public Transport

On Saturday I had the chance to present Transitous, right after Felix's and Robin's talk about MOTIS, the routing engine we use in Transitous.

Transitous also got mentioned in a couple of other talks, including Cartes announcing integration with Transitous and CoMaps announcing work towards that as well. Overall we got very positive feedback for Transitous.

SotM being in Paris also meant there were a number of participants and presentations from SNCF and wider French public transport ecosystem. This also once again demonstrated why we need things like the Open Transport Community Conference, unsurprisingly a lot of challenges in this field exist in all countries and more international exchange could avoid some duplicated efforts.

Outside of the conference program there were also a few discussions on how to move specific topics in Transitous forward, such as integration with Citybikes or improving GTFS data deduplication and measuring GTFS feed overlap.

Indoor Mapping

SotM allowed me to meet a few people in real life that I had only encountered online in the quarterly online OSM indoor meetup so far. The work Antoine is doing on train stations or Gwenaëlle is doing on accessibility and universities isn't "just" mapping, it's also pushing modelling and tagging schemes in OSM forward.

I also got a chance to talk to the team from Sozialhelden about their ongoing work on elevator status data (realtime disruptions and planned maintenance times), and how we could move forward with matching that to OSM data. That's a prerequisite for integrating elevator status data into Transitous, an eagerly awaited feature there given the huge impact this has on wheelchair routing.

A rather different but also important topic was QA tooling for indoor mapping. For OSM in general there's not only a number tools but also quite some research on e.g. reachability or completeness metrics. For indoor spaces this is still largely uncovered, so it was good to see lightning talks in the scientific track on that.

Yet another topic that came up was the documentation, training and onboarding story for indoor mapping. Even some very experienced OSM mappers see indoor mapping apparently as hard and unapproachable, something easy to lose sight of when stuck deep in modelling and tagging issues.

Dynamic OSM

Since the discussions at the FOSSGIS conference and the discoveries presented at Grazer Linuxtage earlier this year the momentum around dynamic (traffic) data keeps building, there was a packed BoF session on this at SotM as well.

There's a very broad interest in this, besides the usual suspects like the FOSS routing engines and map/navigation apps there were a number of national agencies present and indicating their support for an open solution, as well as firefighters unhappy with Google routing them around accidents while actually needing to go towards them.

There's currently three approaches being developed:

• OSM Road Closures by SOSM, focusing on (crowd-sourced) road closure tracking and being modeled around OpenLR.
• "OSM-RT" by the MOTIS team, inspired by GTFS-RT and OSM changesets, provding a dynamic layer on top of OSM using the existing OSM data models, identifiers and tagging schemes (not unlike what we do for Kongress as well).
• OpenEventDatabase, modeled around GeoJSON geometry and a generic tagging scheme.

Those aren't necessarily competing, but complement each other. OpenEventDatabase shows that there's usecases for this way beyond traffic data, OSM-RT looks like an elegant and efficient way to distribute and combine dynamic data feeds from different sources into applications, and both crowd-sourcing and integrating existing official data probably needs a more domain-specific view as adopted by the OSM Road Closure database.

One concrete outcome of the BoF session is that there's no a Matrix channel for coordinating work around dynamic OSM data, as this probably only has a chance of gaining critical mass and going anywhere if we manage to align all this. That remains hugely ambitous of course, but seeing how eager people and organizations seem to be to break free of the monopolies in this area, this might actually work out.

KDE Integration

There's also a few outcomes that immediately benefit users of various KDE apps:

• The SotM venue had indoor mapping usable by Kongress, resulting in a few fixes for this. Kongress can now also add talks or sessions directly to your system calendar (on Linux and Android). Unfortunately no doors were mapped in the venue, which meant we couldn't test the built-in routing in Kongress.
• Itinerary and KTrip now filter out service alerts for (planned) events way outside of your time of travel, such as future construction work. This makes results in Paris a bit more readable, where there's service alerts for works up to half a year into the future.
• We now have a geo: URI handler for Cartes built in, so you can select that in System Settings as the default map (MR 233, part of KF 6.30). I had previously failed to figure out the details for this, after talking to the Cartes team it was just a matter of a few minutes.

And more

All of this is barely scratching the surface of SotM, the topics and the community are far broader than this. Seeing talks on how software and data from the OSM community is essential for emergency services, or helped during the response to the recent earthquakes in Venezuela show how much real-world impact what we do can have.

Hearing the head of the French National Geographic Institute (IGN) very explicitly state in his closing remarks that (digital) sovereignty can only be achieved by openness and collaboration rather than by closing down and adding borders was also encouraging, many public agencies have yet to understand that.

SotM was my start into the conference season, two other major events for me follow in quick succession now, KDE Akademy in Graz, Austria in just two weeks, and the Open Transport Community Conference early October in Bern, Switzerland.

05 Sep 2026 6:45am GMT

Welcome to a new issue of This Week in Plasma!

Some of the last Plasma 6.8 features landed this week, and there's a whole bunch of great stuff! Let's jump right in:

Notable new features

Plasma 6.8

Plasma now features a built-in "dwell clicker" feature! This is an accessibility tool that automatically clicks whenever the pointer is moved somewhere and then left alone for a moment - and what constitutes a "moment" is configurable, of course. It works really well. You can learn a bit more about it on Sebastian's blog. (Sebastian Sauer, KDE Bugzilla #521391)

Speaking of pointers and clicking… the feature to scroll by holding down the middle mouse button and moving the pointer now has a new optional triggering mode: you can press the middle mouse button to enter and exit this scrolling mode, without having to hold it down. This makes it bit closer to the "Autoscroll" feature on Windows. (Uriel Fontan, KDE Bugzilla #495617)

Plasma's ever-growing list of alternate calendar layouts now includes the Bikram Sambat calendar used in Nepal and parts of India. (Satya Prakash Dahal, KDE Bugzilla #500298)

There's now a new remote desktop mode that locks the remote computer's physical screens upon connection, and shows a newly-created virtual screen to the user who is connecting. (David Edmundson, krdp MR #230)

Screen readers can now ask KWin what window is under the pointer. (Nicolas Fella, kwin MR #9825)

Union styles now appear on System Settings' Application Styles page! This will make it easier to use and test them, and you can also import them from files, too. (Arjen Hiemstra, plasma-workspace MR #6970)

Notable UI improvements

Plasma 6.8

You can now disable a screen or other output only when this is actually supported. (David Edmundson, kscreen MR #512)

The mouse keys acceleration spinbox no longer claims it's showing milliseconds, because it isn't! (Nicolas Fella, plasma-desktop MR #2854)

When you resize the Display Configuration widget, the buttons within it resize smoothly, not jerkily. (Michal Malinowski, kscreen MR #513)

The off-by-default feature to show tooltip thumbnails when clicking on a grouped Task Manager Task (kind of like how Windows does it) now works in a more natural-feeling way. (Christoph Wolk, KDE Bugzilla #484206)

KDE Gear 26.12.0

The expander arrow for notifications in KDE Connect's widget now points in the correct direction in all states, including when using a right-to-left language. (Ely Golden and Nate Graham, KDE Bugzilla #524889)

Notable bug fixes

Plasma 6.6.7

Fixed an issue that could make the Maliit on-screen keyboard crash at seemingly-random times. (Sebastian Müller, kwin MR #9818)

If a Plasma Vault with the "Go offline while this vault is open" feature is left open when the system shuts down, networking is now restored on the next login as expected. (Just Karol, KDE Bugzilla #457680)

Clicking on a link in a notification no longer also invokes the notification's default action. (Kai Uwe Broulik, plasma-workspace MR #7003)

Plasma 6.7.5

Fixed a somewhat common way that KDE's background daemon could crash when connecting to a Wi-Fi network or creating a hotspot. (Mickaël Thomas, KDE Bugzilla #522489)

Fixed a somewhat common way that Plasma could crash while shutting down or restarting when there was a Weather Report widget in the panel. (Bohdan Onofriichuk, KDE Bugzilla #524929)

Discover no longer fails to check for updates on operating systems that integrate the fwupd firmware updater system into Discover, but where its background process quits early while Discover is still running. (Tobias Fella, KDE Bugzilla #521682)

Task Manager tasks' progress bars now work as expected when using a right-to-left language. (Christoph Wolk, KDE Bugzilla #524112)

Fixed a recent regression in Discover that made it show a banner about updates requiring a restart for too many types of updates. (Aleix Pol Gonzalez, discover MR #1404)

Fixed a bug that made scrolling through Alt+Tab items with a mouse wheel only work in one direction. (Vlad Zahorodnii, KDE Bugzilla #522229)

Apps that resize their windows immediately after launching are now still positioned correctly according to the "Centered" window placement mode. (Vlad Zahorodnii, KDE Bugzilla #525036)

Fixed some visual glitches in the Eye On Screen effect. (Sudip Datta, KDE Bugzilla #481100)

Fixed the Apply and Help buttons in the Clipboard settings window not working always, or at all, respectively. (Tomáš Hnyk, KDE Bugzilla #485460 and plasma-workspace MR #6992)

Plasma 6.8

Apps or the user can no longer crash KWin by sending malformed shortcut assignment requests over D-Bus. (Vlad Zahorodnii, KDE Bugzilla #524700)

On System Settings' Power Management page, the spinboxes used to configure charge limits now work properly when you type numbers into them. (Christoph Wolk, KDE Bugzilla #505071)

Notable in performance & technical

Plasma 6.7.5

Changing your system languages now sends the same data correctly to Flatpak apps, so they can more reliably display the languages you asked for. (Harald Sitter, plasma-workspace MR #6883)

Plasma 6.8

Screen recordings made by Spectacle and any other app using the KPipeWire library are now higher in quality. (Sergey Katunin, kpipwire MR #278)

Reduced the amount of VRAM that Plasma's Breeze theme requires by optimizing some of its SVG assets. (Méven Car, libplasma MR #1567)

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

Push a commit to the relevant merge request on invent.kde.org.

04 Sep 2026 6:17pm GMT

Back from vacations and I did some catch up late at night… So expect a larger selection than usual. Let's go for my web review for the week 2026-36.

WEBMASTER@ a manifesto for everyone

Tags: tech, web, internet, culture, history

A very uplifting essay in my opinion. Starts with a historical perspective on the webmaster role to then evolve into a manifesto about creation on the web.

https://brennan.day/webmaster-a-manifesto-for-everyone/

There's no such thing as Just a Tool

Tags: tech, tools, philosophy, framework, design

Indeed, it's high time our industry leaves the "it's just a tool" rhetoric behind. This claim is a way for us to not take our responsibilities in the design of the tools we make.

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

Normalized Fascism in Open Source: $12 Million Given to DHH

Tags: tech, foss, politics

There's no "apolitical" projects. Claiming the contrary is just trying to hide your agenda. While our engineer culture keeps falling for it, really bad actors are benefiting from it…

https://brennan.day/normalized-fascism-in-open-source-12-million-given-to-dhh/

Meta's $17 Billion Settlement is a Bad Deal for Teens and All Social Media Users

Tags: tech, facebook, social-media, law, surveillance

This is not indeed the win you'd expect. More surveillance coming pushed by the settlement…

https://www.eff.org/deeplinks/2026/09/metas-17-billion-settlement-bad-deal-teens-and-all-social-media-users

The actual epistemic crisis

Tags: tech, ai, machine-learning, gpt, fake, fake-news, knowledge, politics

Very important opinion piece from Cory Doctorow again. The trend was clear of an epistemic crisis brewing and generative AI basically put it on steroids. This is a real blow to our civilisation.

https://pluralistic.net/2026/08/20/epistemic-void/#expert-agencies

The people vs the AI overlords

Tags: tech, ai, machine-learning, copilot, politics

Clearly there's a political project behind the design of those tools. Clearly our industry is lacking enough class consciousness to push back against the "AI overlords" agenda.

https://anarc.at/blog/2026-08-18-people-vs-ai-overlords/

We Tracked a Shipment of Rare Books. It Ended at an Amazon AI Training Facility

Tags: tech, ai, machine-learning, gpt, ethics, book, knowledge

This truly makes me sad… The level of cynicism required to destroy rare books is just beyond me. All this to squeeze the last human made tokens available with no real gain in sight.

https://www.404media.co/we-tracked-a-shipment-of-rare-books-it-ended-at-an-amazon-ai-training-facility/

AI Software Development - What Does The Data Say?

Tags: tech, ai, machine-learning, copilot, engineering

The executive summary is good. This is also a nice source of reference papers and studies on the topic. It shows quite well why the work is moving to the harnesses rather than the models. Indeed models probably won't improve much in terms of reliability. It all points once again towards a needed shift of people attention from the shiny toys and towards team practice instead.

https://codemanship.wordpress.com/2026/08/12/ai-software-development-what-does-the-data-say/

There Is Still No Silver Bullet

Tags: tech, ai, machine-learning, copilot, productivity, engineering, craftsmanship

Very good opinion piece going back to Naur's and Brook's important papers about software production. It's a sobering take on how LLM can't bring the promised productivity gains. This is not saying it can't bring productivity gains of course but it'll never be as dramatic as what the current hype cycle pushes people to believe.

https://cekrem.github.io/posts/there-is-still-no-silver-bullet/

Copyrightability of LLM-generated code: Can we license "vibe code" into Free Software?

Tags: tech, ai, machine-learning, copilot, copyright, law, foss

Clearly the situation of copyright around LLM uses is complex. It's easy to fall into code which can't be copyrighted if there's not enough human input to produce the work (and keep in mind that "prompting" is likely not enough input). This also raises questions about potential copyright violations. Looks like following the guidelines of the SFC for contributing to Free Software projects is getting especially important.

https://fsfe.org/news/2026/news-20260825-01.html

And then the men with guns tell you to do it anyway

Tags: tech, security, privacy, politics

Or a reminder that no system can be made to be completely safe and secure. When the political pressure or violence gets in the equation it's hard to not simply falter and satisfy the demands.

https://shkspr.mobi/blog/2026/08/and-then-the-men-with-guns-tell-you-to-do-it-anyway/

hk - Git Hook Manager

Tags: tech, git, tools, linting

Might turn into a nice way to manage your git hooks.

https://hk.jdx.dev/

Easy Sandboxing on Linux with Bubblewrap

Tags: tech, linux containers, flatpak, security, sandbox

A nice and simple approach to sandbox a command. Of course with the system integration it's a bit porous bit it might be a good base for quite a few uses.

https://bxt.rs/blog/easy-sandboxing-on-linux-with-bubblewrap/

Hister: Your Own Search Engine

Tags: tech, search, self-hosting

Looks like an interesting personal indexing system for your own files and slice of the web.

https://hister.org/

Monitoring SystemD services with Healthchecks.io

Tags: tech, systemd, monitoring

Neat trick to monitor systemd services.

https://passbe.com/2022/healthchecks-io-systemd-checks/

Python sets and dictionaries can have quadratic-time performance

Tags: tech, python, performance, algorithm, cpu, memory, complexity

Too often people mistake the algorithmic complexity theory for the real performances you would get. This can't be further from the truth. The memory layout trumps all. As usual you need to measure.

https://lemire.me/blog/2026/09/03/python-sets-and-dictionaries-can-have-quadratic-time-performance/

Rewriting in Rust: Performance, Failures, 2026 Reality Check

Tags: tech, rust, porting, rewrite, safety

Unsurprisingly it's not all unicorns and rainbows. This piece tries to highlight the right questions to ask yourself before aiming for a rewrite.

https://blog.jetbrains.com/rust/2026/08/10/rewriting-in-rust/

Rust concurrency vs Go concurrency: stackless vs stackfull coroutines

Tags: tech, go, rust, asynchronous, coroutine

Comparison of two concurrency models. This is a light read which shows quite well the differences.

https://kerkour.com/rust-vs-go-concurrency

Concurrency vs. Throughput: why more parallelism can make databases slower

Tags: tech, multithreading, databases, performance

When more concurrency might not help. Illustration with the case of database queries.

https://planetscale.com/blog/concurrency-vs-throughput-vitess-mysql

SQLite for Everything

Tags: tech, databases, sqlite, architecture, funny

Another love letter to SQLite. It's meant to be funny but comes with plenty of good arguments and ideas as well.

https://joecode.com/2026-08-19-sqlite3/

The Browser's Main Thread Is Expensive

Tags: tech, web, frontend, browser, performance

A reminder that web frontend work isn't as easy as it sounds. It brings quite some caveats and his difficult to do well. Otherwise you wonder why things stutter or render badly.

https://kciter.so/posts/the-expensive-main-thread/en/

Ambient CSS - a physics-based lighting system for CSS

Tags: tech, css, graphics, physics

Really nice tricks you can pull with CSS nowadays. The result is fairly nice visually.

https://ambientcss.vercel.app/

HTML Can Do That

Tags: tech, html, javascript

More proofs that HTML is more and more capable by itself.

https://chrisburnell.com/html-can-do-that/#example-until-found

Solving copyright & licensing information in client-side JavaScript, CSS and similar

Tags: tech, web, frontend, javascript, licensing, foss, law

Finally a sensible approach to communicate license compliance for client side content delivered via a browser. It's not too much of a bother so let's hope it gets picked up.

https://matija.suklje.name/solving-copyright-licensing-information-in-client-side-javascript-css-and-similar-agreeing-on-a-useful-solution

Software That Must Not Be Wrong: Property Tests for a Pediatric Dosing Calculator

Tags: tech, property-based-testing, tests, rust, type-systems

Interesting case where you want to property test but without a specific property base test tool. Indeed, if you need to be exhaustive and the input space is small enough this is the better decision. This article also comes with interesting point on Rust type system but that's less central to the main point.

https://rust-blog.github.io/post/favi-child-property-tests/

Let's not call it "tech debt," it's just "mess"

Tags: tech, technical-debt, complexity, maintenance, craftsmanship

A good piece showing some of the problems with how the term technical debt is widely misused. There's a problem with the metaphor itself, you rarely have the information level needed to call it debt.

https://www.simplermachines.com/lets-not-call-it-tech-debt-its-just-mess/

Guilt-Driven Development

Tags: tech, quality, engineering, craftsmanship

I like this article somehow. Indeed I'd like to see more guilt in the people shipping bugs in production (myself included probably). Also I'm very much aligned with the proposed approach to tame issues: thinking, types, tests, and telemetry.

https://markuseliasson.se/article/guilt-driven-development

Reviewing code is a skill

Tags: tech, engineering, codereview, learning, knowledge

Excellent piece about code reviews. But it goes further than that and shows how our skills could improve. By tackling this question it does a good job showing we don't know where the ceiling is in terms of skills in our craft.

https://typesanitizer.com/blog/code-review.html

Coachability++

Tags: tech, coaching, management, mentoring

Interesting slide deck about coaching in tech circles. Clearly provides good inspiration both for coaches or if you're the one requesting to be coached.

https://cate.blog/2021/02/22/coachability/

The Expertise Trap

Tags: expertise, problem-solving, cognition, bias

This is an easy trap to fall into unfortunately. Be mindful of your own biases. They might increase as you gain more expertise in a field unfortunately.

https://www.congruentchange.com/the-expertise-trap/

Has America Crossed the Asshole Threshold?

Tags: history, politics, mathematics

Don't be fooled by the click-bait title. It's a good piece looking at history and game theory. It gives some lessons about how civilizations collapse… or not.

https://thegrimhistorian.substack.com/p/has-america-crossed-the-asshole-threshold?ref=DenseDiscovery-404

Meet the 2026 Ig Nobel Prize winners

Tags: science, funny

Another good crop of Ig Nobel this year! I'm not sure which one is my favorite.

https://arstechnica.com/science/2026/09/meet-the-2026-ig-nobel-prize-winners/

Bye for now!

04 Sep 2026 11:46am GMT

For many years now, I and others have been working on getting plasmashell's open bug reports as accurate and actionable as possible.

We've made tremendous progress, driving down the number of unconfirmed bug reports to its lowest levels in over a decade, and mostly keeping it there:

Right now we're at a point where we're down to about 160 unconfirmed reports, and we need your help to get that down as close to 0 as possible.

Why do we need your help?

Because most of the remaining unconfirmed bugs are really hard to reproduce and confirm. They can only be understood or reproduced by someone with specialized hardware, uncommon software, specialized configurations, specific VPN setups, domain-specific knowledge, and so on. Others were reported in a state where the author doesn't know how to reproduce the issue and none of us has been able to, either.

The addition of your valuable eyeballs and brains can help figure out what the heck is going on in these reports!

How to help

Go to https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&list_id=3586535&order=changeddate%20DESC%2Cdupecount%20DESC%2Cshort_desc%2Cproduct%2Clongdescs.count%20DESC%2Cbug_id%20DESC&product=plasmashell&query_format=advanced, and…

• Figure out the pattern for issues that are reported to happen "randomly" or "sometimes".
• If you have the hardware, configuration, or specialized software necessary to try to reproduce an issue described as specific to it, try.
• If you're familiar with upstream software like the Qt, PipeWire, Bluez, graphics drivers or the Linux kernel, help identify bug reports whose issue is upstream of KDE.

What it takes

1. Use the latest released version of Plasma. that's 6.7.4 as of the time of writing. A distro that uses git master versions of things is even better.
2. Use a distro that ships KDE software as "vanilla" as possible, with a minimum of distro-specific customizations. Either as your daily driver, or in a VM. Arch Linux and KDE Linux are good options here, and Fedora KDE is okay too. Highly opinionated distros can still work, but are not as ideal for bug triage.
3. Read through and understand https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.
4. Be nice. You'll be a part of KDE's public face!

And that's it! Bug triaging help is really appreciated here.

I would absolutely love it if we could get the number of UNCONFIRMED plasmashell bugs down to 0, and then keep them that way by pouncing on every single new one as it comes in.

You can help make that possible! Thanks, everyone.

04 Sep 2026 12:30am GMT

Hello everyone!

My Google Summer of Code project Font Subsetting in Poppler has technically been completed with this MR getting merged.

Poppler now supports Font Subsetting and a new release is going to be out soon. Although the work has been rigorously tested for regressions on a lot of PDF files, I am still quite nervous :D

Here's a demo video I made for font subsetting:

Experience

Overall, GSoC was a very enriching experience. I learnt many things I didn't know before such as PDF internals, some C++ and CMake features and sharpened my debugging skills using GDB.
But it was also a very tough experience, there were a lot of times when I thought I was going to fail.

I'll also be attending Akademy in Graz so I hope to meet and learn from a lot of contributors from there!

Gratitude

I am grateful to god for providing me with such an opportunity.

I would like to thank my mentor Albert Astals Cid for mentoring me throughout GSoC.
Huge thanks to the people from the Poppler community, Sune Vuorela, Lucas Baudin and everyone for helping me with my technical doubts in the Matrix IRC.
Thanks to the KDE mentorship team and the board members for managing the GSoC program!

03 Sep 2026 8:15pm GMT

This summer the SPDX Cryptography Group agreed on how to describe algorithm parameters, tightened its contribution and release processes, and opened the discussion on post-quantum cryptography. Where this report comes from This is an update of the work we do at the SPDX Cryptography Group. SPDX stands for Software Package Data Exchange. Our group is … Continue reading SPDX Cryptographic Algorithm List: summer 2026 update

03 Sep 2026 11:34am GMT

One known significant issue when going from X11 to Wayland was our KMouseTool being X11 only.

KMouseTool implements a Dwell Clicker that is an assistive technology designed for individuals who find traditional mouse clicking difficult, painful, or impossible due to conditions like paralysis, mobility issues, or repetitive strain injury (RSI). It allows users to perform left-clicks, right-clicks, double-clicks, and dragging entirely without pressing physical buttons by simply pausing the cursor on the screen for a specified duration.

In KDE Plasma 6.8 we will ship the just merged brand new Dwell Clicker implementation that works also on Wayland.

Here is how it looks in action:

Have feedback or questions? Head over to the KDE Discuss forum to share your thoughts with the team.

02 Sep 2026 3:31pm GMT