A new version of Plasma Camera and Plasma Settings have been released

We have a new release of Plasma Camera and Plasma Settings!

Plasma Camera changes:

• Timestamp EXIF data is now added to photos (MR)
• Fix log of libcamera property names (MR)
• Don't default to first pixel format by libcamera (MR)
• Selectable filename pattern and output path (MR)
• New translations

Plasma Settings gained the ability to show all settings modules (for all platforms, such as desktop) under a toggle. It now supports the ability to show an "Apply" button for settings modules that do not want settings to save automatically. The header being misaligned on category pages is now fixed.

• Use custom page stack (MR)
• Have larger delegates on mobile (MR)

Visit /info/independent-releases-25-11 for the tarballs.

Please note: most Plasma Mobile software is now shipped under the Plasma or KDE Gear release cycles.

This post is about how we met KITE‘s team and visited some schools during our family visit trip in Kerala. For those who don’t know, KITE stands for “Kerala Infrastructure and Technology for Education”; they are in charge among other things of the GNU/Linux distribution for Kerala schools and training teachers to use it. GCompris is used a lot there, as it is the main software used in their ICT curriculum textbooks for classes I to IV. The widespread and official use of Free Software in Kerala schools really is an awesome model.

The connection with KITE happened thanks to Aiswarya’s sister’s husband, Karunraj K. He recently got hired by KITE, so even before going we knew we would try to meet some of their team. During some discussions with him, I understood they did some small customization to their GCompris package to fit their specific needs, but most importantly they added translations and voices for Tamil and Kannada languages. They need those with Malayalam and English as the Kerala state shares borders with Karnataka and Tamil Nadu, so they have many pupils in border areas speaking those languages. Of course my first reaction was to look for their sources to upstream those translations and voice files missing from our GCompris package. Sadly, after searching through their distribution and online, the sources were nowhere to be found, the only way to get them was to ask for it. This was one more motivation to get in touch with their team.

Karunraj invited us to visit KITE’s office of Kannur district, where we were warmly greeted by the local team. We met Surendran Aduthila (head of the local team), with whom we could start discussing several topics, including how to get their translation files. He made some calls to investigate the issue, and soon enough we got in contact with KITE’s CEO Anvar Sadath who invited us for a meeting at KITE’s headquarters in Trivandrum a few days later.

For this meeting, they also invited several team members from various districts involved in their GNU/Linux distribution and software development projects. First, I explained how important it is to publish their sources, especially for customized Free Software packages, ideally using both some public git repositories and the standard way to publish source packages for debian-based distributions. Using public git repositories could also help them to organize their work, and allow some external contributions. It seems they understood it clearly, and decided to follow this path.

I showed them for reference the French education forge portal, which includes a dedicated gitlab instance for teachers to host and share their projects (mostly software and tutorials), and a dedicated instance of matrix chat server for internal communications. They looked very interested, and discussed about how they could do something similar and reuse some of the educational content available from this forge. I also showed them the work from Primtux, the French GNU/Linux distribution for primary schools, which has a lot in common with their own distribution.

We discussed about how we could collaborate, like how it would be better for their translation team to work directly with us, or how we could develop some new activities together. We also discussed especially about how GCompris is used for children with special needs, and how the coming “GCompris-teachers” (a new side application we are working on, allowing teachers to create customized datasets and analyze pupils results) could be useful for this use case. And I spent some time with the head of their GNU/Linux distribution project, Abdul Hakeem, giving various tips, especially to improve their customized packaging of GCompris. And of course I could get those wanted translation and voice files from his computer, with all the necessary info to add them to our repositories

Also, I gave them some tips about how to turn some of their in-house software into proper Free Software projects, as it is something they were interested to do but were missing some insights about how to proceed.

Finally, Aiswarya shared her experience with Kerala’s Free Software based education and how it helped her to build her career. Also, she helped me a lot during the meeting when translating some things to and from Malayalam was needed.

Globally it was a very tight-scheduled session, but I think we could cover all the most important topics. I’m very happy of this meeting, and looking forward to future collaborations.

It was covered by the press, and an article was published in The Hindu newspaper the next day (original article behind a paywall).

Two days later, I was invited to Kannur district’s “IT MELA” (IT Fair), a yearly school event with some competitions on IT topics. On this day was the digital painting contest, which I was very interested to attend: pupils had one hour to paint an image on a given subject, using either Krita or GIMP and a mouse(!). Digital painting without a graphic tablet is super difficult, so I was very impressed to see what those pupils could achieve this way. There was also a Malayalam typing contest (using a special in-house software to track typing), and a web design contest. Again I was super impressed to see what some pupils could produce in one hour with pure HTML+CSS (no frameworks allowed).

This time again my visit was covered by the press, and the next day almost all local Malayalam newspapers had an article about it.

Finally, I had the chance to visit Kuttiattoor’s primary school where I made a little speech to pupils about the importance of Free Software in education. The teachers showed me the ICT “PLAYBOX” textbooks, and gave me an English hard copy of the book for class I.

I’d like to thank again all those who were involved in the meeting organization, the IT MELA visit and the school visit. And thanks a lot to our family in India for the support!

Introduction

I finally have a good desktop computer for streaming, and I have been testing streaming KDE documentation work on Twitch (with occasional Silksong speedrunning) while using a bunny avatar.

It’s time to announce it: I now stream mondays to fridays at 8 PM UTC (5 PM UTC-3 / Brasilia time) on twitch.tv/herzenschein. Come and say hi, ask about KDE stuff there!

This year we again participated in Google Summer of Code and we had 12 successful projects.

Akonadi/Merkuro

Merkuro is a modern groupware solution and uses Akonadi as backend. This year we had two mentees working on Akonadi, and in particular on how the resources and their configuration dialogs interact with Merkuro on mobile.

• Pablo Ariño worked on improving the memory usage of the Akonadi agents and resources. He did that by ensuring the configuration dialogs of the agents is moved to a separate plugin which is then loaded on demand by the application, instead of having the agents being GUI processes which handle their configuration dialogs directly.

• Shubham Shinde worked on the UI side of things by writing the infrastructure for config dialogs to be written in QML. This is extremely important to get mobile optimized dialogs on mobile and is also a good occasion to clean the dialog code up. All the major code changes can be found on the following merge requests: Akonadi and KDE PIM Runtime.

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:

• Ajay Chauhan improved the supported for timeline markers in Kdenlive. Previously, we only supported single point markers, which can be used to mark a specific point in time. Ajay added support for duration-based markers that define a clear start and end time.

ISO Image Writer

• Akki Singh worked on a port of ISO Image Writer from QtWidgets to Kirigami. Akki also added a bunch of features to the app such as allowing you to download ISO images for some of the more popular KDE distributions, or from an URL automatically.

OSS-Fuzz Integration

OSS-Fuzz is a program by Google were our code is fuzzed by them in search for vulnerabilities.

• Azhar Momin focused his work on improving the OSS-Fuzz integration in the KDE libraries. Azhar moved our configuration to our repos, making them easier to maintain, and the fuzzer now scans many thumbnails formats (e.g. poppler, syntax highligted text, krita archives, mobipocket and many more). He also fixed some of the bugs detected by the fuzzer like a memory leak in the blender thumbnail extractor.

KDE Linux / Karton

• Derek Lin worked on the new virtual machine manager from KDE named Karton. He implemented, among other things, keyboard input support, basic SPICE viewer (non hardware accelerated) and audio support.

Since the end of GSoC, he has also added hardware acceleration to the playback and you can find more information about that on his blog.

GCompris

GCompris is KDE's educational suite for children learning at home or school. It comes with around 200 activities to learn while having fun. The next iteration of the suite adds a teacher panel to follow the progress of children and provide customised exercises to focus on specific topics.

• Ashutosh Singh worked on adding new dataset editor for an in-progress GCompris admin software for teachers. This feature will allow teachers to send customized exercises to children and Ashutosh has added multiple editors: Learn decimals activities, Graduated lines activities and Fractions activities. These activities have been chosen as they are the ones most used at schools.

Mankala

The Mankala engine is a project that was started during last year's GSoC. The project is still in review and is pending integration into KDE.

• Srisharan V S worked on a cross platform GUI for MankalaEngine. On the desktop, it is possible to play Mankala games against a remote opponent provided both players have XMPP accounts. The GUI uses QXmpp for networking. The GUI works on both desktop and mobile, though network play is not yet available on mobile as support for this needs to be re-enabled in the QXmpp library.

Krita

Krita is KDE's free and open source cross-platform application for creating digital art files from scratch.

• Ross Rosales worked on improving Krita's usability by adding a UI to display common selection actions after selecting a layer. More details on Ross journey are available on his blog. The feature request was opened in 2022 and will be available in the upcoming 5.3 version of Krita.

Cantor

Cantor is a powerful mathematical and statistical computing front-end within the KDE ecosystem. Two contributors worked on improving Cantor this year:

• ZhengJiahong added features to improve Python support. Once the merge request is finished, users will be able to switch Python virtual environments to improve the user experience.

• Lv Haonan worked on integrating KTextEditor in Cantor to replace the custom made spreadsheets. This has several advantages: the current spreadsheets lack some features (auto-indent, code completion, spell checks...), they require extra maintenance from developers where a better solution already exists within KDE, and it will bring consistency between the different backend editors.

Mentorship Portal

One of the current KDE Goals is to improve the long term sustainability of KDE by recruiting and keeping more newcomers.

• Anish Tak worked on extending the current mentorship website to make it cleaner and with more information for newcomers.

KWin

KWin is an easy to use, but flexible, window manager and compositor for the KDE Plasma desktop. It controls how windows are drawn, moved, and displayed, handles input (keyboard, mouse, touch, etc.).

Yelsin 'Yorisoft' Sepulveda worked on adding game controller input support to KWin. By using input libraries like libevdev he was able to add a option in Plasma System Settings that enables awareness of game controllers and detects their input. This was essential for adding features, such as:

• Mapping Game Controller inputs to Keyboard and Mouse
• Navigating Plasma Desktop with Game Controllers
• Preventing Sleep/Suspend when gaming with controller and leaving keyboard/mouse idle

Next Steps

The 2025 GSoC period is finally over for KDE. A big thank you to all the mentors and contributors who have participated in GSoC! We look forward to your continuing participation in free and open source software communities and in contributing to KDE.

In this blog post, we’re having a look at how we added support for custom server certificates to Qt WebEngine. This way an application can talk to a server using a self-signed TLS certificate without adding it to the system-wide certificate store.

Continue reading Qt WebEngine Custom Server Certificates at basysKom GmbH.

Zerodha created FLOSS/fund to support free and open source software projects, and one of the projects FLOSS/fund supports is Krita! We were part of the first tranche: FLOSS/fund first tranche: $325k to 9 projects.

The $50,000 the Krita Foundation has received has been earmarked for improving Krita on Android. We've already started working on the project, in cooperation with Drawpile.

Thank you, FLOSS/fund!

Last week I attended the 2025 edition of the CAP Implementation Workshop in Rome, Italy, a three day conference around the use of the CAP protocol for emergency warnings.

Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) is an OASIS standard for exchanging emergency alerts between altering authorities (meteorological or hydrological institutes, civil protection authorities, etc.) and alert dissemination channels (mobile network operators, media broadcast, sirens, etc.).

As that’s very widely used all over the world, including for global aggregation of alerts (e.g. by Google or by us), there’s the yearly CAP Implementation Workshop as a forum for exchange between all those stakeholders. Besides alerting authorities and aggregators/distributors this also included NGOs helping with and pushing for setting up early warning systems for weather, climate or geophysical emergencies as well as equipment vendors and researchers.

Alert Aggregators

With the FOSS Public Alert Server we have implemented and operate a CAP alert aggregation service, which receives alerts from more than 200 sources.

This means we get to deal with alert feeds becoming temporarily unavailable, feeds changing their URL, different interpretations of the data formats and other interesting issues in the alert data. All of that needs continuous monitoring, investigating and working on resolving issues with the alert publishers or, when that’s not possible, implementing technical workarounds.

We aren’t facing this alone though, it’s the same for all aggregators. In order to at least avoid duplicated efforts there’s now plans to improve collaboration and establish a communication channel between the aggregators.

Perfectly timed we discovered a new issue during the conference which was triggering problems on our server as well, caused by an alert feed reusing identifiers that were meant to be permanently unique.

Talk

Our talk on Thurday afternoon mainly focused on our observations and experiences with data availability, data quality (particularly from an end-user perspective) and CAP standard ambiguities (slides).

This includes:

• Alert feeds being inaccessible for automatic access due to captchas, geo-blocking, paywalls or outright denial of access.
• Alert feeds preventing redistribution with license or copyright restrictions.
• Alert feeds where the corresponding geocode geometry isn’t published.
• Excessively detailed geometry and confusion between affected and to be alerted areas.
• Different ways of implementing multi-lingual alerts.

The most important user-facing issue however is probably alerts stopping at borders while the corresponding emergencies or disasters don’t, and we weren’t the only ones pointing that out. That’s not a technical issue though, but a very political one.

Alerting Authorities

The alerting authorities on the other hand have a very different view on this, being legally prohibited from alerting outside of their corresponding jurisdiction. This is also part of the reason for excessively detailed area geometries and additional technical complexity like device-based geofencing for more precise cell broadcast targeting, ie. things I’d even consider counter-productive in many cases.

It’s not like this problem isn’t recognized by some alerting authorities at least, there’s e.g. some promising collaboration for cross-border alerting between Belgium, Germany and the Netherlands.

There were other topics we were able to discuss with representatives from alert producers as well, such as:

• Obtaining access to feeds we currently don’t have, such as non-weather alerts in Belgium or volcano warnings in Iceland.
• Finally resolved an issue with wrong categories on non-weather alerts in Germany.
• Meteoalarm’s upcoming rollout of ETL category codes, avoiding us having to deal with custom CAP extensions.

Standards and common practices

I had so far underestimated how much the Common Policies and Practices document is relied upon to clarify room for interpretation and corner cases of the CAP standard, such as:

• Polygon winding order and thus how to deal with geometry crossing the anti-meridian.
• 0-radius circles.
• Alert content licensing.
• Category and ETL event code translations.

Those are things we had encountered as well, so this helps. However, since those are merely common practices and not requirements of the standard, we can’t rely on this and thus it’s not a viable solution for the anti-meridian crossing geometry problem at least, as that remains ambiguous.

The other aspect that still needs a proper solution (which is in the works) is the ETL versioning issue, that I at least only realized to the full extent while discussing this at the conference: There’s a draft version with completely different meanings of the event codes and which due to a misunderstanding appears to have the higher version number.

To make matters worse, the key for those values is the same (OET:v1.0), so they aren’t distinguishable at all, which practically means we can’t distinguish whether a warning is about a dust storm or a drug supply issue, nor whether it’s about the fall of snow or space debris, for example. That currently renders all existing ETL codes practically useless unfortunately.

Outlook

It’s always good to meet everyone involved in person, and this helped a lot with getting a better understanding of the views and priorities of different stakeholders as well as with clarifying a number of details of CAP usage. Let’s see what we can get going in terms of closer collaborations with other aggregators here.

KWin, our fantastic and flexible window manager and Wayland compositor, can not just drive your session but also run in windowed mode for development purposes:

$ dbus-run-session kwin_wayland --exit-with-session kwrite

Et voila, a windowed KWin appears, running KWrite. The separate DBus session is important so it doesn’t mess with your running session, notably trying to take over your global shortcuts.

Speaking of shortcuts: when grabbing the mouse (press right Ctrl), it now blocks the session’s global shortcuts. This makes it behave more like a full “input grab” on X11. As a result, you can now use global shortcuts in your windowed KWin, for instance to more easily trigger the Overview effect (Meta+W), if you want to work on it without affecting your running session.

KWin also includes a debug console that lets you inspect open windows, see input devices and events, the state of the clipboard, load and unload desktop effects, and so on. We particularly moved developer-facing desktop effects (like the “Compositing” indicator or FPS effect that isn’t a benchmark) from System Settings to the debug console. You can access it by typing “kwin” in KRunner and selecting “KWin Debug Console”. Mind that it’s a developer tool, so function definitely outdoes form.

After a recent bug report about a blurry window icon in the Alt+Tab window switcher, I noticed that we didn’t include any information about the window’s icon. It would have been helpful to see the icon name used, if any, and what sizes were available. In fact, there were a couple of window properties using custom types that the debug console didn’t know how to visualize. I therefore added a couple of custom converters to the tree model:

• QIcon, (e.g. window icon): Display the icon, its name, and list of available sizes. Generally, for properties of Window type, such as dialog parent (transient parent), also show the window icon
• KWin::Output: the name of the output, its geometry, and scale factor
• KWin::Tile (quick tile and custom tiles): its geometry, shape (e.g. floating) and/or quick tile mode (e.g. left/right)
• KWin::VirtualDesktop: its name
• QPalette (e.g. window color scheme): show a 2×2 grid of important theme colors, similar to the application color scheme selector we have in many apps

With that, the list of windows becomes much more useful and nicer looking. For those who prefer a command-line tool, David Redondo added a little kwindowprop application similar to xwininfo that prints information about a given window.

I’m pleased to share that my career transition has been successful! I’ve joined our local county assessor’s office, beginning a new path in property assessment for taxation and valuation. While the compensation is modest, it offers the stability I was looking for.

My new schedule consists of four 10-hour days with an hour commute each way, which means Monday through Thursday will be largely devoted to work and travel. However, I’ll have Fridays available for open source contributions once I’ve completed my existing website maintenance commitments.

Open Source Priorities

Going forward, my contribution focus will be:

1. Ubuntu Community Council
2. Kubuntu/Debian
3. Snap packages (as time permits)

Regarding the snap packages: my earlier hope of transitioning them to Carl hasn’t worked out as planned. He’s taken on maintaining KDE Neon single-handedly, and understandably, adding snap maintenance on top of that proved unfeasible. I’ll do what I can to help when time allows.

Looking for Contributors

If you’re interested in contributing to Kubuntu or helping with snap packages, I’d love to hear from you! Feel free to reach out—community involvement is what makes these projects thrive.

Thanks for your patience and understanding as I navigate this transition.

For a while now, probably two years, I wanted to have support for high-contrast colorschemes in KDE Plasma.

Technically, this was already doable, by just modifying your colorscheme to such colors. However one thing was lacking: Outlines were calculated automagically with hardcoded value.

Well, no more! Now you can set your own frame contrast value! And you may ask "Why not change the color completely?" which is a good question and I will answer that later.

This feature will be in Plasma 6.6. Hopefully. Or if you use KDE Linux you can already try it out. :)

The settings

This is how the settings will look like.

This setting used to be a slider.. And guess what, it did nothing in Breeze style. It was leftover from Oxygen times. Do not worry though if you use Oxygen style, the slider value is just percentage now and it will be converted to the value Oxygen uses.

Desktop examples

Some examples how it might look like in desktop setting.

All items are updated to follow this:

• QtQuick windows (qqc2-desktop-style)
• QtWidgets style and decorations (Breeze)
• Plasma SVG files (Anything using class: ColorScheme-Frame )

There's still some bugs with panels not always updating immediately, though we're working on fixing them.

Why not change the whole color?

Currently across all of our apps and styles, we do the following:

• Take background color and foreground color
• Mix them with previously hardcoded frameContrast value, which was 0.2
• Use that as the color for all the frames

If we wanted this to be recolorable completely, we would have to go through every single occurence of this color mixing. Most apps luckily rely on the styling, but some may have custom things, for example custom QtQuick Controls that are doing this manually, using the Kirigami.Theme.frameContrast value.

I think we most likely would have gotten away with it for most apps, but then rest of them would look wrong, and some of them may not even be KDE apps but are using Kirigami.. So we would need to tell everyone to do this update, or risk things look broken.

This was the compromise solution: Allow users to change the Kirigami.Theme.frameContrast value to whatever they wish, even turn it off. :)

A lot of work

This was a lot of work. In total, it was 8 merge requests that had to work together and be merged in correct order, etc..

And this is why modifying Breeze in our current stack is so difficult. You have to do many many changes across the platform.. And make sure that nothing breaks in the process!

My first draft: Use kdeglobals

First step for me was trying to make this a global configuration value only in ~/.config/kdeglobals, which every platform would watch for modifications for this particular value.

It worked fine, but it was quite messy, and I had to make sure all the default values across the stack would be synced. That is annoying for anyone who wants to maybe modify the default value later. On top of that, I felt like different platforms constantly watching the config file for changes just was not a good idea..

Second draft: Use KColorScheme

After chatting with people, we decided it would be best to just add this as a new value into our KColorScheme library. Instead of all the platforms looking for this configuration change, only the KColorScheme library did it.

This allowed me to simplify the implementation significantly.

Summary of changes

All in all, I had to do the following:

• Update KColorScheme to load this value from kdeglobals/current colorscheme | Link
• Update the settings for plasma-workspace to allow users to change this value | Link
• Update Breeze window decorations and QtWidgets style to use this value | Link
• Update Kirigami platformtheme to notify any platforms that use it about the changes | Link
• Update the libplasma library to actually listen for changes to this contrast value and change accordingly | Link
• Update qqc2-desktop-style (QtQuick style) to listen for changes to this value and change accordingly | Link
• Update KSvg library so that the Plasma styles can now use ColorScheme-Frame class to load correct color | Link
• Update kde-gtk-config to make sure the Breeze GTK theme also updates correctly when value is changed | Link

Yeah. It's a lot. This took me about a week to work on.

A week to make one number user modifiable.

Now imagine how long it would have taken if I had made the whole color modifiable!

And remember, there's tons of legacy code here which rely on each other, so I could not take shortcuts at places without possibly breaking everything.

And that's why Union was born

This is why Union is such an important project when it comes to styling, and which is why we are most likely NOT going to modify Breeze much further, aside maintenance: A lot of work for even small changes.

Union lets us have a "single source of truth." We can change things only in one place and (hopefully) see the visuals update everywhere, be it QtQuick, QtWidgets or Plasma style or whatever we decide to support! Which means easier to work on styling and iterate on it, designers have easier time collaborating because changes do not take days.. Etc.

So I am putting more effort in Union from now on.

Summary and future

I felt this was important change due to accessibility reasons, so I did it. And I am happy that I did, even if it was tons of work. (And there's more left with bugfixing lol.) This will also help alleviate issues where people feel like our apps are too "framey." You can now turn them off (well, you can make their color same as the background color) by setting the contrast to 0%. I must warn you that setting the value to 0% will probably look broken at some places, so we will probably have to add a warning to the color editor that "hey this is not optimal but you can do it lol."

In short-term future, I want this to be tied to the desktop portal interface for high-contrast accessibility preference: When user has this enabled, be they on Plasma desktop or not, the applications will maximize this frame contrast value automatically.

And then, there's bug hunting and finding out any weird inconsistencies. If you spot any, please report them to https://bugs.kde.org!

In long-term, this whole color thing will be rewritten to something much more robust, shinier, fancier and it will work with Union and everything is nice and beautiful. At least, that's what I hope.

I hope people will like this feature, especially those who need high-contrast colors.

Thanks for reading.