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!

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!