Welcome to a new issue of “This Week in Plasma”! Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This was another big week, the result of Plasma 6.4’s soft feature freeze fast approaching and then taking effect today. So there are tons of useful and interesting user-facing changes! I think Plasma 6.4 is shaping up to be a big release! Check it all out:

Notable new Features

Plasma 6.4.0

18 years after it was first requested, you can now configure the system so that dragging-and-dropping files and folders to another location on the same disk automatically moves them, rather than asking every time. (Sebastian Parborg, link)

You can now activate KWin’s full-screen zoom feature with a three-finger pinch gesture (thumb plus two fingers). (Xaver Hugl, link)

System Monitor now lets you monitor GPU usage on a per-process basis (Intel and AMD only for now; NVIDIA is coming later). (David Redondo and Lenon Kitchens, link)

The Task Manager now lets you configure it so that scrolling on a Task will cycle through only its windows, rather than all windows. (Theo Luschnig, link)

Added a new “Sensors” page to Info Center that allows you to see raw sensor data. (Thomas Duckworth, link)

Notable UI Improvements

Plasma 6.4.0

System Monitor’s History page now includes two styles of CPU graph (total and per-core) and also includes a GPU usage graph. (Arjen Hiemstra, link)

…But don't worry, if you had customized the History page in the past, your customized version will be preserved!

Improved the default quality level of the RDP server, and clarified the range of responsiveness/quality levels that you can choose between to be more sensible. (Akseli Lahtinen, link)

The authentication dialog now plays a sound from the sound theme when it appears. (Bogdan Cvetanovski Pašalić, link)

Frameworks 6.14

The dialog that asks you whether you want to open or run a file is now much fancier! (Kai Uwe Broulik, link)

Notable Bug Fixes

Plasma 6.3.5

Fixed a bug that caused notifications whose text include the < character to cut off all the following text. (Akseli Lahtinen, link)

Fixed a bug that caused Sticky Notes widgets on the desktop to forget their custom size if you resize them. (Christoph Wolk, link)

Plasma 6.4.0

Removed the videos from System Settings’ Desktop Effects page, since they were all in various states of brokenness, and basically could not work over the long term because nobody is going to keep them up to date. Removing them fixes multiple bugs. (Oliver Beard, link 1, link 2)

The item labeled “C” in language lists on System Settings’ Region & Language page now works. (Han Young, link)

Fixed a bug that caused Breeze-themed group box titles using non-default fonts and font sizes to not appear correctly. (Kai Uwe Broulik, link)

The System Tray configuration window’s “Entries” page is now smarter about knowing when a change that was made but not applied before being reverted shouldn’t be counted as a changed setting. (Christoph Wolk, link)

Fixed a bug with the “Activate, raise and pass click” window click mode setting not always raising the window. (John Kizer, link)

Gear 25.08.0

The System Tray icon for KTeaTime now respects your Plasma style’s color scheme properly, and the steeping indicator is rendered at an appropriate size. (Fabian Vogt, link 1 and link 2)

Frameworks 6.14

Other bug information of note:

• 1 very high priority Plasma bug (same as last week). Current list of bugs
• 20 15-minute Plasma bugs (down from 21 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.4.0

If you have a misbehaving monitor that doesn’t play nicely with DDC/CI (the mechanism that allows Plasma to manipulate screens’ hardware brightness levels), you can now disable this. (Jakob Petsovits, link 1 and link 2)

Implemented support for the “Relative tablet dials” (zwp_tablet_pad_dial_v2) Wayland protocol. (Nicolas Fella, link)

Implemented support for the “Toplevel tag” (xdg_toplevel_tag_v1) Wayland protocol. (Xaver Hugl, link 1 and link 2)

Implemented support for the “Color Representation” (color_representation_v1) Wayland protocol. (Xaver Hugl, link)

Improved game controller joystick support in various ways. (Jeremy Whiting, link)

The DrKonqi crash tracing system now uses much less memory while working, making it less likely to cause your system to run out of memory and terminate it. (Harald Sitter, link)

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.

You can help KDE by becoming an active community member and getting involved somehow. 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:

• Triage and confirm bug reports, maybe even identify their root cause
• Contribute designs for wallpapers, icons, and app interfaces
• Design and maintain websites
• Translate user interface text items into your own language
• Promote KDE in your local community
• …And a ton more things!

You can also help us by making a donation! Any monetary contribution — however small — will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

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!

Let’s go for my web review for the week 2025-18. This is another big one with old articles, I’m not done purging the treasure trove I mentioned a couple of weeks back.

Security Education Companion

Tags: tech, security, education

Need to teach security basics to your family, friends and neighbors? Here is a nice resource to do a good job there. We often approach the task the wrong way.

https://www.securityeducationcompanion.org/

Future of OSL in Jeopardy

Tags: tech, foss, politics

A reminder that reckless political decisions can have dire consequences for quite a few FOSS projects.

https://osuosl.org/blog/osl-future/

Third Party Cookies Must Be Removed

Tags: tech, web, privacy, attention-economy, standard

I have a hard time seeing browser makers truly drop third party cookies without pushing a worse replacement first… Still, it’s nice to see the W3C take a stand in the matter.

https://w3ctag.github.io/web-without-3p-cookies/

As engineers, we must consider the ethical implications of our work

Tags: tech, engineering, ethics

This opinion piece is getting old… and yet, it doesn’t feel like our professions made much progress on those questions.

https://www.theguardian.com/commentisfree/2013/dec/05/engineering-moral-effects-technology-impact

How and why to properly write copyright statements in your code

Tags: tech, licensing, foss

This is one of the best references I know on the topic. It’s not that long, to the point and all developers should know it.

https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code

Deep learning and shallow data

Tags: tech, data, machine-learning, computer-vision

A look back at the limitations of deep learning in the context of computer vision. We’re better at avoiding over fitting nowadays but the shallowness of the available data is still a problem.

https://blog.piekniewski.info/2019/04/07/deep-learning-and-shallow-data/

Are “AI” systems really tools?

Tags: tech, ai, machine-learning, gpt, tools

Interesting point of view… what makes a tool really?

https://tante.cc/2025/04/27/are-ai-system-really-tools/

xAI Dev Leaks API Key for Private SpaceX, Tesla LLMs

Tags: tech, ai, machine-learning, twitter, tesla, security, politics

They’ve been warned of this leak by GitGuardian weeks ago… and did nothing. For people manipulating such sensitive data their security practices are preposterous.

https://krebsonsecurity.com/2025/05/xai-dev-leaks-api-key-for-private-spacex-tesla-llms/

I use Zip Bombs to Protect my Server

Tags: tech, compression, security, memory

Nice little trick to get rid of some malicious bots.

https://idiallo.com/blog/zipbomb-protection

The Day Anubis Saved Our Websites From a DDoS Attack

Tags: tech, ai, machine-learning, gpt, security

Of course it helps also against DDoS attacks… tells something about the state of AI scrapers I guess.

https://fabulous.systems/posts/2025/05/anubis-saved-our-websites-from-a-ddos-attack/

Use The Index, Luke: SQL Indexing and Tuning e-Book for developers

Tags: tech, databases

Looks like a good resource to better understand indices in relational databases.

https://use-the-index-luke.com/

O(no) You Didn’t 😱

Tags: tech, performance, complexity, profiling

Nice little article. It’s a good way to point out that aiming for the lowest Big-O approach is often not what you want in terms of performance. Always keep the context in mind, and in doubt measure.

https://mrshiny608.github.io/MrShiny608/optimisation/2025/04/22/OhNoYouDidnt.html

Accurate mental model for Rust’s reference types

Tags: tech, rust, memory, type-systems

Mutable vs immutable is a good first approximation… but it goes further and this little article does a good job explaining why.

https://docs.rs/dtolnay/0.0.6/dtolnay/macro._02__reference_types.html

Making PyPI’s test suite 81% faster

Tags: tech, tests, python, optimization

Good proposals to shorten the time spent executing tests. Tighter feedback loops make everyone happy.

https://blog.trailofbits.com/2025/05/01/making-pypis-test-suite-81-faster/

6 Tips to supercharge C++11 vector performance

Tags: tech, c++, programming

Some tips which are easily forgotten to get the most out of std::vector.

https://acodersjourney.com/6-tips-supercharge-cpp-11-vector-performance/

C++26: Removing language features

Tags: tech, programming, c++

Of course, we’d like more to go away… But that’s already something.

https://www.sandordargo.com/blog/2025/03/12/cpp26-removing-language-features

Get out of my <head>

Tags: tech, html

Nice little resource to better understand some of the tags which appear inand what they’re used for.

https://getoutofmyhead.dev/

Polishing your typography with line height units

Tags: tech, web, css, fonts

Didn’t know we had this unit. It’s welcome indeed.

https://webkit.org/blog/16831/line-height-units/

Techniques for Creating Textured Text

Tags: tech, web, frontend, html, css, fonts

A good tour of various techniques available on the web for making textured text.

https://tympanus.net/codrops/2013/12/02/techniques-for-creating-textured-text/

Against Horizontal Scroll

Tags: tech, html, css, ux, mobile

Avoiding them requires some care when designing the page and CSS.

https://matklad.github.io/2025/04/22/horizontal-scroll.html

9 Anti-Patterns Every Programmer Should Be Aware Of

Tags: tech, design, pattern, programming, engineering

There are clearly more to know. But this is a good list already.

https://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

Differential Coverage for Debugging

Tags: tech, debugging, coverage

This is indeed a good way to guide your debugging. Using coverage information can sometimes reduce the search space.

https://research.swtch.com/diffcover

Is High Quality Software Worth the Cost?

Tags: tech, quality, cost, productivity

We often hear that question about the trade off between quality and cost. The question is badly framed though. If it’s low quality it’s requires more effort to add or change features… and so it’s more expensive mid-term (not even long term).

https://martinfowler.com/articles/is-quality-worth-cost.html

Testing sync at Dropbox

Tags: tech, syncing, filesystem, tests

Testing sync engines can be especially challenging. This story from Dropbox gives ideas on how to do it well.

https://dropbox.tech/infrastructure/-testing-our-new-sync-engine

What if we embraced simulation-driven development?

Tags: tech, tests, distributed, reliability, simulation, complexity

At some point the complexity is high enough that you indeed need more tools than only handcrafted tests to discover bugs.

https://pierrezemb.fr/posts/simulation-driven-development/

The Practical Test Pyramid

Tags: tech, tests, tdd

A bit long and dated for a some advice. Still it does a very good job going through all the different type of tests you’ll want to find on your project and how they’re structured.

https://martinfowler.com/articles/practical-test-pyramid.html

Unit Tests are not Friends

Tags: tech, tests, c++

Of your tests are friend with implementation classes in C++, then something is wrong. Such tight coupling between tests and implementation is not welcome.

https://arne-mertz.de/2015/08/unit-tests-are-not-friends/

Unit Test

Tags: tech, tests, tdd

Good reference to get an idea about what we should be considering when we talk about unit tests.

https://martinfowler.com/bliki/UnitTest.html

Loosely Coupled Tests

Tags: tech, tests

Definitely be careful when using mocks. You can end up introducing too much coupling between your tests and the application code. Use alternative test doubles instead and reduce duplication.

https://8thlight.com/insights/loosely-coupled-tests

You won’t believe how old TDD is

Tags: tech, tdd, history

A reminder that the technique goes back to way before XP.

https://arialdomartini.wordpress.com/2012/07/20/you-wont-believe-how-old-tdd-is/

Visualizations of Continuous Delivery

Tags: tech, ci, sketchnotes

Very nice sketchnotes about Continuous Delivery.

https://continuousdelivery.com/2014/02/visualizations-of-continuous-delivery/

Extreme Programming: Whole Team

Tags: tech, agile, xp, team

What is the “Whole Team” practice from XP? Well, it’s fairly simple in the end… it’s about collaboration really. Needs to be reminded often though.

https://codingjourneyman.com/2015/04/13/extreme-programming-whole-team/

Ways to Make Code Reviews More Effective

Tags: tech, codereview

A good reminder that reviewers have many things to keep in mind and evaluate. This is why what can be automated should be automated.

https://www.infoq.com/articles/effective-code-reviews/

Why pair programing is as much about business continuity as it is about code quality

Tags: tech, pairing, business

Developers tend to push for pair programming mostly for technical and code quality reasons. This is fine, but often the fact that it also spreads knowledge and ensures business continuity is forgotten.

https://thinkfoo.wordpress.com/2014/05/25/why-pair-programing-is-as-much-about-business-continuity-as-it-is-about-code-quality/

On Pair Programming

Tags: tech, pairing, programming, codereview

A good in-depth article about pair programming. Shows well the pros and cons.

https://martinfowler.com/articles/on-pair-programming.html

Story Points Revisited

Tags: tech, agile, xp, estimates

They’re so misused that it’s better to let them go. Indeed, we can go as far as wondering if estimating stories instead of slicing them is a good idea at all. Doesn’t mean all estimates disappear of course, but at the single story resolution? You likely better invest time in slicing them better.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

The Difference Between a Story and a Task

Tags: tech, agile, scrum

Short and to the point. It needs repeating from time to time for some reason.

https://www.mountaingoatsoftware.com/blog/the-difference-between-a-story-and-a-task

Writing User Stories for Back-end Systems

Tags: tech, agile, scrum

Or why the term “user” in “user stories” need to be seen very liberally.

https://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems

Why 90 percent gets Kanban wrong! – and getting it right

Tags: tech, agile, kanban

Indeed, Kanban is massively misunderstood. This is unfortunate, this article does a good job explaining what this is about.

https://www.agileupgrade.com/why-90-percent-gets-kanban-wrong-and-getting-it-right/

5 questions that reveal if a company has a healthy workplace culture

Tags: hr, interviews

As I often says: interviews are also for candidate to evaluate the potential employer. If you’re interviewing there are good questions to ask, here are a few ideas. I think I’m almost never asked those unfortunately…

https://canopy.is/blog/2017/11/21/5-questions-that-reveal-if-a-company-has-a-healthy-workplace-culture/

How to win your first clients

Tags: sales

I generally don’t like this kind of articles. It’s often snake oil salesmen writing this… Now this one has good advice instead. Of course it doesn’t mention how much luck has to be involved as well.

https://oliveremberton.com/2013/how-to-win-your-first-clients/

Monty Python and the Holy Grail turns 50

Tags: movie, culture, funny

Still a masterpiece if you ask me. I love that movie.

https://arstechnica.com/culture/2025/04/monty-python-and-the-holy-grail-turns-50/

Bye for now!

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.

A few days ago I returned home from a wonderful Plasma sprint in Graz, Austria. Between COVID-19 and there being no Plasma sprint last year in favor of the Goals mega-sprint, this was actually only my my third in-person Plasma sprint! So I was very excited to attend. There’s much to talk about!

Sprints are often said to come in two flavors: “talking” sprints, which are mostly about discussing big topics; and “working” sprints, where folks write lots of code. This one was a bit of both — a good mix, I think.

For my part, I wanted to talk about some big topics and see if we could get them unblocked. And talk about them we did! There were many more discussions besides these, but here’s a summary of the ones I led:

Plasma LTS

It’s no secret that our Plasma LTS (“Long-Term Support”) product isn’t great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there’s no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there’s the fact that “LTS” means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.

Our conclusion was that the fairly limited nature of the product isn’t meeting anyone’s expectations, so we decided to not continue it. Instead, we’ll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six.

We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we’d also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.

For some background, last Akademy we decided to postpone making this schedule change until all the KDE items on the “Wayland known significant issues” wiki page are addressed. During the sprint, we took another look and found the list much shorter than it was last year, with most remaining items in progress or nearing completion! So we agreed to revisit the topic again around this year’s Akademy in about 4 months (reminder to submit a talk!).

I hope that by then we’ve either got everything done, or can consider it close enough that we can pull the trigger on the new schedule anyway — the latter outcome being what we did for the Wayland-by-default rollout.

However, the concept of “Long-Term Support” doesn’t go away just because we’re not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It’s a lot of work.

So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE’s bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can’t be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users’ unfamiliarity with software release schedules and bug reporting.

3rd-party content and theming

We’ve had some difficulty with the UX for how users get 3rd-party content, and what it does to their system once they’ve gotten it. Many folks will remember the issue last year when a defective 3rd-party Global Theme caused user data loss. It was Very Bad.

The issue here is that QML-based theming is just inherently dangerous because QML is code; there’s not really a way to make QML theming safe, so we’re working on moving away from it. David Edmundson wrote about this recently, too.

So far we’ve already removed QML-themability from the lock screen (a component that’s very sensitive to stability and security needs!), and during this sprint, we hit the OSDs too. We also made plans to remove QML-themability from splash screens and login screen themes, and instead you’ll simply be able to choose custom images.

However, some things will always have to contain QML code, like 3rd-party widgets and wallpaper plugins. For these, we devised a plan to sandbox them so they can’t blow up the world if they misbehave. This will also make Global Themes safe, since Global Themes can include them. I wasn’t able to follow all the details of the proposed sandboxing system, so others will have to fill in the blanks with their own blog posts!

Finally, we talked about the distribution channel of https://store.kde.org, exposed via the “Get new [thing]” dialogs sprinkled throughout System Settings and KDE apps. What some might not know is that this distribution channel is not actually owned by KDE; it’s simply a themed front-end to https://pling.com. And that’s one of the issues: people think this is owned by KDE, and it’s not! Some other concerns included the lack of approval-required moderation for new content with stability or security implications; lack of automatic linting for content to make sure it’s valid; inability to specify a minimum Plasma version for QML-based content; and the place being sadly flooded with low-effort AI-created junk. We also talked about some UX issues in these dialogs and in Discover, and how we can address them.

We brainstormed what our ideal 3rd-party content distribution mechanism would look like if we were creating one from scratch, and the degree to which our current UX does and doesn’t approach it. I’ll be reaching out to the folks behind Pling to see if we can work on any improvements there so we can make reality converge more with our desires!

Activities

Activities has been in a weird place for a long time now. It’s a feature that’s somewhat difficult to explain in an elevator pitch, and with a more limited scope than you might expect. We all pretty much agreed that it’s not ideal, and not as useful as it could be.

So we brainstormed many alternatives, taking into account feedback and experiences from people at the sprint who currently do use Activities, or would like to if it met their needs.

Something that came up over and over again was the desire to use certain apps differently in different Activities. For example in your “Home” Activity, you could have your email client set up to only show your home email accounts, whereas in your “Work” activity, you could have the same app set up with only the work email accounts, or with both. But it would be the same email client app in each Activity, just configured differently!

This functionality right now needs to be provided by each app implementing its own “profiles” or “sessions” feature — and of course, most don’t. So an idea that stuck was for us to make this into a system service that can basically bolt the functionality of multiple profiles/sessions onto any app! This would be easiest for containerized apps that already have their own separate location for configuration data, so this is where we’ll start. But it’s possible we’ll also be able to open it up to un-containerized traditionally-packaged apps too, using Firejail or another similar technology.

We thought this feature would be useful even outside of Activities, so our conclusion thus far has been to build it first! After it’s in production and the kinks have been worked out, it would then become the basis for the Activities system’s new scope: “configure and use your apps and virtual desktops differently in each Activity.”

There are no timelines for any of this yet; it’s still in the “turn a discussion into a plan” phase.

Telemetry

There was broad agreement that the status quo is not ideal: we collect very little data from people who have opted in (because it’s off by default), and we don’t have a path towards changing what data we collect in response to newly-discovered questions we’d like answered.

For example, let’s say we want to remove a very niche KWin effect that we think probably nobody’s using. Right now, we have no way of knowing how many people have it turned on, and of them, how many people are actually using it — let alone reaching out to ask them why! So we have to just go by gut feelings when we make that decision, or get spooked and not do it at all.

So we decided to change the way we collect telemetry to be more like the common and successful Steam Hardware Survey. Our telemetry UX will be the same: people will see a dialog window asking them to participate in the survey, and in there, they’ll see what data will be collected. They’ll have the opportunity to say yes, say no, or turn it off forever. And for each survey, we can tailor the data collected to what we actually want to know! So we could have it collect information about that KWin effect, and it could even prompt the people using it to write a little bit of text explaining why.

We also discussed how the current place to view collected data is not ideal. Right now there’s a GUI app which is slightly broken, and a web page you have to type raw SQL queries into to see anything besides the default visualizations. Not ideal! We brainstormed a better web UX so we can make better use of the data we do currently collect. We also agreed that we want to make the aggregated data public, just like Valve does with the results of the Steam Hardware Survey.

And more

In addition, I got in a lot of hacking time between discussion sessions, which felt useful. Being able to sit down with other people unblocked some work, both mine and theirs, as a result of some productive face-to-face conversations! And I got to see a lot of old friends again, and meet a few in person for the first time. The city of Graz was lovely too — such a sensible and humane-feeling place.

Thank you to TU Graz for hosting us for this sprint, to Techpaladin Software for sponsoring my travel and lodging costs, and to Harald Sitter for organizing everything!

Last week I attended the Plasma (Mobile) Sprint and the following Grazer Linuxtage 2025 in Graz, Austria.

Plasma (Mobile) Sprint

There’s detailed notes in the Wiki, I was mostly involved with mobile related topics and how those align with our Android support.

• Power management and device sleep for the push notification server.
• Common infrastructure for alarms and “long-distance” timers, which is another power-management related topic. While we have some parts of the backend implementation here already, there’s no cross-platform API for applications yet.
• Supporting display cutouts/notches. There’s basic application-facing API in Qt 6.9 for this, which we yet have to make use of in Kirigami and/or applications. It’s however only backed by actual display data on Android and iOS, so we also have to build up the entire infrastructure behind this on Linux.
• Unifying (manual) location selection. We have an increasing number of features depending on an (approximate) position (night light, timezone switching, weather and emergency alerts, etc), all with their own and sometimes very different UIs for choosing how the location is determined.

We also looked at a few implementation details:

• Using XDG portal APIs for camera and location access in Qt, to make this transparent for applications.
• Localized sorting issues due to the wrong or incomplete collate APIs being used.
• Possible ways to deal with date and date/time formatting in QML without losing timezone information.

On Thursday we even got a thunderstorm for testing the weather warnings, a nice touch by the organizers.

In person meetings are extremely productive, as you can see here and by reports from others on Planet KDE. They often involve travel cost though, that’s where your donations to KDE e.V can help!

Itinerary Sprint

And of course every KDE sprint is implicitly also an Itinerary sprint:

• The live status view can now also use the OpenRailwayMap infrastructure, signaling, electrification, speed and gauge map styles.
• Improved support for importing tickets from ÖBB NightJet and local transport in Graz, as well as a&o Hostels Apple Wallet files.
• Improved applying live updates to multi-ticket trips.
• Improved geo coding and address editing, including a fix for QtLocation not forwarding Nominatim house numbers correctly.
• David R looked into simplifying and improving the horrible journey progress bar code.
• Moved more UI components from Itinerary to KPublicTransport, for sharing with KTrip.

Bhushan discovered a hotel that apparently provides key cards as Apple Wallet passes. That’s something we of course would want to support in Itinerary, but we lacked actual test cases so far. Good to know for the next visit to Graz.

Grazer Linuxtage

As the Plasma sprint was not only directly before Grazer Linuxtage but also essentially in the same venue at TU Graz, we could conveniently participate there as well.

KDE had a booth with Plasma and KDE applications running on a variety of devices, including laptops, mobile phones, drawing tablets and gaming consoles, with Krita, HDR video playback and Plasma Mobile drawing particular attention.

Attached to the booth we had an improvised hacking area where sprint work continued.

Outlook

The setup and combination with Grazer Linuxtage worked great, and being able to do a sprint for a bit longer than just a weekend makes this a lot more effective. Thanks for everyone who helped organizing this!

There might be the possibility to repeat this, and I’m certainly looking forward to return to Graz for an event or two next year :)

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