Introduction

Another year, another successful Season Of KDE for 10 contributors!

This article has been co-written with the input from all contributors.

Kdenlive

Kdenlive brings you all you need to edit and put together your own movies. We had 1 project for KDE's full-featured video editor:

• Swastik Patel animated transition previews in Kdenlive by extending the TransitionListWidget with a dual-view system (tree/icon) and creating a custom TransitionIconDelegate for rendering GIF previews. The core functionality is powered by a Python script that leverages MLT to generate standardized preview GIFs by applying transitions between colored clips or custom images. The implementation integrates with Kdenlive's existing asset management system, utilizing QStandardPaths for preview storage and QMovie for GIF playback. The UI updates are triggered through signal connections when frames change, providing real-time preview updates in the transitions panel. This enhancement allows users to visually evaluate transitions before applying them to their projects. All the code changes are in this merge request.

  

KDE Eco

There are 4 new projects related to the KDE Eco project. This helps make KDE software more efficient and environmentally friendly, as well as more accessible at the same time:

• Anish Tak worked on a new tool, Win2KDE-Chooser project to help users migrate from Windows to Linux by recommending KDE-based distributions. A questionnaire was designed to understand the user's needs, mapping their responses to distribution parameters like ease of installation, hardware support, and community backing. Further, a recommendation engine was implemented in the backend to rank distributions according to user preferences and hardware specifications. Overall, a functional MVP was created that suggests suitable KDE-based Linux distributions based on users' needs and hardware capabilities.

  

• Oreoluwa Oluwasina built a new GUI for the emulation tool KdeGuiTest formerly known as KdeEcoTest with features that allows users to easily create and run a standard usage scenario script. Button commands that records the actions made by a user have been implemented and they display real time in the action buffer widget. The scripts can be modified in the final script widget to finalise each script before saving it in a text file. A combo box has been implemented to toggle to the run script interface where users can select and run final scripts. Additionally, a "Platform supported" error was encountered and fixed by installing a custom pynput package and other packages like Rust.

  

• Roopa Dharshini worked on writing technical documentation for the KEcoLab project. After a detailed exploration on the KEcoLab project, an outline was crafted. This mentorship program taught valuable practical experience in team collaboration and in thinking of approaching various possible solutions to a problem.

  

• Shubhanshu Gupta worked on rewriting and restructuring the documentation for KEcoLab to make the project more accessible to newcomers. This includes explaining usage scenario scripts—core to KEcoLab’s process—and how they simulate real-world software usage to measure energy consumption. The structure of its repository was mapped out, for a clearer understanding of the project. The experience deepened Shubhanshu appreciation for technical documentation and collaborative development of FOSS communities.

  

Mankala Engine

The Mankala Engine is one project started during last year Google Summer of Code to introduce a new game to KDE. During this year SoK, we had a lot of projects to improve this game.

Two new variants were added:

• Rishav Ray Chaudhury implemented the Kalah game for the Mankala Engine. A greedy move selection algorithm was also added and a script for generating a benchmark report for the available games and algorithms.

  

• Srisharan V S integrated the traditional game Pallanguli into the Mankala Engine. After researching regional rule variations and the core game logic was implemented in C++. A package of the engine for Fedora has been created, fixing the reported bugs and ensuring everything worked smoothly. Later, I organized a FOSS meetup at my college to showcase KDE apps and help students try out Linux. Finally, I completed the documentation and polished the codebase for future contributions.

  

• Shubham Shinde worked on enhancing the Mankala Engine by exploring and implementing new gameplay algorithms like MCTS and Q-learning, comparing them with existing ones like Minimax and MTDF. While MCTS didn’t perform well, Q-learning showed better results after optimization. Review and improvement suggestions were also provided on the Pallanguli variant implementation.

  

• Ashutosh Singh worked on creating a GUI for mankala Game. This development was done using Kirigami and qml for creating and designing the GUI. The GUI is functional but it is still a work in progress with several bugs and missing elements which need to be implemented. The current state of the game can be see below.

  

• Nidhish Chauhan have implemented a feature in the engine supporting Player versus Player (PvP) mode, with real-time XMPP-based communication for PvP. The project includes a terminal-based user interface, move tracking, and game state management, along with a man page for documentation.

  

One of the next steps for the game is to follow the KDE review process and becomes an official KDE application!

New Mentors

The projects were guided by several people new to welcoming contributors to KDE through SoK. Thanks go to Kieryn Darkwater, João Gouveia, Aakarsh MJ, Pradyot Ranjan and Snehit Sah for giving new contributors an introduction to free and open source software.

Closing

We would like to congratulate all participants and look forward to their future journey with KDE!

This month has been amongst the most intense of my FOSS journey I’d had in a while. We had both the Plasma sprint and the LinuxAppSummit (LAS).

You can follow what was done in the sprint at the many blog posts by our teammates. Thank you all!

When it comes to LAS, you can look at most videos here. However, you’ll be missing out on the experience of joining it. Consider joining next year!

All in all, it gave me a nice feeling of realisation that we are on the right track at large. Plasma is getting lots of love by our devs, ensuring a continued stream of improvements to our UX. From a Plasma standpoint, we are slowly exploring the possibility of having add-ons with Flatpak. I find this an exciting development that can bring Plasma extensions to a next level, that wouldn’t be feasible without the work from many of the folks at LAS.

And all that to say that we are all fine, and healthy. Either Plasma or LAS, both are nice communities full of nice people pushing our ecosystem together towards new horizons that I’m sure we’ll all be happy to explore.

Happy hacking!

I attended the Plasma sprint this year in Graz, Austria!

It has been a couple of years since I have last met KDE contributors in-person (Akademy 2022), so I really looked forward to finally being able to meet again. This sprint was the first time I met Bhushan, who is a long time contributor to Plasma Mobile, and was the one that initially guided me through contributions! He recently got funding to overhaul and improve the power management stack we have in Plasma Mobile, which you can read about here. I also met Luis for the first time, who has been contributing to the project for quite a while, notably having contributed the system navigation gestures we have now!

I brought my brother along as well, who is starting to also make contributions to KDE. After the sprint, we travelled around a bit (I will eventually have another post about it, link coming when that happens). This post will focus on just the sprint itself.

Be sure to also check out blog posts about the sprint by other Plasma developers over at planet.kde.org.

Photo by Kevin Krammer

Lockscreen overlays and more 🔗

A few years ago, Aleix implemented the ability to allow windows to be overlaid on top of the lockscreen. We utilize this for the Phone dialer application in order to have the call screen show up over the lockscreen. In the past, I had made some attempts to also have the power menu, status bar, and quick settings panel also shown over the lockscreen, but was unsuccessful. At the sprint, we were able to make it happen!

For the power menu, Bhushan first investigated why the holding the power button on the lockscreen did not get passed to the shell. After a rabbit chase through many different places, he was able to create a fix. With Luis and the KWin developers, he also figured out why lockscreen overlays would get stuck visually after they are closed (fix).

After those fixes were done, Bhushan and I spent some time figuring out why my old merge requests did not work. We were eventually able to fix it up and get it working (video in this merge request)! We also investigated overlaying the status bar and quick settings panel from the shell to improve the lockscreen load time. While I was not able to finish the implementation at the sprint, we got the fundamental parts working too!

• https://invent.kde.org/plasma/kwin/-/merge_requests/6752 (Restore lockscreen overlay test)
• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/270 (Status bar and quick settings overlay on lockscreen)
• https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2406 (Power screen overlay on lockscreen)

I also did some more investigation into the performance of the lockscreen. We currently load a new status bar and quick settings panel when the device is locked (as part of the lockscreen theme), which have some components that load quite slowly.

Merge requests related to this investigation:

• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/714 (Plasma-nm singleton)
• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/713 (Load speed test)
• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/715 (caffeine quicksetting: Port away from DataSource)
• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/718 (record quicksetting: load less things initially)
• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/710 (Lockscreen keypad sync load)

Kirigami 🔗

Marco was at the sprint, and so I had the opportunity to discuss some mobile related issues with him.

Marco made the following fixes:

• https://invent.kde.org/frameworks/kirigami/-/merge_requests/1784 (Fix vertical/horizontal touch drag detection on PageRow, so that the direction of movement is correct)
• https://invent.kde.org/frameworks/kirigami/-/merge_requests/1785 (Fix back button visibility behavior with certain page row setups)

Broader Discussions 🔗

We were able to discuss some topics together at the sprint with other Plasma developers!

Photo by Kevin Krammer

Haptics stack 🔗

We discussed the stack that we use for vibrations and LEDs (issue). We currently use hfd-service (from Ubuntu Touch) as a backend to interact with the hardware, and QtFeedback on top for the system and applications to interact with them. However, QtFeedback is no longer developed by Qt (though we have forked it within KDE to port it to Qt 6), and gives a very simplistic API for vibrations (on and off with set durations). We also have had the issue that vibrations are not customized per-device, and so events that work fine on one device might feel too heavy on others, or not resonate at all.

We ended up deciding on giving feedbackd (used in Phosh) a try, using it directly in the shell and implementing a feedbackd backend in our fork of QtFeedback (KTactileFeedback) for backward compatibility. This allows us to potentially adopt the event system that feedbackd provides, so that they can be adapted to devices based on how they feel. While feedbackd does has an DBus API for applications, we will eventually want to look at having a generic portal API for applications on having haptics.

I created the following merge requests:

• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/719 (Adopt it in the shell)
• https://invent.kde.org/jbbgameich/ktactilefeedback/-/merge_requests/2 (Add a feedbackd backend to QtFeedback/KTactileFeedback)

Notch Support 🔗

Plasma Mobile does not currently have any support for notches or rounded corners. Phosh developers have already proposed a new Wayland specification that will allow the shell and applications alike to receive information about screen cutouts. We discussed it with the KWin developers to get it on their radar, and decided upon pursuing an experimental implementation of it in KWin, and using it in the shell to make any UI adjustments necessary. Qt 6.9 also recently introduced a screen edge “safe areas” API (for Android and iOS), and so we can eventually also implement a backend there to support it on Linux.

Envmanager 🔗

Plasma Mobile has a service called envmanager that manages configurations that are used by both Desktop and Mobile, and swaps configuration as necessary between the sessions. There are many drawbacks to this approach because it affects the user’s Plasma configurations directly, and needs to run before session startup (and so bad stuff can happen if it is uninstalled before logging into the desktop session). We discussed having a more robust approach, and one of the ideas floated was to add a path to XDG_CONFIG_DIRS in the Plasma Mobile startup script, where we can have a “Plasma Mobile” folder that only the shell controls to provide our intended configuration. Our configuration framework (KConfig) supports overlaying config options from various locations, and so we can have the user’s config be overlaid on top of our “Plasma Mobile” config. envmanager can then directly write to this folder without having to affect the user’s configuration, and without affecting the Desktop session.

I created a merge request to implement this:

• https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/723

Power management 🔗

Bhushan has been doing a lot of work in this area recently, and did some work on this at the sprint (hopefully his blog post will come soon!). Jakob, who has done a lot of work on overhauling the power management stack in the past year, was also at the sprint. Together, we had a conversation about the future of the power management KCM. Currently, there are separate desktop and mobile KCMs for power, mainly because the desktop one contains far too many options that are not relevant on mobile. The mobile KCM has suffered from some bitrot in the past, and so I had moved the code to be located in the same repository as the desktop one in order to share code. We discussed potentially merging the two KCMs, but decided on continuing with the status quo for now because of the complexity involved in both having good UX, and in how to streamline the desktop settings to have some features apply more directly to mobile. It is a much larger topic that could perhaps be suited for a future GSoC project.

I created a merge request to share more code with the desktop KCM for the time being:

• https://invent.kde.org/plasma/powerdevil/-/merge_requests/543 (KCM KConfig XT port)

Thank you 🔗

I am really glad to have been able to finally attend an in-person KDE event, it was really productive! Thank you for having me!

I know I have not really shared many updates about Plasma Mobile in the past few years, mainly due to being busy with school and work. Rest assured, the project is still moving along, I plan to hopefully push through a new blog post on plasma-mobile.org in the coming weeks!

As much as I love Kate editor, as I mentioned in my previous post, setting up Python language server has always been a bit fiddly if you want it to work with virtual environments.

However thanks to Kate documentation and some Big Think:tm:, I managed to figure it out, and now I wish to share it.

I could just show the code and that's it, but I wanted to write this so that someone new-ish has easier time to understanding what to do.

Language server: python-lsp-server

The language server I am talking about in this instance is the python-lsp-server. VSCode uses something called Pylance, but that's proprietary and probably can't ever be made to work with any other editors. One thing I do miss from Pylance is the easy way to make it work with virtual environments.

Also silly side tangent, I kinda find it weird people call them "LSP" and not "LS" or "language server." LSP means Language Server Protocol, which is how the language server talks to your editor.. I mean I know it doesn't matter but it's a silly pet-peeve.

Python language server plugins

I also want to utilize ruff which is a nice linter and formatter for Python. To use it with the language server, you need to use python-lsp-ruff. This makes the language server use ruff instead of it's own built-in things.

Configurations for virtual environments

Kate docs actually mention this part. Search the documentation for pylsp_in_env. It's a bash script which we will be making, but with a tiny twist.

Bash script

We need to create a bash script called pylsp_in_env (or whatever you desire) which Kate will use to figure out the virtual environment before running the language server.

It's rather simple script:

#!/usr/bin/env bash

path=$1
cd $path
if [ -d "${path}/.venv" ]; then
  source $1/.venv/bin/activate
fi

if [ -d "${path}/venv" ]; then
  source $1/venv/bin/activate
fi

exec pylsp --check-parent-process

What we do here, instead of the documented example, is to check where the activate script actually is. Some people prefer having it .venv and some venv and there's other names too I'm sure.

So we get the path from the command, then source the virtual environment in right folder, and then execute the pylsp --check-parent-process as Kate would do by default.

Save this this to your $PATH somewhere so that Kate can see it, or alternatively add the path to your Kate settings. This PATH setting is in Kate 25.04.0 at least. Don't forget to chmod +x ./pylsp_in_env so that it has the execution permissions

Kate LSP config

Finally, just add this to your Kate LSP config file:

{
    "servers": {
        "python": {
            "command": [
                "pylsp_in_env", "%{Project:NativePath}"
            ],
            "root": ".",
            "url": "https://github.com/python-lsp/python-lsp-server",
            "highlightingModeRegex": "^Python$",
            "settings": {
                "pylsp": {
                    "plugins": {
                        "ruff": {
                            "enabled": true
                        }
                    }
                }
            }
        }
    }
}

Of course, if you have more language servers in your config, make sure to add the above part next to them.

If you don't want to use ruff, you can remove the whole settings bit.

What I wanted to note here is that Kate now gives the full path to the python project using the %{Project:NativePath} argument. There's more of these %{} items in Kate, which can be found by scouring the documentation.

Done!

That's pretty much it. Now restart the language servers from Kate menus, or restart Kate, and Kate is now aware of any of the virtual environments running inside your Python project.

Do note that I have no idea how poetry etc. do this. I think they may need some kind of different script. If I ever need to figure that out, I will extend this post or make new one.

If you read the Kate docs, you may have already understood what to do and done so. I however wanted to share my solution for this, which differs very slightly from the one in the documentation.

Thanks for reading, I hope this helps!

It’s no news that cool kids don’t blog anymore. So passé! That’s why Harald and I, we have started doing some mild streams where we discuss topics around our little FOSS perspective like KDE, Plasma, KDE Linux and the likes.

We’ll be more than happy for you to join! twitch.tv/daft_code

I’ve been announcing the next episodes in my Mastodon account as well as in the involved Matrix channels. There I try to announce the next episodes and when they’ll happen. It’s generally been on Sunday evenings.

We are total noobs about using Twitch and all that, don’t hesitate to suggest us how to do better.

Looking forward to having you over!

Consider supporting us!

The past week I spent in the lovely Austrian City of Graz attending the Plasma Sprint and Grazer Linuxtage 2025.

Sprint

After no Plasma Sprint in 2024 the attendance was massive, it was the biggest sprint I attended - if not the biggest in recent KDE history, the Nuremberg ‘Mega Sprint’ in 2019 may come close but that multiple sprints in one! The result was a lot of productive discussions, hacking and fun conversation during dinner and afterwards.

A subset of all the interesting discussions and things that happened at the sprint:

• We discussed sandboxing 3rdparty plasmoids which was talked about already a bit during last years Akademy. It involves interesting technical challenges and tradeoffs but would also enable for example distributing plasmoids through flatpak in the future.
• A new applet loading mechanism was proposed by Nicolas enable us to take advantage of the modern QML infrastructure and tooling
• We decided to do one more point release for regular Plasma releases (i.e. a .6) but no more LTS releases
• Streamlining the many repositories Plasma consists of
• Switching qdoc for documentation instead of doxygen (like Frameworks will do soon)
• Vlad presented his very impressive Dynamic Wallpaper Engine and how we could upstream parts of it to Plasma proper

…and a whole lot more, be sure to check out all the other reports by the other attendees over at the Planet

I also got some hacking in between session and on the train and managed to finish a very nice feature for Plasma 6.4. Systemmonitor will now be able to display the GPU usage of each process and how much VRAM it is using.

Grazer Linuxtage

On Saturday we had a booth at Grazer Linuxtage showcasing Plasma and KDE software such as Krita on various form factors such as laptop, phones, the Steam Deck and a graphics tablet with a built in screen (connected to a laptop). The interest was immense and it was very nice to see many children attending the event and being interested in Linux. After the event we even managed to pull an elaborate heist and smuggle the poster designating our booth curled up inside a roll-up banner outside the venue.

Epilog

Big shutouts to Harald and Kevin for organizing the Sprint. Thank you to Grazer Linuxtage for making it possible to have the Plasma Sprint there, my employer Techpaladin Software for sending me there, and the KDE e.V. that makes it possible for others to attend (donations always welcome).

Next week I will in Munich to attend Qt World Summit and Qt Contributor Summit, see you around!

Earlier last month I helped organize conf.kde.in 2025 in the Gandhinagar, Gujarat. This was very exciting for me as it was apparently in same venue where I had attended my very first KDE event!

General structure of event

As of recent years, conf.kde.in has been three-day event, two days of conference followed by one day of un-conference sessions, those of who attend the Akademy or GSoC mentor summit, this is not a new format. Un-conference allows audience to schedule a session they’re interested in and is pretty much open-mic session for anyone.

I attended my first Plasma sprint, and indeed my first in-person KDE event! It was an amazing experience! 😄

It was really great to be in the same room with so many talented and knowledgeable people. The amount of expertise gathered together was fantastic. The usual difficulties with remote communication were gone, and suddenly we could have easy back-and-forths, go sit next to someone to ask their expert opinion, and big group discussions could flow freely in a fraction of the time it would normally take.

Some of the cool things we talked about and worked on are: sandboxing (including things other than apps, like Plasma widgets and runners for KRunner), KNewStuff (where we can download new widgets/themes/etc), Activities, Telemetry, and oh so much more! We covered so much in such a short time it had my head spinning.

We also discussed the first-run experience (FRE) or out-of-the-box experience (OOBE) that is my current main focus. For those who are unfamiliar, this is the flow that happens when a user first turns on a new computer where it asks them to create the first user. Currently this doesn't exists for KDE (outside of some hacks that have significant drawbacks), and the user has to be created during system installation. For technically inclined users doing their own system install this is no problem, but it is a big problem for other scenarios; think for example about…

• Government organizations or large businesses who want to image computers with the system software
• OEMs who need to pre-install an operating system
• Used computer shops saving those millions of PCs that can't run Windows 11

For all of these scenarios and more, the operating system needs to be installed but the user account should not yet be created. Rather once the intended end-user has opened up the box and turned on their shiny new computer, only then should they be prompted to "Choose your username and password" (among other things).

It was great to be able to present the vision for this, and I got great feedback, questions, suggestions, etc. Working together we came up with a solid plan to proceed, and I've started the work of implementing all of these ideas!

On the personal front, the whole experience was pretty challenging for me. Right off the bat my pre-existing medical condition means that I don't have much energy to work with on a daily basis, and that I get sick worse/more easily than most people do.. and wow did I ever get hit with the whole shebang!

After being hired on as the new Plasma Software Engineer, I had just under 2 weeks notice to try and arrange to attend the sprint. This started with needing my passport; I already had an appointment to get it, but not until just after the sprint (I was getting it originally for use to attend Akademy!). So I had to go down and spend the entire day at the passport offices, to ask for it to be issued expedited - which thankfully I got! Then was a whirlwind of things like...

• Research (do I need a visa? what can I/can't I bring? what should I bring? Is there any potential issues bringing my meds? (yes), travel insurance, mobile service, etc)
• Booking travel & lodging, and trying to do so at a semi-reasonable price while booking last minute
• Buying supplies for travel (toothbrush, laptop bag, water bottle, travel umbrella, climate appropriate clothing (we just had snow/ice storms in Canada before I left, and it is still getting down near freezing at night!), etc, etc)

Though I will say it is pretty lucky I had been casually learning German for the fun of it the past couple years. I definitely need more speaking practice though!

I am very happy I managed to attend, but generally I would not recommend trying to arrange one's first international travel with only several day's notice haha! 😂

Yeah, that's right.. first. I've rarely been away from my hometown before, and I've actually never left my native timezone previously! So travelling to the other side of the planet was a bit of a change, to say the least. The travel was more than I expected: ~2 hr bus ride to the airport, waiting for hours to get on the plane, ~10 hrs across the ocean, ~2 hr layover, ~1 hr additional to Graz, then ~1.5 hrs figuring out the train/tram from the airport to the venue (I had to ask for help figuring out how to get to the train station).

With all of this, the jetlag, as well as working 9 to 10 hour days I was feeling incredibly exhausted to put it mildly. Then I thought I was having a massive attack of allergies (I did just come from the land of ice and snow to a place where everything is green and blooming after all…), alas sadly I did catch a cold or something quite nasty that I am still trying to shake off. 😷🤧🤒😴

I learned a whole lot about travelling, there are a bunch of things I would do differently, and I am confident that my next trip will go much more smoothly as a result!

I am so glad that I got to attend, because we got some great work done and I met lovely, friendly people. It was a very nice atmosphere, and everyone was very kind and welcoming. It is really good to be able to put faces to the names of people I've been working with for years in some cases!

I am really looking forward to seeing everyone again at Akademy~ 🎉 Tschüss!

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

This year’s Plasma Sprint had a very special meaning for me. For the first time, in a long time, I feel like I am contributing something big for the community. It has the potential of setting our development process on steroids.

The goal is to remove so much designing from the work our developers do and bring more design to the hands of designers. That way we can all communicate better and focus on the things that we do best.

My goal for the sprint was to get buy-in from the development team to start the process of implementing our design system foundations. The days were long but the team was positive about this change. While we don’t know exactly how big things will get, we at least are committed to delivering an easier development platform for our Community.

With that in mind, I completed (first pass) the work on making monochrome icons. I then started making colorful icons for our colorful collection. I was able to get a good idea of what works well for us.

A couple of amazing things allowed me to make better icons. Qt 6.9 onward contains a bigger implementation of TinySVG which now allows us to use Gaussian blurs and offsets to create shadows and gradients. If you didn’t know this, our previous icons had to rely on cutouts and tricks to generate gradients. This added a tremendous amount of graphic development time. However, with this change, we don’t have to do this kind of work. I am so excited for this. So excited that I wanted to show you a preview of the colorful icons:

Please note that these are still in early development and there is a lot of testing that I need to do to make them viable and visible for users. They may change a lot between now and the time they are provided. However, my goal is to have a complete Breeze icons replacement that users can test by Akademy 2025.

So while all the friends were coding, I was clicking away 1000 clicks per minute to get this part going forward! haha.

We also decided to map our design system variables to the elements provided by Qt. I will be doing that work as well and already set up a project in Qt Creator to get started. Should be able to share that with the team soon.

All in all, I was happy to see everyone, develop awesome software together and I am looking forward to our next gathering in Berlin later this year.