The latest Qt release, Qt 6.11, is just around the corner. This short blog post series presents the new features that QML tooling brings in Qt 6.11, starting with qmlls in this part 1. Parts 2 and 3 will present newly added qmllint warnings since the last blog post on QML tooling and context property configuration support for QML Tooling.
Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.
Today they all get new bugfix source releases with updated translations, including:
Distro and app store packagers should update their application packages.
A project that I had planned for quite some time came to fruition last year, now I finally found time to document the result. My livingroom sideboard looked messy and kind of boring while not blending in anymore with the updated style of my living room. I wanted to turn it into a striking centerpiece of the room.
The plan was to install a sound-reactive lighting system. I wanted the light effects to be detailed and not disturbed by ambient sound in the living room, i.e. it sound not react to people’s voices, just the music playing.
My living room sideboard is an off-the-shelf product from IKEA that I bought many years ago. It didn’t have doors installed, but I was delighted that I could still buy matching doors with windows in them.
To realize the light effects, I’ve installed frosted plexi glass inside the windows.
To control the LEDs, I’m using an ESP32-based LED controller with a line-in module and an ADC (analog-digital converter). After some experimenting, I’ve found this board to work well. I’ve connected 6 WS2812B LED strips to 3 pins and installed them with an aluminium profile into the doors. The frosted windows and profiles diffuse the light nicely so you can’t make out individual LEDs really.
On the software side, I’m using a sound-reactive port of the WLED project. WLED is Free and Open Source software, of course. Though its user interface can be a little unwieldy, it’s also very powerful and integrates nicely with homeassistant, so it can be controlled automatically.
The ESP32, being a rather powerful dual-core microcontroller, can process the incoming audio signal on one core (using fast-fourier transformation) and compute complex LED effects on the other core. Rendering up to 200 frames per second to 2 times 210 LEDs is no problem while power consumption of just the controller stays well under 1W. Pretty impressive! Depending on the LED effects (number of LEDs lit up at a given time and their colors), the whole thing hardly ever reaches 10W of power consumption.
Another functional goal of this project was to solve cooling issues of my amplifier once and for all. The amp would run really hot and shut off after playing at higher volume for some time. I installed a bunch of 12cm fans which suck air through the amplifier and blow it out on the backside. Both amp and and fans are connected to smartplugs. I turned to my homeassistant and set up an automation which turns the fans on whenever the amp’s power consumption reaches a certain level. This works really nicely, since the fans never spin at lower volumes (when you could hear them through the music) and keep everything cool and running stable at higher volume when it’s necessary — without human interaction.
The outer shell of the sideboard is made of walnut wooden panels with an oil and varnish finish, thanks to my friend Joris. The oil gives it a darker look and accentuates the grain, matching the speaker system. The matte varnish finish (Skylt, highly recommended for its durability and natural look) allows me to sleep well even if people put their drinks on it.
I’m really happy with the result. While I had thought it out for a long time already, it’s always a lot more impressive when you see the final result in action.
The WLED firmware allows me to create interesting light effects. I can run the 3 doors as one, but also easily split them up into segments so each door panel renders its own effect. WLED has ca. 200 different LED effects, many of them react to sound. Each effect can be combined with one of 50 color palettes, some of the palettes are sound-reactive in their own right leading to a very dynamic display.
One cool feature is that the processed sound data can be broadcast across the network (over UDP) and received by other WLED controllers, so I can have multiple LED displays in the house, each rendering their own effect to the music, creating a more immersive experience.
Glaxnimate 0.6.0 is out! This is the first stable release with Glaxnimate as part of KDE.
The biggest benefit of joining KDE is that now Glaxnimate can use KDE's infrastructure to build and deploy packages, greatly improving cross-platform support. This allows us to have releases available on the Microsoft Store and macOS builds for both Intel and Arm chips.
But there is much more...
Glaxnimate now uses the KDE file recovery system making it more reliable.
Settings and styles also go through the KDE systems, which, among other things, lets you choose from more color themes for the interface.
Translations are also provided by KDE. This makes it easier to keep other languages up to date as Glaxnimate evolves. In fact, the number of available languages has increased from 8 to 26!
The script console has also been enhanced with basic autocompletion making scripting easier.
The timeline dock now allows effortless scrolling and provides buttons that make moving to different keyframes, and adding and removing them easier too. This contributes to making the animation workflow much smoother.
Hiding and showing layers from the timeline now interacts with the undo/redo system.
You can also quickly toggle keyframe easing without having to navigate menus. Just hold down the Alt key and click on the timeline.
SVG import and export has been re-worked, and precompositions are now properly exported and animations improved. You can even export an animation as a sequence of SVG frames.
We have improved the bezier editing tools, and included the ability to Alt-click on bezier points to cycle between tangent symmetry modes.
The Reverse path action is now implemented and works for all shapes. This is mostly useful when adding the Trim path modifier.
Version 0.5.4 included a significant refactoring of internal logic that introduced several bugs. These have now have been fixed.
The source code tarballs are available from the KDE servers:
URL: https://download.kde.org/stable/glaxnimate/0.6.0
Source: glaxnimate-0.6.0.tar.xz
Signed by: 97B71AA02D63EA6C5C44C23B962AC48EF0501F0B Julius Künzel julius.kuenzel@kde.org
Tuesday, 3 March 2026. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.6.2.
Plasma 6.6 was released in February 2026 with many feature refinements and new modules to complete the desktop experience.
This release adds a week’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:
View full changelog
Rocky Linux throws its support behind KDE, becoming our latest patron.
Rocky Linux is a stable, community-driven, and production-ready Linux distribution designed to be fully compatible with Red Hat Enterprise Linux. Rocky Linux powers clouds, supercomputers, servers, and workstations around the world.
"Sustainable Open Source depends on great open-source communities supporting each other" said Brian Clemens, Co-founder and Vice President of the Rocky Enterprise Software Foundation. "We do our best to support our upstreams, and backing KDE was an easy choice for us given the popularity of the Rocky Linux KDE spin."
"As a user-first community, KDE creates solutions to address real-world needs" said Aleix Pol, President of KDE e.V.. "We are excited to welcome Rocky Linux as a KDE Patron and see KDE's software shine on Rocky Linux, their enterprise-ready operating system."
Rocky Linux joins KDE e.V.'s other patrons: Blue Systems, Canonical, g10 Code, Google, Kubuntu Focus, Mbition, Slimbook, SUSE, Techpaladin, The Qt Company and TUXEDO Computers, who generously support FOSS and KDE's development through KDE e.V.
Hi Everyone ,I am Hrishikesh Gohain a third year undergraduate student in Computer Science & Engineering from India. For the past few weeks I have been working as a Season of KDE mentee with my mentors Joseph P. De Veaugh-Geiss ,Aakarsh MJ and Karanjot Singh. This post summarizes the work I have done until Week 5.
KDE Eco is an ongoing initiative by the KDE Community that promotes the use and development of Free , Open Source and Sustainable Software. KEcoLab is a project that allows you to measure energy consumption of your software through ci/cd pipeline using a remote lab.It also generates a detailed report which can further be used to document and review the energy consumed when using one’s software and to obtain Blue Angel eco certification.
The Lab computer on which the software runs for testing was migrated to Fedora 43 recently, which comes with Wayland by default. Writing Standard Usage Scenario scripts, which are needed to emulate user behavior, was previously done with xdotool, but that will not work on Wayland. My work so far has been to port the existing test scripts to a Wayland-compatible tool. For those who want to contribute test scripts to measure their own software , the current scripts can be taken as a reference. My next tasks are to prepare new test scripts to measure energy usage of Plasma Desktop Environmen itself.
In the first week I studied the Lab architecture and how testing of software is done using KEcoLab. The work done by past mentees as part of SOK and GSoC was very helpful for my research which you can read here , here and here. I also set up access to the lab computers through SSH. RDP access had some issues which were solved with the help of my mentors. To replicate the lab environment locally, I set up a Fedora 43 Virtual Machine so that I can test scripts under the same Wayland environment as the lab PC. I also documented and published a blog about the project and shared with my university community to promote the use of Free and Open Source Software and how it relates to sustainability.
I communicated with my mentors and other community members to decide the new wayland compatible tool. After evaluating different options, we decided to use:
A combination of tools was required to meet all our requirements. To help future contributors, I published my first blog on Planet KDE explaining how to set up and use ydotool and kdotool . I also imported the repositories into KDE Invent for long term compatibility and wrote setup scripts for easier installation and configuration. These tools did not work out of the box and I had to make some workarounds and setup before usage which i documented in the blog.
During these weeks, along with my mentors, I installed and set up the required tools on the Lab PC. I then ported the test scripts of Okular from xdotool to ydotool and kdotool and did testing on my local machine first. Currently, the CI/CD infrastructure through which these scripts run on the Lab PC is temporarily broken due to the migration to Fedora 43. Once these issues are fixed, we will test the new Wayland compatible scripts on the actual lab hardware and compare the results with previous measurements.
I will be working on measuring energy usage of Plasma Desktop Environment itself. It will be more challenging than measuring a normal software application because Plasma is not a single process. It is made up of multiple components such as KWin (compositor), plasmashell, background services, widgets, and system modules. All of these together form the desktop experience.
Unlike normal applications like Okular or Kate, Plasma is always running in the background. So we cannot simply “open” and “close” it like a normal app. Because of this, some changes may be required in the current way of testing using KEcoLab.
To properly design the Standard User Scenario (SUS) scripts for Plasma, I will discuss closely with my mentors and also seek feedback and suggestions from the Plasma community. Defining what should be considered a “standard” usage pattern will require careful discussion and community input.
It has been a very amazing journey till now. I learned how to make right choices of tools/software after properly understanding the requirements instead of directly starting implementation.
I’d like to take a moment to thank my mentors Aakarsh, Karanjot, and Joseph. I am also thankful to the KDE e.V. and the KDE community for supporting us new contributors in the incredible KDE project.
KEcoLab is hosted on Invent. Are you interested in contributing? You can join the Matrix channels Measurement Lab Development and KDE Eco and introduce yourself.
Thank you!
Welcome to a new issue of "This WeekMonth in KDE Apps"! Every week (or so) we cover as much as possible of what's happening in the world of KDE apps.
It's been a while since the last issue, so I'll try my best to summarize all the big things that happened recently.
A lot happened in Marknote. We released version 1.4.0 of Marknote, which contains a large number of bug fixes. It also includes a few new features. Siddharth Chopra implemented undo and redo in the sketch editor office/marknote MR #91 and Valentyn Bondarenko made it possible to drag and drop images inside Marknote office/marknote MR #90. Valentyn has also been busy fixing many bugs and improving the stability of Marknote.
In the development branch even more happened. Shubham Shinde added a note counter to the notebook sidebar indicating the number of notes in each notebook office/marknote MR #110. Additionally, Shubham implemented text search inside a note office/marknote MR #109; drag-and-drop support for moving notes between notebooks office/marknote MR #111; internal wiki links between notebooks office/marknote MR #115; a table of contents panel office/marknote MR #112; and a button to copy the whole note content office/marknote MR #108.
Valentyn Bondarenko further improved the drag-and-drop support for images, which now supports multiple images at once office/marknote MR #104; made image loading async office/marknote MR #99; ported some custom FormCardDelegates to the newer standardized delegates now available in Kirigami Addons office/marknote MR #144 office/marknote MR #122; added support for code blocks office/marknote MR #146 and block quotes office/marknote MR #142; significantly improved support for tables office/marknote MR #143; and delivered an even bigger list of bug fixes, code refactoring, and UI polish.
A new release should follow soon :)
Drawy saw a massive wave of improvements and new features this month. Prayag delivered a major UI overhaul that includes a new hamburger menu graphics/drawy MR #295; improved zoom and undo/redo controls graphics/drawy MR #193; and a more uniform appearance across the app. He also improved the saving mechanism to correctly remember the last used file graphics/drawy MR #345.
Laurent Montel was busy expanding the app's core capabilities, implementing a brand-new plugin system to make adding new tools much easier graphics/drawy MR #352; Laurent also added a color scheme menu to switch themes graphics/drawy MR #372, and introduced the ability to customize keyboard shortcuts.
Nikolay Kochulin greatly enhanced how you interact with content, adding support for styluses with erasers and the ability to export your finished canvas to SVG graphics/drawy MR #258; Nikolay also made bringing media into Drawy a breeze by adding support for copying and pasting items, pasting images directly graphics/drawy MR #285, and dragging and dropping content straight onto the canvas graphics/drawy MR #322.
Finally, Abdelhadi Wael polished the visual experience by making the canvas background automatically detect and respect the system's current light or dark mode theme graphics/drawy MR #380.
Jaimukund Bhan added a setting to open the last viewed page when reopening a document graphics/okular MR #1324.
Ajay Sharma made it possible to open embedded file attachments in Okular graphics/okular MR #1312.
Carl Schwan modernized some dialogs to be more convergent using Kirigami Addons' ConvergentContextMenu pim/itinerary MR #413.
As always, there were also improvements in terms of ticket support. Carl Schwan improved support for Hostel World, GetYourGuide, and FRS ferries. Volker Krause improved support for FCM flights and French TER. Tobias Fella added support for Gomus annual tickets.
Volker Krause also posted a blog post about all the other improvements in the Itinerary/Transitous ecosystem.
We removed support for Kolab. If you are using Kolab with KMail, you will need to reconfigure your account with a normal IMAP/DAV account pim/kdepim-runtime MR #154.
We also switched the default database backend to SQLite for new installations pim/akonadi MR #311.
Zhora Zmeikin fixed a crash when editing or creating a new incidence (25.12.3 - pim/merkuro MR #608).
Yuki Joou fixed various small issues in Merkuro Calendar (25.12.3 - pim/merkuro MR #610, pim/merkuro MR #611, pim/merkuro MR #609, pim/merkuro MR #579).
Carl Schwan added basic support for displaying travel reservations in the mail view pim/mimetreeparser MR #90.
Swastik Patel and Jean-Baptiste Mardelle added support for showing animated previews in the transition list (26.04.0 - multimedia/kdenlive MR #816).
Valentyn Bondarenko added support for the standard zoom-in and zoom-out shortcuts in Photos (26.04.0 - graphics/koko MR #267).
Bart De Vries refactored the sync engine to be a bit more efficient (26.04.0 - multimedia/kasts MR #315 multimedia/kasts MR #305).
Carl Schwan added a home and explore pages to Audiotube (multimedia/audiotube MR #179) and ported the convergent context menu to the standardized one in Kirigami Addons.
Leia uwu added a way to clear the search history (26.04.0 - utilities/kate MR #2044).
Akseli Lahtinen released Komodo 1.6.0 utilities/komodo MR #72. This release adds Markdown-style inline links, fixes some parsing issues, and removes the monospace font from tasks.
Micah Stanley added a lockscreen overlay for the timer utilities/kclock MR #244 and improved the existing one for the alarms utilities/kclock MR #243.
James Graham rewrote the text editor of NeoChat to be a powerful rich text editor (network/neochat MR #2488). James also marked threading as ready, and this feature is no longer hidden behind a feature flag (network/neochat MR #2671); improved the avatar settings (network/neochat MR #2727); and, as always, delivered a lot of polishing all around the place.
Joshua Goins improved the messaging around various encryption key options (network/neochat MR #2687).
Aleksander Szczygieł fixed replying to posts with multiple mentions (network/tokodon MR #796).
Andreas Cord-Landwehr introduced a common view for system and user unit logs (system/kjournald MR #79).
Carl Schwan released Kirigami Addons 1.12.0.
George Florea Bănuș added some missing description and trailing properties to a few of the FormCard delegate components (libraries/kirigami-addons MR #421, libraries/kirigami-addons MR #410). Carl Schwan made the configuration dialog modal (libraries/kirigami-addons MR #419). Hannah Kiekens fixed the templates for KAppTemplate (libraries/kirigami-addons MR #434). Volker Krause made the date and time picker locale-aware and fixed some issues with RTL layouts (libraries/kirigami-addons MR #431).
This blog only covers the tip of the iceberg! If you’re hungry for more, check out This Week in Plasma, which covers all the work being put into KDE's Plasma desktop environment every Saturday.
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.
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, keep KDE continue bringing Free Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
In my 5th week of Season of KDE, I have translated the Mankala Engine into Tamil. Things are a lot easier with KDE’s very own translation software called Lokalize.
Here is a guide to get you started with translation in KDE. I had installed KDE Lokalize in my Plasma desktop using:
sebas
@neo-0007:matrix.org$ sudo apt install localize
My project '''Mankala Engine''' already had translation files under the po folder; I had taken them as a reference for the strings that were to be translated. If the project being translated doesn’t have any prior translation, one can install the language template and start the translation from scratch.
svn co svn://anonsvn.kde.org/home/kde/branches/stable/l10n-kf5/{your-language}
svn co svn://anonsvn.kde.org/home/kde/branches/stable/l10n-kf5/templates
I copied the string from the previous translations of my project and changed the text to my intended language of Tamil. After this, we go to Lokalize and configure the settings.
To setup your project, go to the project folder and select your po files and edit them in Lokalize.
At the beginning of the files, we have some metadata giving the details about the files, their editor, the dates, and the version. After that, we have the lines for translation, followed by the English strings and then the translated language.
English
#: src/variantdescriptions.h:25
#, kde-format
msgid ""
"Bohnenspiel is played on a board with 2 rows, each with 6 holes, and 2 end-"
"holes, called stores. Each player owns the store to their right hand and "
"controls the holes on their side of the board.\n"
Tamil
msgstr ""
"போனென்ஸ்பீல், 2 வரிசைகளைக் கொண்ட பலகையில் விளையாடப்படுகிறது. ஒவ்வொரு வரிசையிலும் 6 குழிகள் "
"மற்றும் 2 இறுதிக்குழிகள் இருக்கும். ஒவ்வொரு ஆட்டக்காரரும் தமது வலதுபுறமுள்ள இறுதிக்குழியைச் சொந்தமாகக் "
"கொண்டுள்ளனர். பலகையில் தமது பக்கத்திலுள்ள குழிகளை அவர்கள் கட்டுப்படுத்துவார்கள்.\n"
After all the files are created, we should send them to the language moderators or else contact the mailing list of that language and ask for guidance on how these translations can be uploaded. To get involved and be updated with the team, one can join KDE Translation’s matrix channel:
#kde-i18n:kde.org
I was asked a good question: What are these things? What are the differences? I will try to explain what they are in this post, in bit less technical manner.
I will keep some of the parts bit short here, since I am not 100% knowledgeable about everything, and I rather people read documentation about it instead of relying my blogpost. :) But here's the basics of it.
It's infodump time.
QtWidgets is the "older" way of writing Qt applications. It's mostly C++ and sometimes quite difficult to work with. It's not very flexible.
More information in here:
QStyle is the class for making UI elements that follow the style given for the application. Instead of hardcoding all the styles, we use QStyle methods for writing things. This is what I was talking about in my previous post.
More information in here:
Breeze is our current style/theme. It's what defines how things should look like. Sometimes when we say "Breeze" in QtWidgets context, it means the QStyle of it, since we do not have other name for it.
Repository: https://invent.kde.org/plasma/breeze/
QtQuick is the modern way of writing Qt applications. In QtQuick, we use QML which is a declarative language for writing the UI components and such. Then we usually have C++ code running the backend for the application, such as handling data.
More information in here:
qqc2-desktop-style is the Breeze style for QtQuick applications. It tells QtQuick applications what certain elements should look like.
Repository: https://invent.kde.org/frameworks/qqc2-desktop-style/
Kirigami is a set of shared components and items we can utilize in our QtQuick applications. Instead of rewriting similar items every time for new apps, we use Kirigami for many things. We call them Kirigami applications since we rely on it quite a lot.
These two are a bit intermixed. For example, Kirigami provides convenient size units
we have agreed on together, such as Kirigami.Units.smallSpacing.
We then use these units in the qqc2-desktop-style, but in other applications as well: Both for basic components that QtQuick provides us which are then styled by qqc2-desktop-style, but also for any custom components one may need to write for an application, if Kirigami does not provide such.
I wish the two weren't so tightly coupled but there's probably a reason for that, that has been decided before my time. (Or it just happened as things tend to go.)
This is how the current stack looks like.
As you can see from the diagram, the styles must be kept in sync by hand. We have to go over each change and somehow sync them.
Not all things have to be kept in sync. This whole thing is rather.. Primitive. Some parts come from QStyle, some parts are handcrafted, some metrics and spacings can get out of sync when changed.. But for purposes of "regular person reading this" they need to be carefully modified by developers to make sure everything looks consistent.
Even bigger problem is that these two (QtWidgets and QtQuick) can behave very differently, causing a lot of inconsistent look and behavior!
But this is why Union was made.
Union is our own "style engine" on top of these two. Instead of having to keep two completely different stacks in sync, we feed Union one single source of truth in form of CSS files, and it then chews the data out to both QtQuick and QtWidgets apps, making sure the both look as close to each other as possible!
I think it's entirely possible to create other outputs for it too, such as GTK style. Our ideal goal with Union is to have it feed style information even across toolkits eventually, but first we just aim for these two! :)
And yes the CSS style files are completely customizable by users! But note that the CSS is not 1-to-1 something one would use to write for web platforms!
Repository: https://invent.kde.org/plasma/union/
Plasma styles are their own thing, which are made entirely out of SVG files.
I do not know if Union will have an output for that as well, or do we just use the qqc2-desktop-style directly in our Plasma stack (panels, widgets) so we can deprecate the SVG stack. Nothing has been decided in this front yet as far as I know.
Yeah that's a lot of stuff. Over +20 years of KDE we have accumulated so many different ways of doing things, so of course things will get out of sync.
Union will be a big step in resolving the inconsistencies and allowing users easily to customize their desktop with CSS files, instead of having to edit two or three different styles for different engines and then having to compile them all and load them over the defaults.
I hope this post helps open up this a bit. Please see the previous post as well, if you're interested in this work: https://akselmo.dev/posts/breeze-and-union-preparing/