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.
Last week I decided to clean up a bit of digital cruft. That is, I moved a few of my websites onto a single VPS, saving quite a bit of monthly server hosting costs.
What I did was that I moved VPSes from Linode (Akamai) to DigitalOcean, but also migrated a full web hotel from One to DigitalOcean (converting email accounts to email forwards).
As this is something that I do very rarely, I decided to document the process here so that I don’t have to look everything up again next time around.
The grunt work was about migrating a number of L*MP services to a LEMP server. There are a couple of tasks involved here, mainly migration of databases and getting WordPress running in a subdirectory using Nginx. The rest of the exercise had to do with the moving of nameservers and waiting for DNS propagation to get certbot to provide certificates for the new location.
Migration of MySQL databases
The migration of a database between machines can be broken down into three stages:
Dumping the old database
Creating a new database and user
Sourcing the database contents into the new database
I choose to do it in these three stages, as I’d like to keep the old database dump as an additional backup. The other option would be to transfer the database contents in a single step, merging steps 1 and 3 into one
Nevertheless, I use mysqldump to dump the database contents, and then bzip2 to reduce the size of the dump. This is efficient since and SQL dump is quite verbose.
This is derived from the answer by Anuboiz over at stack overflow. The resulting file is then transferred to the new server using scp together with the actual website.
The next step is to create a new database and a new database user. Here, I assume MariaDB (using the mysql commands), as my main target is WordPress. For other database engines, e.g. Postgresql, please check the docs for exact grammar, but the SQL commands should be very similar.
sudo mysql mysql> CREATE DATABASE databasename; mysql> USE databasename; mysql> CREATE USER 'username'@'localhost' identified by 'password'; mysql> GRANT CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, SELECT, REFERENCES, RELOAD on databasename.* TO 'username'@'localhost' WITH GRANT OPTION; mysql> EXIT
The next step is to read the database contents into the new database. For this, we need to unzip the sql dump, e.g. bunzip2 dumpname.sql.bz2, which will result in a file called dumpname.sql. Please notice that bunzip2 unzips the file and removes the original, zipped, file. If you want to keep the original, use the -k option.
Once you have the dumpname.sql file available, you can read it into the database with the newly created user using the source command as shown below.
mysql -u username -p
enter the password here
mysql> USE databasename;
mysql> SOURCE dumpname.sql;
mysql> EXIT
Now you should have a new database with the old database contents on the new server, with an associated database user. For WordPress sites, make sure that you reflect any changes in the associated wp-config.php file.
WordPress in a subdirectory using Nginx
The other piece of the puzzle that was new to me was to run WordPress from a subdirectory, e.g. example.com/blog/, rather than from the root level, e.g. example.com/.
Removing most of the nginx server configuration, the following parts does the magic:
server { root /var/www/thelins.se; index index.php index.html;
The trick was to ensure that the subdirectory try_files statement refer to the correct index.php. Notice that this has to be done for each WordPress instance, if you happen to have multiple WordPress installations in various subdirectories on the same domain.
Conclusions
Its a bit of hassle to migrate a lot of web sites at once, but the monetary saving from moving the low traffic sites onto a single VPS, and the simplification of the management and monitoring by moving all VPSes to a single provider makes it worth it.
#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,