Kaidan 0.12.0 looks and behaves better than ever before!
Chats can now quickly be pinned and moved.
In addition, the list of group chat participants to mention them is placed above the cursor if enough space is available.
With this release, OMEMO can be used right after migrating an account and migrated contacts are correctly verified.
The developer teams continued to improve the Qt6 port of Krita. Dmitry fixed the HDR support on Windows (Dmitry Kazakov, link). Freya fixed an OpenGL crash on macOS (Freya Lupen, link).
Carl Schwan reduced the memory usage of various Akonadi resources by around 75% each. The optimized resources, which take advantage of this new API, are the following: Birthday, VCard files and directories, Ical, Mbox, Open-Xchange, cardDAV and calDAV. There is already significant progress done in that direction also for the IMAP and POP3 resources. The technical background behind this is that these resources running as independent processes are now using non-visual QCoreApplication instead of the more powerful QApplication, which is more appropriate resource wise for background services. This is part of the Don't depend on QtWidgets in lower parts of the stack milestones. (Carl Schwan, 25.08.0. Link 1, link 2, link 3, link 4, link 5, link 6, link 7, link 8, link 9, link 10, link 11, ...)
Daniel made a change to ensure that operations in Akonadi that operate on a large number of items are processed as multiple smaller batches which the SQL engine can then handle (Daniel Vratil, 25.08.0. Link).
Merkuro Calendar Manage your tasks and events with speed and ease
Tobias ported Merkuro Calendar to the new QML declaration which slightly improves the performance but more importantly enables us to take advantage of the QML tooling (Tobias Fella, 25.04.0. Link).
Carl made the region used to display holidays configurable. You can also select more than one region now (Carl Schwan, 25.04.0. Link)
Kleopatra Certificate manager and cryptography app
Tobias moved the notepad feature to a separate window, which means it's now possible to have multiple notepads open at the same time (Tobias Fella, 25.08.0. Link).
Tobias also ensured the GPG password prompt (pinentry) in Kleopatra is properly parented to the correct parent window on Wayland (Tobias Fella, 25.04.0. Link). Other apps using GPG were also fixed.
KOrganizer KOrganizer is a calendar and scheduling application
Allen made a series of small improvements and bugfixes to Korganizer. He improved the configure view menu action description (link), added more information to the delete folder dialog (link), and added a search option to consider the current view filters. (Link).
The digiKam team released version 8.6.0. of the powerful photo classifying and editing tool. Among many other things, digiKam now comes with a smarter face management tool, an improved auto-tagging system that identifies elements in your images, fully automatic red-eye removal, and a new image quality feature that classifies images according to their aesthetic quality. The digiKam developers also fixed 140 bugs.
Volker improved the history of past searches in KTrip by reusing some code from Itinerary. The biggest improvements are that the list is now de-duplicated, and the model supports more features not yet exposed to the UI. (Volker Kruase, 25.08.0. Link)
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
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. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. 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 your application mentioned here, please ping us in invent or in Matrix.
A Glyph Palette has been added to Text Tool Options, which allows selecting glyph alternates as well as showing a font character map (MR!2080). The Text Properties Docker now shows CSS Font Variants glyph properties (MR!2325) and OpenType features property (MR!2343).
Qt6 Port Progress
Krita now has Qt6 CI builds for Linux, Windows (MR!2328), and macOS (MR!2334). Android has yet to be built, as the platform has more complications and fewer developers working on it.
Most of Krita's custom Qt patches have now been ported by Dmitry, and ANGLE and HDR support are revived on Windows (deps commit).
For the March Art Challenge, @Elixiah has chosen "Virtual Plein Air Painting" using MapCrunch or Google Maps street view, as the theme. The optional challenge is doing paired entries; one urban, one rural. See the full brief for more details, and see the sights without stepping outside your door.
Featured Artwork
Best of Krita-Artists - January/February 2025
Nine images were submitted to the Best of Krita-Artists Nominations thread, which was open from January 14th to February 11th. When the poll closed on February 14th, these five wonderful works made their way onto the Krita-Artists featured artwork banner:
Krita is Free and Open Source Software developed by an international team of sponsored developers and volunteer contributors.
Visit Krita's funding page to see how user donations keep development going, and explore a one-time or monthly contribution. Or check out more ways to Get Involved, from testing, coding, translating, and documentation writing, to just sharing your artwork made with Krita.
Other Notable Changes
Other notable changes in Krita's development builds from Feb. 12 - Mar. 17, 2025, that were not covered by the Development Report.
Stable branch (5.2.10-prealpha):
Resources: Correctly load UTF-8 .pat pattern names. (bug report) (Change, by Nicholas LaPointe)
Unstable branch (5.3.0-prealpha):
Bug fixes:
Animation: Fix crash on closing secondary animated document during playback. (bug report) (Change, by Emmet O'Neill)
General: Fix menubar disappearing after toggling system global menubar feature. (Change, by Carl Schwan)
Features:
Freehand Brush Tool: Add Brush Smoothing options to adjust the smoothing based on brushstroke speed. (Change, by killy |0veufOrever)
Preferences: Add a global pen tilt direction offset in Tablet settings. This can be used to make tilt brushes work similarly for left- and right-handed users, or behave better without tilt support. (Change, by Maciej Jesionowski)
Scripting: Add Canvas.setPreferredCenter() and Canvas.pan() for panning the canvas. (Change, by Dov Grobgeld)
Python Plugins: Add Mutator plugin. This consists of an action to randomly modify brush preset settings such as color and size, and a docker to customize these mutations. (Change, by Emmet O'Neill)
I just got myself a brand new car: an ID.Buzz with seven seats so that I can fit the whole family at once. I’m very happy with the car this far, but since it has connectivity, I want to see if I can integrate it into HomeAssistant.
Having played with the software for a bit (and reported a bug that Till fixed asap – I’m impressed!) I decided to setup the whole thing on my little RaspberryPi that runs a few little services I use around the house.
Preparing this, I setup a new user and installed the software in a Python virtual environment:
sudo adduser carconnectivity
sudo su carconnectivity
cd
mkdir carconnectivity
cd carconnectivity/
python -m venv venv
source venv/bin/activate
pip install carconnectivity-connector-volkswagen==0.5a1 carconnectivity-plugin-mqtt carconnectivity-plugin-mqtt_homeassistant
vim carconnectivity.json
Using the vim command, I created the CarConnectivity configuration file. Update usernames, passwords and IPs to your needs. I will experiment with the interval parameter, as I don’t want to discharge the 12v battery by querying the car too much.
Having configured the service (and having run it manually to fix my mistakes) I created the carconnectivity.service systemd service shown below (in /etc/systemd/system):
Friendly country, Friendly people, Reunions, New Experience, a bit of hustle and that’s LIFE!
So, this was my 4th conference and 3rd international trip! A lot of new experiences and new friends, but let’s talk about FOSSASIA Summit 2025 first.
FOSSASIA Summit 2025
This is the first conference where I was having a lot of different tasks, lightning talk, representing Ubuntu booth and KDE booth. So, a lot of different perspectives will be here. Sometimes I’ll be writing from KDE’s pov, sometimes Ubuntu’s and sometimes my own.
One of the biggest obstacles for users switching to Linux is choosing the right distribution.
With the end of support for Windows 10 on October 14, 2025, many users are looking for alternatives to continue using their devices. This project aims to help users migrate from Windows 10 to GNU/Linux by analyzing their system specifications, asking relevant questions, and recommending a ranked list of distributions with KDE Plasma based on their preferences.
This post will break down how we approached this problem in SoK25, focusing on two core challenges:
Designing a recommendation logic that ranks distributions based on user preferences.
Detecting hardware specifications and integrating them into the ranking logic.
Original Idea
Step 1: Initial Design for the Questionnaire
When we started the project, we considered including a range of distributions and desktop environments. Over the course of SoK, however, we decided to limit the recommendations to distributions offering KDE Plasma. I will first present the original idea.
To keep things simple, we decided to limit the number of questions we would ask Windows users. Instead of overwhelming users with technical details, we settled on a set of key questions. These cover parameters like:
Ease of installation
Support for older hardware
Quality of documentation
Community support
Frequency of updates (Rolling or Point)
Preferred UI style (Windows-like or Mac-like)
Each response contributes to a “parameter” of user preference vector, which helps in matching the needs of user with the best-fitting distributions.
Step 2: Selecting Initial Distributions
We initially started with a limited set of well-known beginner-friendly distributions:
Fedora KDE
Kubuntu
Lubuntu
Linux Mint XFCE
Linux Mint Cinnamon
Revised Idea
Over the course of SoK25 we decided to narrow the scope of the chooser app and rename it Win10-2-KDE-Chooser. After receiving some feedback from the community, we decided it made sense to focus on KDE-only solutions for a Season of KDE project, while others can adapt the idea at a later date. With this new scope, we think the app can be promoted by the KDE community in the context of the ‘End Of 10’ campaign. The new scope includes:
The app will target devices running Windows 10.
The app will recommend distros with KDE Plasma.
The recommended distros for first-time users include Fedora KDE, Kubuntu, and Debian KDE (specifically the live installer, which uses Calamares).
In the rest of this SoK25 post, I will describe the implementation of the original idea in more detail, and this can later be adapted before release. This has been the focus of my work for the first half of SoK25.
Step 3: The Recommendation Logic
The core logic behind ranking distributions is vector-based similarity measurement. Each distribution is represented as a vector, with dimensions corresponding to the parameters defined in our questionnaire.
The approach works as follows:
User Preference Vector: The answers provided by the user form a vector with numerical values assigned to each preference.
Predefined Distribution Vectors: Each distribution has a corresponding vector based on predefined scores.
Similarity Calculation: The similarity between the user vector and each distribution vector is computed using a mathematical function.
TL;DR : We are using dot product and a penalty criteria (multiplying by 0.5) for ranking the distros
Choosing the Right Similarity Function
Initially, we considered cosine similarity, but we found that dot product gave better results.
Cosine Similarity measures how closely two vectors align in terms of direction, but it ignores magnitude.
Dot Product considers both direction and magnitude, making it a better fit since we care about absolute scores.
Example:
{width=456 height=164}
According to dot product:
A>B>C
Dot Product recommends Distro A as the best choice, which makes sense.
But according to cosine similarity:
C>B>A
Distro C appears as the best match because it follows the same ratio (even though its scores are much lower).
Since we care about absolute quality in preferred criteria rather than just proportional similarity, dot product is the better approach.
Here’s how we implemented the ranking in Python:
defrecommend(self):ifnotself.user_vectorornotself.distro_vectors:return"No sufficient data to generate recommendations."scores={}user_vector_np=np.array(self.user_vector)fordistro,vectorinself.distro_vectors.items():distro_vector_np=np.array(vector)score=np.dot(user_vector_np,distro_vector_np)scores[distro]=scoresorted_indices=np.argsort(list(scores.values()))[::-1]ranked_recommendations=[(list(scores.keys())[i],list(scores.values())[i])foriinsorted_indices]returnranked_recommendations
Step 4: Handling Categorical Questions
While numerical parameters like “Ease of Installation” are easy to quantify, categorical preferences (e.g., “Do you prefer a Windows-like UI?”) are more like binary or ternary preferences and are difficult to score.
To handle this, we introduced a penalty mechanism:
If a distribution does not match the user’s categorical preference, a penalty factor (e.g., 0.5) is applied to its score.
This ensures that distributions aligning with strong user preferences are ranked higher.
Here’s the modified code which ranks distros with penalties:
defrecommend(self,penalty_factor=0.5):ifnotself.user_vectorornotself.distro_vectors:return[]# Return an empty list instead of a string
scores={}user_vector_np=np.array(self.user_vector)binary_params={"updates","UI_Look"}fordistro,datainself.distro_vectors.items():distro_vector_np=np.array(data["scores"])final_score=np.dot(user_vector_np,distro_vector_np)forparaminbinary_params:ifparaminself.user_binary_preferencesandparamindata["raw_scores"]:ifself.user_binary_preferences[param]!=data["raw_scores"][param]:final_score*=penalty_factorscores[distro]=final_scorereturnsorted(scores.items(),key=lambdax:x[1],reverse=True)
Conclusion
This ranking system forms the backbone of the chooser app, helping users find the most suitable distribution based on their needs.
While our initial model looks good, we are still refining the parameters (questionnaire), expanding the dataset, and revising the app to fit the new scope
Next steps include:
Enhancing hardware detection to factor in compatibility scores. Given the limited time left in SoK25, I will only focus on Nvidia driver detection.
Improving penalty logic for better handling of categorical preferences.
This project has been an exciting challenge and I’m looking forward to refining it further. Stay tuned for more updates!
Acknowledgement
Thank you to the Season of KDE 2025 admin and mentorship team, in particular flyingcakes an Aakarsh MJ and Joseph, the KDE e.V., and the incredible KDE community for supporting this project.
Please feel free to contact me here: @drowsywings:matrix.org
After four months of active maintenance and many weeks triaging bugs, the digiKam team is proud to present version 8.6.0 of its open source digital photo manager.
The digiKam team has continued to work on a better Artificial Intelligence integration in digiKam, and many parts have been improved with the 8.6.0 release.
One of the biggest behind-the-scenes changes in the upcoming Plasma 6.4 release is the split of kwin_x11 and kwin_wayland codebases. With this blog post, I would like to delve in what led us to making such a decision and what it means for the future of kwin_x11.
Background
KWin started as an X11 window manager almost two and a half decades ago. Over the course of the years, it transformed drastically. It gained support for compositing on X, and it became a Wayland compositor.
Sharing the same codebase was critical in the early days of kwin_wayland. We already had working window management abstractions, which had been tested for many years, so we could reuse them on Wayland instead of writing new from scratch. Also, if kwin_x11 gained a new feature, then kwin_wayland would likely gain it for free too.
As time went by, kwin_wayland outgrew kwin_x11. They still shared code but they became quite distinct projects with different mental models how things operate, e.g. how pixels get on the screen or how input works. It also didn’t help that many Plasma developers jumped the X11 ship and turned to the Wayland side as part of the “eating your own dog food” practice, which eventually led to the feature freeze in KWin/X11 back in 2018 due to the lack of sufficient testing and various breakages.
Some time around 2020, we started taking a more bold and aggressive approach to Wayland session development because we saw that Plasma Wayland was trailing behind other desktop environments and something had to be changed in order to catch up. Such a policy produced great results, and Plasma is now one of the leading Wayland desktop environments. Unfortunately, it also greatly contributed to the number of regressions in the X11 session.
Another issue was that there were some features that we couldn’t make work as expected on Wayland so we had to drop them for everyone, which understandably made X11 users unhappy.
Goals
A few years ago, we started contemplating the idea of splitting the X11 and Wayland codebases because of the growing list of regressions affecting the X11 session, and architecture restrictions imposed on KWin/Wayland by the way KWin/X11 works.
That would allows us to keep KWin/X11 working as is without it breaking too often and freely change KWin/Wayland in ways that we think are best suited to make the Plasma Wayland session even better. Of course, it is not a silver bullet solution: we replace one problem with another problem (mainly related to maintenance and ensuring interface compatibility between two projects).
Details
After various discussions online and at Akademy and also seeing (impressive) Plasma Wayland usage statistics, we decided that it’s the right time to do such a split. The main kwin repository is going to host KWin/Wayland, while the kwin-x11 repository is going to host KWin/X11.
KWin/X11 and KWin/Wayland are co-installable so users can freely switch between the X11 and Wayland sessions back and forth and also make sure that updating to 6.4 is not a big hassle for distributions. You’ll be able to have only KWin/X11 or only KWin/Wayland on your computer, or both.
The codebase split doesn’t affect Xwayland support in KWin/Wayland. In other words, X11 applications will continue running on Plasma Wayland.
Extensions
Like any other Plasma component, KWin’s functionality can be extended using plugins. There’s good and bad news. The good news is that extensions written in JavaScript and QML (for example, fancy effects that are available at the KDE Store) will continue working both with kwin_x11 and kwin_wayland as expected, so extension developers don’t need to do anything about it. The bad news is that C++ extensions should be specifically targeted for kwin_x11 and kwin_wayland because neither provides API and ABI compatibility guarantees for its C++ API.
As Wayland progress moves forward, it is likely that the scripting API of KWin/Wayland will be further extended.
Future of KWin/X11
KWin/X11 will be still maintained for the foreseeable future. But that maintenance work will boil down to fixing build errors, adapting to new KDE Frameworks and Plasma APIs, and backporting window-related fixes from KWin/Wayland. There are no plans to drop KWin/X11 in the Plasma 6 lifecycle, although it’s highly possible that it will happen in Plasma 7.
KWin/X11 won’t receive new features anymore; until recently, it received new features that had been developed against KWin/Wayland passively (because both lived in the same repository). However, it might be actually a good thing because the X11 session doesn’t receive that much testing nowadays.
Ever wondered how todays apps can scale up so smoothly, bounce back from crashes like its no big deal, and keep running even when everythings going wrong? Well, the secret sauce is probably Kubernetesyep, the magic behind the scenes! Often called as K8s, Kubernetes is this awesome open-source platform thats basically taken over the tech world. But whats actually happening under the hood? How does it pull off all this magic? Lets dig in, take away the mystery, and see what makes Kubernetes so great!
The Rise of the Container Kingdom
Alright, lets begin with a brief overview before delving into Kubernetes. Picture yourself shipping products worldwide. You could simply throw everything onto a ship without any plan, but good luck dealing with that chaosit would be a complete disaster! Thats where containers enter the scene: neat, uniform boxes that enhance shipping efficiency and reliability. In the realm of software, Docker had a similar concept and thought, Lets apply this to applications! Now, developers can enclose their programs into these tidy little containers, including all necessitiessuch as libraries and configurations. Heres the catch: operating a single container? No issue, its extremely straightforward. However, attempting to oversee hundreds or even thousands of them across multiple machines, ensuring theyre all functioning, distributing the load, and remaining updatedthats when it becomes complicated very quickly. Thats where Kubernetes steps in, serving as the ultimate overseer, ensuring this entire container operation runs seamlessly and appears effortless
The Anatomy of Kubernetes
Kubernetes is fundamentally a framework that assists in the administration of containerized applications across various machines. It functions on a cluster architecture, which consists of two main components: the control plane, acting as the operational brain, and the worker nodes, which supply the essential computing resources. Lets explore this further.
The Control Plane: The Central Intelligence
The control plane is the starting point of everything. It encompasses multiple components that supervise the cluster, make crucial decisions, and ensure your applications operate correctly. Heres what it comprises:
API Server: The gateway to Kubernetes. Every interactionwhether you are deploying an application using kubectl or a component is assessing the clusters healthoccurs through the API server. It serves as the primary communication hub.
etcd: The memory bank of Kubernetes. This distributed key-value store retains the configuration data and state of the cluster. Consider it the definitive source of truth that ensures consistency across the system.
Controller Manager: The regulator. It monitors the state of the cluster and guides it towards your specified configurations (for instance, I require 3 replicas of this application). If a pod fails, the controller manager promptly intervenes.
Scheduler: The allocator. It decides which worker node will hold your new container by analyzing resource availability, constraints, and policies. It is similar to a game of Tetris, but centered on CPU and memory resources.
The Worker Nodes: The Essential Contributors
The worker nodes serve as the operational environment for your applications. Each node consists of a machine, which may be either physical or virtual, that is equipped with the necessary resources.
Kubelet: The local agent. It talks to the control plane and ensures the containers on its node are running as expected. If the scheduler says, Run this pod, the kubelet makes it happen.
Container Runtime: The Container Runtime is the software that retrieves images and initiates the containers, like Docker or containerd. It serves as the underlying engine for these operations.
Kube-Proxy: Kube-Proxy acts as the networking intermediary. It enables communication between pods and the external world by overseeing network configurations on each node.
To consistently align the desired statewhat you wish to achievewith the actual statewhat is occurringthe control plane and worker nodes collaborate to create a cohesive cluster.
The Magic Trick: Self-Healing and Scaling
Now that weve introduced the characters, lets witness the magic unfold. Two of Kubernetes most impressive abilities are its self-healing and auto-scaling features.
Self-Healing:
Picture this: youve launched a web application with 5 replicas. Suddenly, one pod fails because of a bug. In a conventional setup, you would be hurriedly trying to restart it. With Kubernetes, the controller manager detects the issuedesired state: 5 pods; actual state: 4 podsand directs a node to generate a replacement. Its as if the system has an intrinsic capacity to regenerate, rising from the ashes effortlessly.
Auto-Scaling:
Traffic spiking? Kubernetes has your back. The Horizontal Pod Autoscaler (HPA) watches metrics like CPU usage or custom app metrics. If your apps getting hammered, HPA tells the cluster to deploy more pods. When the storm passes, it scales back down. Its elastic computing at its finestno overprovisioning, no waste
Pods: The Smallest Spell in the Book
Pods are the wizard's tiniest spells, if Kubernetes is the wizard. The fundamental building piece is a pod, which is a wrapper around one or more containers that share network and storage resources. Consider it a comfortable home for the containers in your app. Kubernetes determines where pods reside in the cluster; you manage pods rather than containers directly.
Pods are meant to be transient. The scheduler and controller manager allow them to die and reappear in another part of the cluster. The flexibility of Kubernetes is largely due to this abstraction; pods enable it to rearrange workloads like a pro chess player.
Networking: The Invisible Threads
Containers need to talkto each other, to databases, to the internet. Kubernetes weaves a network thats both simple and powerful:
Every pod gets its own IP address, even across nodes, flattening the network and avoiding port conflicts.
Services provide stable endpoints for pods, load-balancing traffic across them. If a pod dies and respawns, the service keeps the connection alive.
Ingress controllers handle external traffic, routing HTTP requests with finesse.
Its like an enchanted web, ensuring communication flows seamlessly no matter where your pods land.
Why It Feels Like Magic
Kubernetes feels magical because it abstracts away the chaos of distributed systems. You declare what you wantvia YAML files or Helm chartsand Kubernetes makes it happen. Crash recovery? Load balancing? Rolling updates? Its all baked in. Under the hood, its a symphony of components working in concert, but to you, its a single spell: kubectl apply.
The Trade-Off: Complexity vs. Power
Of course, no magic comes without a cost. Kubernetes has a steep learning curveterms like persistent volume claims, CRDs, and RBAC can feel like arcane runes at first. And running it in production demands care: monitoring, logging, and security dont set themselves up. But for those who master it, Kubernetes unlocks unparalleled power to build resilient, scalable systems.
Conclusion: The Wizard Unveiled
Kubernetes isnt just a tool; its a paradigm shift. Under the hood, its a marvel of engineeringdistributed components, clever abstractions, and relentless automation. Whether youre running a small app or a global platform, K8s brings order to the chaos of modern computing. So next time you deploy a pod or scale an app with a single command, tip your hat to the magic happening beneath the surface. The wizardry of Kubernetes is realand its here to stay.
#this-week-kde-apps:kde.org
soumyatheman
GSoC
Friendly country, Friendly people, Reunions, New Experience, a bit of hustle and that’s LIFE!
{width=456 height=164}
Dear digiKam fans and users,
