lprod KDE Blog

KDE Akademy 2026

Thu, 24 Sep 2026 20:00:00 +0000

My experiences at Akademy

It's been a hot minute since my last blog post, mostly because I was focusing on finally finishing my studies - while I'm not quite done yet (still missing one exam), I have a good reason to come out of hiding: KDE Akademy 2026 just happened and I was there!

Talks

While I was already at the Plasma Sprint in Graz last year, this is my first other KDE-related event I attended and oh boy was it ever an event. So many talks ranging from educational and thought provoking to simply silly fun and plenty of opportunities (for frequent and extended coffee breaks leading to even more education, thought provoking and simply silly fun conversations!

BoFs

If it was just that I would have already called this amazing, but the "talks" part of Akademy was just the first two days (not counting the "arrival day" + evening welcome event which I could unfortunately not attend myself), but the following days were equally amazing, if not even more so. A bunch of lively discussions in plenty of BoF rooms (and, which I have learned there, the famous hallway BoFs) around so many topics I can't even hope to mention them all here. I attended some conversations around how to better get in touch with stakeholders to reduce the general society's reliance on big tech, the technical intricacies of theming systems in general and KDE Union in particular, implementation details for the new XDG Intents, ... I could go on forever, really, but I shall restrain myself.

In short: Tons conversations and planning that works best in-person was done as well as a lot of networking and putting-faces-to-names.

The C word

Now unfortunately not everything was sunshine and roses - Wednesday was a day of unspeakable, chocolate-based torture for all of us. We toured the Zotter factory near Graz which included the ability to taste-test their chocolates at various steps during production process (yes, this includes up to as early as whole dried cocoa beans!) as well as a wide selection of their final products. It was much more interesting than I thought it would be and such a great experience to do all this with so many kool (with a K!) people.

However... let's just say mistakes have been made and I misunderstood the Zotter employee's statement that there are "roughly 300 taste testing stations" as a promise and not a threat. I definitely purchased a number of chocolate bars in their shop at the end but I don't think I'll be eating any of them any time soon after my complete lack of self control during the tour and the ensuing (and entirely predictable!) consequences.

And the worst part: After that we went to a Buschenschank for a good old "Brettljausn" (not sure how to translate, but essentially a meat and cheese buffet) where I also ate way too much since it's been way too long since my last proper Brettljausn.

And with that I think I covered everything I wanted to talk about - Thanks so much to everyone organizing and attending to make this such an unforgettable week! If you'll excuse me, I'll now fall into bed and sleep what feels like for several days straight

Revamping Plasma Mobile Navigation Gestures

Sun, 05 May 2024 00:00:00 +0000

Down the rabbit hole

A few months ago I was kind of toying with the idea to start contributing to Plasma Mobile because I was getting increasingly fed up with Android and I realized if Linux Mobile was going to be my daily driver before I need to buy a new phone I better help out.

Then, after a few trivial commits I've seen that for the Plasma 6 release the navigation gestures were (at least temporarily) turned off - and since I am a very big fan of navigation gestures ~~because they are objectively the best way to interact with a phone~~ I just couldn't have that and I went about fixing them.

A bit of context

Why did the gestures even break by the upgrade to Plasma 6? Well, in Plasma Mobile 5 the navigation gestures were implemented in quite a hacky way - an invisible panel at the bottom screen edge that captured finger touches and handled the gesture and visual effect. While this worked this required a bunch of data moving around from KWin to the shell to show the window thumbnails which is unnecessary overhead.

So for Plasma 6 Devin Lin rewrote the entire task switcher, including the navigation gestures, to be a KWin effect which should make it perform better and use more of its infrastructure to need less bespoke code.

This went mostly quite smoothly, with few hiccups along the way. Unfortunately one of those hiccups was gestures (which now moved to KWin's EffectTogglableTouchBorder interface) simply not working anymore.

Fixing gestures

The fix was surprisingly simple: In the constructor for setting up the task switcher, including all shortcuts and gestures for it, the reconfigure function was simply never called which in turn meant the KWin::EffectTogglableTouchBorder::setBorders function was never executed. As you might imagine "setting the border" is quite a crucial part of having working gestures and one function call later gestures worked again!

Or did they

Disclaimer: I'm shuffling around the timeline a bit to make this post easier to follow, this part actually didn't happen until quite late.

Turns out the gestures did work - but oddly enough only after opening the Action Drawer at least once after every screen geometry change (eg: screen rotation). But the Action Drawer doesn't have anything to do with the task switcher and its gestures, how did it have an effect on them?

Well the reason is-... Honestly, I have no freaking clue. It makes no sense, but I also didn't really investigate it all that much, because I stumbled on the cause by accident quite quickly.

It turns out that the KWin people have done a good job at making the setBorders function quite safe to use and before reserving a touch border for an effect they first un-reserve anything that used to be on that border beforehand so two effects don't have to argue about who is allowed to react to the gesture. The problem is that for some reason in the reconfigure function in the task switcher effect logic also unreserved and reserved the borders, kind of doing setBorders job already before calling it.

Now why exactly that interfered with reserving the border I don't know, in theory setBorders should unreserve our previous stupidity and set us up properly - but evidently it didn't and when I removed our unnecessary border shenanigans in reconfigure suddenly gestures magically started working again. Either way, it's fixed now.

But define "working"

Well, it turns out that while KWin's border gesture infrastructure is quite nice, it also... doesn't allow customizing the distance a user needs to move their finger for a gesture to be "completed". It also turns out that on the PinePhone (and probably quite a few other phones) this lead to the gesture being... pretty much impossible to use. You just had to move your finger waaaaaayyyy too far (on the PinePhone about 3/4 of the screen height, see MR linked in next paragraph for video examples) to invoke the gesture. That's just unacceptable!

Luckily the fix is quite easy and a quick MR to KWin allowed us to set custom gesture distances-... or so I thought.

I mean, it did allow us to set the gesture distance, but that didn't mean the gestures were much better, so I went for another approach.

The rabbit hole.

(I'm talking about this monster of an MR from here on out, it also contains a video example of the almost-final product)

Ooooooh boy.

I'll have you know that I have quite strong feelings towards what navigation gestures need to be able to do to be a nice user experience.

One very crucial part of this for me is being able to "flick away" an app and go to the homescreen. The old navigation gestures didn't support that - to go to the homescreen you needed to open the switcher, then tap on the side to close it. That's TWO WHOLE FINGER TAPS - UNACCEPTABLE (Well, one drag and one tap, but let's not be pedantic).

And while we're at it, having "quick task switch" gestures would also be really nice - but I'll keep those for followup MRs, first I need to just revamp the task switcher backend to support tracking gesture velocity to discern between a drag with a pause at the end or a quick flick.

Velocity Tracking

I'm gonna gloss over a lot of the details, but for a quick too-long-didn't-care-enough-to-write-it-all-down: KWin's gesture system doesn't expose gesture positions, just percentage based activation factors so I had to do some work to massage that into giving me the right data.

After said massaging we now magically get the "primary" and "orthogonal" gesture position from KWin we can sit down to create velocity tracking

Moving average

My first gut reaction was to implement a normal moving average calculation and after chatting a bit with Devin it seems other projects went for a similar approach. But then I looked at the moving average calculation in other places and... it looked so complicated and bloated and over the top to store all the past values and iterate through the entire list of them to average them out and doing all that every frame and ...

As someone who initially learned programming by working with microcontrollers this was unacceptable (I see, this word is becoming a recurring theme). Now let's step back a bit and figure out what we actually need. The moving average is just there to filter out spikes in movement speed, be it due to inaccurate sensor touch screen readings, frametime spikes or accidentally slipping with the finger. We only want to filter, we do not actually care about receiving a mathematically accurate moving average. In fact we couldn't care less about getting a mathematically accurate moving average for our velocity.

We only want to filter

Damn. Now if only someone knew how to choose and design filters.

Looks at Uni curriculum

Oh would you look at that! Signal theory, control technology and filter design this semester. I can finally procrastinate AND study for a course at the same time!

Exponentially Weighted Moving Average

Even though I have a course on filter design at Uni, I never said I was any good at it. I mean, I'm okay enough, but not good enough to explain this filter better than Wikipedia does. The upshot of it is: It is a filter that does not need to store the entire history it tries to filter (no ugly array of values to iterate through: check), it is essentially a low pass filter (filters out transient spikes in movement speed: check) and it can be implemented in essentially 30 lines of code in a single function without any loops (not overcomplicated and bloated: check).

In fact, the EWMA filter is just a single formula that takes the previous filtered velocity, the current speed in the last time step (~frame) and a magic smoothing factor and spits out the filtered velocity updated with the newest sensor values. So that's just two lines for the actual filter (1 per axis) and some boilerplate. Neat!

Magic smoothing factor

Usually you'd pick a smoothing factor based on the sampling rate of your system and your desired time constant. To emulate the behavior of moving averages I found elsewhere I picked a time constant of 30ms. This (very roughly) means, when starting from 0, a sudden input value is applied to the filter, it will reach ~63% of the input after 30ms - and after another 30ms it will have reached ~90%. This is roughly in line with an "proper" moving average with a window of 60-70ms.

The problem we now have is that we don't have a fixed sampling interval - we get new gesture positions whenever KWin deems fit to give us some (which might be seconds apart if the user doesn't move the finger for a while). Sooooo what now? If we get a very long timescale our "roughly equivalent to a 60ms moving average" goes right out of the window.

Well, luckily with one simple formula we can calculate our smoothing factor based on a desired time constant and a certain sampling interval which we can call every time we get a new value:

smoothing_factor = 1 - exp(-delta_time/desired_time_constant)

(Maybe someday I'll add a LaTeX parser to the blog. Or I just copy in a screenshot. We'll see)

Now there is one remaining problem: As a self-respecting microcontroller dev who absolutely knows he is not restricted by a 16MHz CPU without a floating point arithmetic unit, but still cannot shake old habits that having e to the power of a floating point number in that formula hurts.

Luckily there is an approximation formula that is a bit cheaper

smoothing_factor = delta_time/desired_time_constant

That approximation formula should only be used when the delta time is a lot smaller than the desired time constant, which we

checks notes

Oh. We don't really satisfy that condition. Eh. Whatever. We only need it to filter out super high weird spikes and be roughly in the right ballpark, we don't need to propulsively land a rocket.

Some manual checks later show we'll not be all that far off the "correct" formula and we need to put a clamp on it anyways to always do a bit of smoothing so we'd deviate from the right formula anyways.

Do our "recalculate smoothing factor on every new value" shenanigans interfere with the stability or correctness of our filter? Probably, I dunno. But it's probably fine and throughout all of my testing, both throwing in arbitrary test values and empirical testing while using the gestures it all felt nice, so I give it my seal of approval!

Now... where were we? Right!

Flick!

And now with a simple check on if speed > threshold we can detect flicks! And voila - an upwards flick goes to homescreen!

2D gestures

Well, I know I said I'll replicate the old gesture behavior without touching any functionality and keep any extra features for followup MRs, but the gesture feels kinda bad when it only goes up and down and doesn't follow the finger left and right as well - and thanks to our previous excursion into KWin it also magically exposes the orthogonal gesture position, so we can just really quickly hook that up and have X and Y tracking.

States?!?!?!

As a remnant from Devin's move to a KWin effect there was a bit of a mess of what keeps state where - he simply didn't have enough time to refactor the entire thing while also updating the rest of the shell to KF6 and all the fun API breakages and so there were several places that kept track of the same-ish state that made things confusing and hard to work with.

No problem, I can refactor that and take some work off of Devin.

Quick task switch gesture

But you know what, now the task switcher code feels really clean and nice and it would be so easy to just add a few lines of logic to discern between an upwards flick and a diagonal flick to switch to neighboring tasks.

Ah to hell with it, let's add that as well!

Task Scrub

Remember how I said I have opinions on what good gestures are?

Well, I really really really dislike what Android does with their task switcher where it uses some heuristic to only reorder the tasks based on recency after you have been in a task for a while. This allows you to use the quick task switch gesture several times in a row to go "further back" in the task history.

But it's also kind of a black box as to when that happens and it really annoys me a lot - besides, the quick task switch gesture is neat for one switch, but gets very tiring to use when you have to use it several times in a row.

So how about a bespoke "task scrub" gesture that activates on a mostly-horizontal gesture invocation and allows to scrub through a large number of recent tasks.

Right.

I've skipped over a lot of detail and some entire sidequests in this story (with a lot of potential for more jokes) for the sake of brevi-WOW HOW IS IT OVER 2000 WORDS ALREADY?!

Uhm.

Wrapping Up

There's still some bugs to fix, some tasks for later MRs (though much fewer than I thought there would be) and some decisions to make, but for now this has been my small odyssey about first fixing then slightly extending then completely rewriting the task switcher and navigation gestures for Plasma Mobil

Plasma Sprint and more

Wed, 30 Apr 2025 16:00:00 +0000

So many phones!

What happens when you put three mobile OS devs into one room for more than a few minutes?

Fun times, that's what!

A few days ago I returned back home from Graz after attending my very first Plasma Sprint and it's been an incredible experience throughout. Everyone there was incredibly welcoming and we managed to not only have a great time, but also got a lot done.

As you might expect, my focus was mostly on Plasma Mobile, which was helped by Devin and Bhushan also attending in person. We chatted about technical challenges around power management, display notches, haptic feedback and so so much more - but maybe even more exciting in the short term, we managed to reproduce and fix a number of very annoying bugs that stopped me (and probably some others) from daily driving Plasma Mobile with my main SIM.

Double Call Bug

While calling on my OnePlus 6T worked really well for a while already there was a... quite annoying issue when receiving calls while the phone was locked: Plasma Dialer would receive two call notifications which in turns lead to the ring tone being doubled. So far so bad. The worse part was when accepting said call one of the two ring tones would continue. Now, the call itself worked fine, microphone, speakers, all good - you just had the ringing in your ears the entire time and had to reboot to get rid of it. Not great!

This was ultimately an issue with events being connected too often in certain cases like when a SIM card has a pin lock or the phone has (working) dual SIM. This is now fixed from Plasma 6.3.5 onwards. Yes, I kept the dev build on my phone until then ;)

Dialer freezing on lockscreen

The second big issue was that any time Dialer opened on top of the lock screen it would get stuck there after closing. The last frame rendered by the app would remain frozen on the lockscreen until it was rebooted or unlocked. The same bug could lead to essentially softlocking the phone on boot if session restore was enabled and the phone app was open, as it would initialize on top of the first-boot lockscreen and then stay frozen there (Which is why I disabled session restore for mobile before already).

This was ultimately an issue in KWin and how it handles certain effect types on the lockscreen and has also been fixed for 6.3.5. Until then as a workaround it's possible to disable KWin's Scale effect (which animates opening and closing windows) as that is what "got stuck" on the lockscreen.

To debug and fix both of these we made about 100 calls to and from various Plasma Mobile devices throughout the Sprint - Sorry to all the people who had to hear constant ringing, we really tried having it as quiet as possible!

Merged Changes

As far as merged changes go, it's... short this time around since free time wasn't kind to me these last few months, so most of what I did, I did on the sprint with others and the blog-worthy parts of that are covered above, but there's a bit:

Made some interactions with the modem asynchronous to improve UI performance (these could potentially freeze the UI for a short time).

Feels a bit weird to have a list for one item, so let's make it two:

This wasn't me, but Devin fixed the navigation gestures being enabled when the navbar was active which was terrible user experience and I'm so grateful for this finally being fixed because this bug absolutely broke me. Thanks Devin for saving my sanity!

Unfinished

I did make some progress on other tasks though, even if they (still) aren't done yet:

On the sprint I had a good long chat with Xaver about my corner touch gesture MR for KWin in preparation for feature parity between navbar and gesture navigation. He has been working on a refactor of the gesture code in KWin which decouples touch and mouse gestures from each other and we came to the conclusion that it's more sensible to base my work on his refactor as it then has to touch a lot less code and stops sharing code paths with other mostly unrelated features.

As part of that conversation we also touched on incorporating some of the custom gesture logic I created for the task switcher gesture into KWin directly, as that currently still lives in the Plasma Mobile repo.

I've restarted work on my "refactor" of the mobile task switcher again to make it more maintainable and performant by annotating types and following some rules to allow Qt to create a precompiled binary of the QML files using qmlcachegen.

Closing Remarks

I want to circle back to the Sprint and emphasize again how amazing it was - and not only that, since then I've kept my SIM card in my postmarketOS Plasma Mobile phone because the two dealbreaker bugs for me are now fixed. My Android will unfortunately stay with me for the foreseeable future mostly due to banking/payment apps, but it's a step in the right direction.

As an extra goodie for the end, I want to show off Balatro running natively on Plasma Mobile: https://mastodon.gamedev.place/@l_prod/114401321865300843 (Tech can be so cool

What I did in KDE/Plasma Mobile land in July-ish

Sun, 28 Jul 2024 00:00:00 +0000

Miscellaneous improvements

After my gargantuan post around the overhauled navigation gestures (and a still-in-progress one about KWin corner touch gesture support I'll hopefully have ready soon:tm:) let's tackle a few more smaller things. I'll try to make these somewhat regular (dare I say maybe even monthly?), but let's see how that shakes out, probably more like every 2-3 months if at all.

As an exciting update, near the end of June (the 25th to be exact) I got accepted to the KDE dev team. This means I now have the ability to properly manage submitted issues on GitLab and, only slightly terrifyingly, I'm now allowed to push code changes to the main repositories and review MRs. Let's see when, if ever, this feeling of trepidation over having to make quadruple sure I don't accidentally do stupid stuff subsides. Should it even subside or is being very extra super duper careful a good thing. I'll keep you posted whenever I find an answer to that :D

Anyways, let's get to code changes:

Merged Changes

Task Switcher/Gesture Navigation

I sat down and overhauled some of the animations around the navigation gestures of the mobile task switcher: The diagonal quick switch should now look smoother and not be nearly-instantaneous and the flick to homescreen is now a tad smoother and actually makes the task preview smaller while animating instead of looking like it's opening the selected task before suddenly vanishing.
Fixed minor logic bug around task switcher quick switch gesture. It should now correctly open the task switcher when you're trying to quick switch towards the end of a list - if there's nothing to quick switch to, it's better to open the full task switcher instead of just returning to the app you were in before.
I added a task icon list to the task scrub gesture in the switcher to make it visually more distinct to the "normal" task switcher and provide more useful info about the open apps you can switch to. In case you didn't know: In gesture-only mode w (I'll admit this one is a bit older, but this is the first installment of this kind of post so I'm not tooooo strict on the "in July" part): I'm still tracking an issue with this where when the task list becomes too long it's not properly centered anymore, but that should be a fairly simple fix once I get to it.
The main task switcher opening gesture now stops tracking the finger 1:1 in the vertical direction once it's moved a bit past its "fully activated" point. This is a bit awkward to explain, but basically it makes it "more reluctant" to follow the finger infinitely far up. If that still doesn't make sense, here's a video: Video tag unsupported!
The task switcher gestures now have a haptic feedback in some places: When the conditions are met for the task switcher to open (eg: gesture progress is far enough and finger movement speed is slow enough) and when the task scrub mode starts there'll now be a bit of haptic feedback.

Misc

I've done some bug triaging and reproduction here and there, as well as tried to keep up to date on merge requests in the Plasma Mobile world. I still haven't really done a proper review and merge, but I'm trying to look through all of the other ones to hopefully learn how good reviews look like so at some point I'll be able to do them.

Unfinished

I tried my hand at fixing the task switcher navigation gestures being always active instead of just when the gesture navigation mode is actually turned on. To do this properly we probably need to refactor the mobileshellsettings plugin to be accessible via C++ (it's just a QML plugin currently), so let's see how that goes.
I started work on more mobile friendly notification popups. The new design uses a swipe-to-dismiss interaction instead of having a close button. While technically "working" from a functionality perspective, the visuals are kind of broken still. I hope to have this complete by 6.2, but there's still some open questions. I'll probably have to get in touch with more experienced Plasma devs to brainstorm why this is going wrong so badly, but I've not quite given up at bashing my head against this myself. Oh and before I forget: this also affects Plasma Desktop when in Touch/Tablet Mode. Video tag unsupported!This was my first try, which was smooth but left behind the window shadow Video tag unsupported!And this my second try which is more technically correct and properly moves the window, but... I mean, you can see it yourself

Upcoming

For the next month I wanna try and finish up my work on KWin touch corner gestures (and get another oversized blog post out about those) and then implement them into Plasma Mobile. Once that is done I want to do more bug fixing, triaging and looking at knocking out some tickets for planned bigger picture improvements for 6.2. Let's see next month if a) I get any of this done or b) I even manage to make a blog post since I'll not be home for a while

My last 6 months in KDE/Plasma Mobile

Sat, 04 Jan 2025 21:00:00 +0000

Learning experiences all around

Uh. Has it really been almost half a year already? Whoops.

Unfortunately even with this many months I didn't get quite as much done in KDE-land as I hoped, for two main reasons:

I've been bouncing back and forth between quite big tasks (for my current level of experience in the KDE stack), leading to a lot of time spent with few results. I've learned a lot, but there's not much to show for it yet.
A good amount of time was taken by preparations for the 2024 European Rocketry Challenge (EuRoC) in Portugal - this was my second time there with the TU Wien Space Team and while it was an absolute blast, prepping a student-build bi-liquid propelled rocket for launch is on the more time consuming side of things. Who'd have thought! Maybe I'll write a dedicated post for this some time in the future, we'll see.

Back to KDE though: It wasn't all just learning - my phone also broke! Well. Kind of. Probably a loose contact in the SIM reader leading to it dropping connection to my SIM card a bit more often than I'd like. However this did push me to put said SIM into my old OnePlus 6T which just so happened to be running postmarketOS edge making me an official Linux Mobile daily-driver.

And I'm happy to report it mostly just worked. Sure, there's a few apps I'd like to have that aren't available on Linux Mobile (yet?), but what's there works and it's enough for me to use it.

Though there are certainly a number of more-than-a-bit-annoying bugs to be ironed out - so iron them out I will. For now my SIM card is back in my spotty Android phone until I fix a bug which sometimes duplicates incoming calls making them continue ringing while you've already picked up (less than ideal), but after that I think I'll stay on my 6T with Plasma Mobile for a longer while.

Now before I write another novel, let's get to the stuff I did actually finish in the last few months.

Merged Changes

Mobile Taskswitcher

Fixed an issue with the animation opening the taskswitcher from homescreen
Fixed the icon list during task scrub mode sometimes being off center
Reintroduced maximizing the selected window when not in docked mode. Technically it shouldn't be necessary since our KWin configuration should force windows to be fullscreen already, but some apps managed to break out of that (mostly GTK based apps), so back in it goes.
Disable blue border on touch gestures in mobile environment - it's nice as an indicator for mouse based gestures, but unnecessary here.
Add double tap on navbar task switcher button to switch between the 2 most recent apps.

Misc

Disabled session restore on mobile (at least until a bug with dialer launching ontop of login screen soft-locking the phone is fixed)
This is not a change by me, but I wanted to mention it because it's great and I mentioned in my last post that I tried (and failed) working on that before: Micah Stanley did a marvelous job at new mobile friendly notifications!
I've also done my first MR reviews which was exciting and a lot more work than I anticipated. At this point I want to thank all the people who have spent time on my MRs already!

Unfinished

I still haven't managed to get back to my touch corner gesture MR for KWin due to all the stuff that came in between like:

Fixing that the navigation gestures are still active while the navbar is enabled. Unfortunately this requires a change in how our setting system works and... CMake broke me here. I got pretty close to fixing this but had to leave it be for now for my own sanity's sake. I hope to get back to this soon since this is quite annoying.
Improving plasma-dialer's lockscreen behavior. Right now with session restore it restores above the initial login screen on mobile essentially soft-locking the phone if it happened to be running when the phone was shut down. A similar thing happens when a call is received during the lockscreen - I'm currently figuring out how to best fix that.

Well, that's all from me now. Hopefully I manage to do the next post in a more timely manner, but we'll see for how long my current bigger ticket items will keep me occupied for