Here are the new modules available in the Plasma 6.5 beta:

• knighttime

Some important features and changes included in 6.5 beta are highlighted on KDE community wiki page.

View full changelog

18 Sep 2025 12:00am GMT

This year's Akademy took place in Berlin, Germany. The city's modernity and avant-garde counterculture atmosphere fit very well with the current mood in the KDE community. As volunteer developers push forward with technologies that even multi-billion dollar corporations struggle to imitate, there is a general feeling that something great is on the horizon. With major migrations and potential adoptions in public administrations, not to mention KDE technologies making their way into all kinds of devices, it seems that we are finally on the verge of going mainstream and bringing FLOSS to the general public.

Bearing all this in mind, the community gathered at Berlin's Technische Universität for an intense week of KDE-related activities.

Saturday, 6 September 2025

On Saturday morning, and as is traditional, Aleix Pol, President of KDE e.V., kicked proceedings off at 9:30 sharp. Aleix told us about what we should expect, reminded us about accreditations and lanyards. He also told us about the where the talks, BoFs, coffee breaks and sponsor booths were for when we needed a break.

And with that we were off!

In our first keynote, Alexander Rosenthal, project leader at DigitalHub.SH in the northern German state of Schleswig-Holstein, explained the exciting migration to Free Software going on in the region.

The focus was mainly on digital sovereignty and how public administrations should look to FLOSS to recover ownership of their infrastructures, devices and data, but the bit that drew the loudest applause was when Alexander mentioned that Plasma was the front-runner to power the institutional desktops in the region.

After the coffee break, David Edmundson talked about Plasma's reputation, how several mistakes had marked it for a long time, how we have overcome the bad press and what we can do to move forward and avoid the same pitfalls again.

In room 2, Karanjot Singh told us about KEcoLab, an automation tool for energy consumption measurements that allows KDE developers to remotely measure the energy consumption of their KDE software through GitLab CI/CD.

This means that Instead of obtaining measurements manually and in person in a lab such as the one at KDAB, Berlin, KDE developers can trigger the process through CI/CD, wherever they are. This enables developers to effortlessly assess their software's energy consumption when merging new code into the codebase.

After that, and back in room 1, Andy Betts presented the latest in the design goals presented for the first time at last year's Akademy. Andy provided a list of all the updates and implementations including a review on variable availability for designers and developers.

Meanwhile, in room 2, everyone was excitedly listening to Harald Sitter release the first alpha version of KDE Linux. Based on an idea launched back during Akademy 2024, KDE's reference distro for KDE technologies is now in a good enough state for it to be easily tested.

A little after 2 pm, Bettina Louis, Carolina Silva Rode, Joseph De Veaugh-Geiss, and Nicole Teale took to the stage in room 1 to tell us about how the End of 10 campaign is going. The answer was "very well". Designed by the KDE Eco team to try and curb the environmental disaster that Microsoft's end of support for Windows 10 will entail, the campaign encourages users not to ditch their older machines that do not support Windows 11, and do a real upgrade and install Linux instead.

The campaign caught the FLOSS community's imagination and has sparked installfests, inspired news stories, and revitalised repair cafés all over the world.

At the same time in room 2, Cristián Maureira-Fredes from The Qt Company told us about how bindings to newer languages, like Qt for Python have been around to open the doors to new generations of developers, and how one of the Qt's goals was to find ways of unlocking their framework's features for even more programming languages without the need to rely on bindings or learning C++.

At 15:35 we had the traditional Report of the Board in room 1. KDE e.V. board members Adriaan De Groot, Aleix Pol González, Eike Hein, Lydia Pintscher and Nate Graham talked about the work of the organization over the past year and what is coming next.

This session was followed by the annual report of the Working Groups, led by Lydia Pintscher. The Working Groups help the KDE Community in various areas such as fundraising, community management and running our infrastructure.

The third session in this vein was the KDE Goals - One year recap. Farid Abdelnour, Nicolas Fella, Jakob Petsovits, Gernot Schiller and Paul Brown talked about how the KDE goals that were set at Akademy 2024 were going one year on.

Meanwhile, in room 2, Arjen Hiemstra was discussing buttons, sidebars and other graphical elements and how they get rendered in KDE applications during his talk on the Union styling system. Arjen introduced Union at Akademy 2024 and the project aims to create a styling engine that unifies the various styling methods used in KDE. Arjen covered the progress made to achieve this goal and some of the new major features that have been developed, the state of adopting Union within KDE and some plans for the future.

Arjen was followed by Kevin Ottens, who talked about the progress made in the "KDE Neon Core" project, and effort to bring Plasma to Ubuntu Core.

And then Alexandra Betouni took to the stage and talked of her real-life experience trying to claim a space in the male-dominated tech industry.

At 18:00, Nicolas Fella was looking at KDE Frameworks' bindings to other languages (apart from C++), such as Python and Rust. Nicolas explained why this was important, how the binding generation worked under the hood and how they can be used in applications

In room 1, lightning talks, talks that last between 5 and 10 minutes, were kicking off, opening with Emilia Valkonen-Damjanovic, who introduced attendees to Qt Academy and the future plans for an official Qt developer certifications.

She was followed by Marco Martin, who tackled the controversial idea of retiring KWallet, a venerable app that needs to be superseded by a more modern approach to password safety.

Then Volker Krause talked about how to implement emergency and weather alerts into free software systems. Interestingly Volker's implementation in kpublicalerts was put to the test during the BoF when the citizens of Berlin received an alert regarding bad weather. Ultimately, the emergency alert system will be built into Plasma/Plasma Mobile itself, as it should not have to rely on an external app.

Finally Alexander Lohnau gave us an overview of Clazy, KDE's static code analyzer for Qt and C++, and how it can boost developers' workflow, helping them write cleaner, faster, and more reliable code.

Sunday, 7 September 2025

The first session on Sunday started at 10:00 and featured Paloma Oliveira from the Sovereign Tech Agency who spoke about how KDE could become more diverse, not by implementing rigid rules, but with "gentle enforcement", by establishing communication patterns, governance models, and accountability mechanisms that help communities grow in more just and inclusive directions.

After a quick break, we were back in room 1 with Akseli Lahtinen, who spoke from the heart of his experience on how he had been badmouthed, harassed and received hate mail just for implementing features or trying to improve KDE's UIs, and how he had handled it.

In room 2, Sune Stolborg Vuorela told us about CppCheck, a static code analyzer that can be integrated into KDE's CI workflow on invent, and how to get properly started with it.

After lunch, Akademy participants posed for the Akademy 2025 group photo and then went on to listen to David Edmundson, who explained that, while attracting contributors to project is relatively simple, recruiting maintainers is less so. He then gave advice on how to do just that.

At the same time, Aleix Pol was in room 2 talking about Flatpak and dished out advice on how to make Flatpak an actual environment where applications are developed.

Later, in room 1, Till Adam, founder of KDAB, tackled the thorny subject of FLOSS and business. Drawing from his own experience, Till expounded on the dos and don'ts of growing an enterprise from community roots.

Another interesting business-related talk by Patrick Fitzgerald followed. Patrick explained strategies for massive migrations from Windows to Linux, the potential pitfalls migrators face, and how to come out on top in the end.

In room 2, Ulf Hermann covered the new technologies coming to Qt 6.10 that allow developers to expose data to QML.

This was followed up by Nicolas Fella, who explained how developers can leverage the new QDoc system to generate better documentation for their projects.

Back in room 1, Nate Graham was telling us how, even though the world is a mess right now, that same chaos opened up opportunities for projects like KDE and how the community could take advantage of them.

In room 2, Neal Gompa presented a brief history of Fedora KDE Plasma Desktop Edition, success story of how community pressed for a distro to become a recognized flagship offering, and what happens next.

Then, artist and developer Joshus Goins looked at the steps taken in Plasma 6 to make KDE's desktop artist friendly, and how things will go from here on onwards.

At 17:15, lightning talks were starting up again in room 1, and Nicolas Fella kicked them off explaining the theory and practice of effective intra-team communication.

David Edmundson followed, continuing with the theme of communication, and told us what makes an effective commit message.

Bhushan Shah was up next with a talk about the state of power management in Plasma Mobile.

And finally, Jean-Baptiste Mardelle told us about Kdenlive's fundraising efforts and plans, where the money goes, and what they intend to fund next.

Then it was turn for the sponsor's talks and representatives from The Qt Group, KDAB, openSUSE, and Enioka Haute Couture took to the stage to tell attendees about their companies and how they are involved in KDE.

Aleix Pol stood in for Canonical, as the rep who was supposed to be at the event was sick and could not make it.

The last on-site of the day was the KDE Award ceremony. Vlad Zahorodnii and Xaver Hugl were awarded for their work on KWin and Wayland. Then Alexander Lohnau received an award for his work on Frameworks, Clazy and Krunner. Allen Winter was presented for an award in absentia for his work on KDE PIM and many years of contributions to other projects.

Finally, Kieryn Darkwater received an award in the name of all the Akademy organisers for organising such a great Akademy.

For the after-dark track of Akademy, attendees retired to c-base, Berlin's repurposed crashed space station and hackerspace, to discuss, relax and enjoy the community vibe.

18 Sep 2025 12:00am GMT

Visiting my parents before going to Akademy I found the manual of my first Linux distribution ever: S.u.S.E. Linux 5.1 from 1997.

Given my first PC was some Pentium 100 with 16 MB of main memory and Windows 95, that was my first dive into open source software.

Seems I went in less than 2 years from starting on Windows to at least trying out Linux.

A few years later I joined the great KDE community and stayed there :)

:) Now I feel old.

Feedback

reddit - Do you still remember your first Linux distribution?

16 Sep 2025 8:15pm GMT

People have been a bit weirded by what happened during this period. People have been interested in this after the post by Jonathan Riddell was written.

Here's what I remember from the situation.

Order of events

1. I get laid off from previous job in 2023-10-10.
2. Nate Graham learns of this and invites me to join Blue Systems.
   • I would be joining the team that works with Valve contracts. Cool!
   • He had no power to really "invite" me but told me that there's a good spot I could fill.
   • I apply and cross my fingers
   • I get into interview and get hired!
3. I work for Blue Systems until ~31.10.2024, renewing the contract yearly.
4. Blue Systems holds a get-together in late 2024.
5. I am really bad with traveling due to anxiety and I was still recovering from the Akademy 2024, I skip this get-together.
6. I get a video call from the get-together, where I'm told news: the team that has the Valve contract is being laid off.
7. However! We also have this chance to start working with our single contract, Valve, in separate company.
   • Essentially, we, the team that works with Valve, are moving to new company and continue this contract under it's name.
8. A lot of chatter in work Telegram about how the new company should be governed.
9. A lot of differences in opinions. Long debates. Talks.
   • Everyone had their own opinions and plans.
10. My wife gets really sick and has to spend chunk of December in hospital.
    • I have zero energy for any of the work governance things.
    • I just wanted to make sure I have job and get my salary.
    • Thus, I did not really care what the plan was going to be.
11. Eventually, we decide Nate's plan for this is the easiest.
    • More info here Personal and professional updates - announcing Techpaladin Software
    • I would have been fine with whatever plan, as long as I get to keep my job and continue my work and getting paid.
    • I do not remember any kind of voting or anything like that. We just went with it. Everyone was very tired of this weird situation.
    • We all just wanted to get back to work.
12. Time goes by and TechPaladin is ready for continuing the work around March.
13. I have some small interview about the situation with Nate, and he asks me if I'm still interested to join.
    • No contract was made yet with anyone. TechPaladin was barely established at this point.
    • I assume everyone in Valve team went through this discussion. I do not know anything else.
    • We had no money to pay for non-Valve related work.
14. I end my contract with Blue Systems around March 2025.
15. I start my contract with TechPaladin around same week.
16. I still work there!

Messy.

Yeah, it's really messy. And I wish it had gone differently. But that's how things go.

I have been laid off before, twice.

First time when I was a very fresh programmer, I was suddenly told in middle of day that my contract will end right before my probation period will end.

Then second time, I went for a leave due to burnout, come back to work, and on same day I'm told I'm getting laid off.

It sucked.

So Jonathan, I can sympathize with your feelings about the situation. I hope you get help for your issues and warmth to your life. Sincerely. I do not have anything bad against you.

My experiences at TechPaladin

• TechPaladin has always paid my salary in time.
• My contract is completely legal where I live.
  • I'm sure I could negotiate it into something more shiny with help of lawyers, money and time.
  • But I trust TechPaladin to not screw me over.
  • And if they would do so, I would leave immediately and cut my losses.
• I've never been "abused" in any way.
  • People care about me there.
  • They notice if I'm burning out (looking at you Dolphin) and help me switch projects.

Sure, I might be naive for trusting a company like this. But I'm just like this. If I like the people who I work with, I trust them. This is not the first company I trust like this. It won't be the last either, probably.

And I just want to fix bugs in KDE software without having to think about the corporate stuff, but still have money for food and rent. TechPaladin lets me do that.

In the end, the contract is my choice and this is the choice I've made. So far so good.

And my friends and family know me. If TechPaladin would go against my values or rights, all of them would know.

Conclusions

Draw your own conclusions.

Or better yet, join KDE to help keep the project running: https://community.kde.org/Get_Involved

Maybe this post helps shine light on things, anyway. Not that I really need to do this, since it's all private matters, but since it's been blown open, meh. Might as well. I'm tired of the misinformation I've seen around.

glhf.

ps. if some youtuber reads this, hi

16 Sep 2025 3:06pm GMT

By now, many have probably read Jonathan Riddell's blog post yesterday about his departure from KDE and the events that led up to it. And today, an article has been published in ItsFoss about the topic that unfortunately seems to have misunderstood some of the details of Jonathan's post. I didn't want to have to write this post, but since I'm named personally in both places, and there are inaccuracies spreading out there, I thought it would make sense to correct the record before this becomes too much of a game of telephone.

Overall it's a very sad situation, and I want to make it clear that I bear no malice or ill will towards Jonathan. As for the internal details of the transition of many of Blue Systems' personnel to Techpaladin Software, Jonathan is entitled to his interpretation of events, and that's fair. But it was a delicate transition, and people also have a right to personal and professional privacy. As such, it wouldn't be appropriate for me to get into anything non-public about individual people's personal and work situations, motivations, or decisions.

So there are some parts of the story that are going to have to go un-told in public, at least by me. But I can correct the record about misunderstandings and errors, and offer my own perspective!

I'll start with the ItsFoss article:

First of all, Jonathan never wrote in his post that he saw KDE itself "moving away from the cooperative and transparent model he valued", or that decision-making was increasingly concentrated under me. Jonathan's blog post wrote about his relationship with me in the context of the Blue Systems to Techpaladin transition, not about KDE itself. KDE itself is fine - better than fine, really. KDE is thriving, with competitive board elections this year and an increased base of donations it can use to assert a measure of independence from commercial entities.

It's also not true that Techpaladin was "meant to continue supporting KDE neon after Blue Systems scaled back." Jonathan didn't write this, and it was never the case. Techpaladin was and is a vehicle to take over the contract work that Blue Systems had been engaging in, after its manager made the decision to discontinue that work. KDE neon was never a part of this.

There are also a few topics from Jonathan's original post that need addressing. First of all, Blue Systems is not shutting down. I was just talking to a happy Blue Systems person at Akademy last week. As I mentioned, what actually happened is that Blue Systems divested itself of the consultancy element that it had picked up a few years prior. Blue Systems is still around as a company, and is still employing people who want to work there. Several people opted to stay there rather than moving over to Techpaladin. And at no point was I or Techpaladin ever Jonathan's employer.

I also want to make it 100% clear that I never made any effort to shut Jonathan out of anything in KDE, never encouraged anyone else to cut off contact with Jonathan or shut him out of anything in KDE, and never pulled strings behind the scenes to make it happen without looking like it was happening. Nothing of the sort! If Jonathan came back to KDE, I would be happy to rebuild a collegial relationship over topics of shared interest.

Finally, regarding company structure and employment details, I went into this a few months ago in https://pointieststick.com/2025/03/10/personal-and-professional-updates-announcing-techpaladin-software/#comment-40233. Techpaladin's current company structure actually allows people interested in making it more "co-op-like" to buy their way into partnership, which is how Igalia - the "cooperative socialist paradise" that Jonathan mentioned - does this as well. I'm confident that no laws are being broken here; I exhaustively researched the employment laws of 7 countries and then confirmed my conclusions with a lawyer before moving forward with anything. In addition, we practice financial transparency and cooperative decision-making on the topics of hiring, new contracts, etc. So internally it's quite "co-op like" already.

But this is my first time co-running a company of this size and complexity, so I'm sure I'm making mistakes and can do better. Now that the company has survived the initial setup and been around for 7 months, there's some breathing room to explore that. But from the start, the whole point has been to put money into the hands of people doing extraordinary KDE work that makes the world a better place, and to provide all of us with more agency over our KDE careers.

Hopefully all of this makes sense. If anyone has any further questions, I'd encourage them to ask publicly or privately, and I'll do my best to answer what I can that doesn't compromise anyone's personal or professional privacy.

16 Sep 2025 3:01pm GMT

Qt Multimedia is getting its own category at the Qt Forums!

15 Sep 2025 8:10am GMT

As accessibility continues to gain traction across major operating systems, high contrast mode has become a key feature for improving visual clarity and usability. With the release of Qt 6.10, applications built with Qt now readily get support for high contrast modeacross multiple platforms, ensuring more inclusive and visually adaptive UIs. In this post, I explore how Qt 6.10 supports high contrast mode, what it means across different systems, and what Qt now provides for built-in styles.

Enhancing Accessibility with Better Contrast

In recent years, major platforms such as Windows 11, macOS, and the Gnome desktop have introduced settings for a high contrast mode that enhances the contrast between foreground and background user interface elements. Adjusting these contrast settings typically updates the system color scheme and, in some cases, adds more pronounced outlines or other modifications to native UI controls. On macOS, iOS, and Gnome, users can enable increased contrast through a toggle in the accessibility section of the system settings, which reinforces outlines for most native controls. Windows 11 takes a more advanced approach with its Contrast themes feature, resulting in significant changes to the appearance of native applications when activated.

New with the High Contrast Mode in Qt 6.10

15 Sep 2025 6:30am GMT

I was at Akademy 2025 last-last week where I did some preliminary research on optimizing the VM viewer's display rendering on Karton. After some more work this past week, it's somewhat here! I'm still finishing up the merge request, but exciting news to come!

This has been something I've been planning on for quite a while now and will significantly improve the experience using Karton :)

a comparison with an old video I had.

Old Rendering Pipeline

My original approach for rendering listened to display-primary-create and invalidate-display-primary SPICE signals. Everytime it received a callback, it would create a new QImage and render that to the QQuickItem (the viewer window). As you can imagine, this was very inefficient as it is basically generating new images for every single frame being rendered. It suffered a lot from screen-tearing any time there were sudden changes to the screen.

You can read more about my experiences in my SPICE client blog.

We can do better!

Rendering via OpenGL can offload a lot of these tasks to the GPU and can significantly improve performance. I had known about GL properties in SPICE for a while now, but I kept putting it off since I really didn't want to deal with any more graphics stuff after my last attempt.

Fast forward to last-last week, I was attending my first ever KDE Akademy in Berlin and all of a sudden gained some motivation.

It was really exciting hearing talks about all the kool things happening in KDE.

gl-draw

My first order of business was getting the gl-draw signal to properly receive gl-scanouts from my SPICE connection. After setting up the callback, I found out that I had to reconfigure my VMs to properly support it.

This was easy enough as I've made the Karton VM installation classes a few months ago done through the libvirt domain XML format. VMs need enabling of GL and 3D acceleration through the graphics element in the XML. The socket connection to SPICE also had to be switched from TCP to UNIX, which was set to /tmp/spice-vm{uuid}.sock. As a result, previous VMs configured in Karton will no longer work as the previous rendering pipeline has been removed.

<graphics type="spice" socket="/tmp/spice-vm{uuid}.sock">
 <listen type="socket" socket="/tmp/spice-vm{uuid}.sock"/>
 <gl enable="yes"/>
</graphics>
<video>
 <model type="virtio" heads="1" primary="yes">
 <acceleration accel3d="yes"/>
 </model>
 <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

An example libvirt domain XML snippet generated by Karton

Once properly configured, I was able to get SpiceGlScanout objects from my callback linked to the gl-draw signal. Now, I needed to render these scanouts onto my QQuickItem canvas.

EGL stuff

Having no background in graphics, I pretty much had no idea what I was doing by this point.

The SpiceGlScanout is a struct that looks like this:

struct SpiceGlScanout {
 gint fd;
 guint32 width;
 guint32 height;
 guint32 stride;
 guint32 format;
 gboolean y0top;
};

The width, height, stride, etc…, are all parameters that can be used to set your final rendered frame, but the important field is the fd (file descriptor) which is a "a drm DMABUF file that can be imported with eglCreateImageKHR". I didn't know what that was; but at least I learned I should be using the EGL library to do the processing.

I had found some forum articles (Qt forum, Arm developer forum) related to rendering OpenGL textures which used the EGL library and were quite helpful. I also looked at the SPICE GTK widget source code which gave me some ideas on the GL parameters to work with.

From these references, I saw that they pretty much followed the same pattern. Very simply put:

-> create egl image from a bunch of attributes/settings
-> generate texture from the fd
-> bind texture to a texture type
-> "glEGLImageTargetTexture2DOES" use this function?? still don't know what this does lol
-> destroy egl image

I originally tried setting the GL context properties manually, but there were some issues with getting it to detect my display and apparently thread syncronization. Then, I found out that Qt had a QOpenGLFunctions library which had all of the EGL functions and context properties wrapped and made my life a whole bunch easier.

OpenGL texture -> Qt

After a ton of trial and error, it looked like my EGL images were properly being created. Now I needed to render these GL textures to the QQuickItem.

How you do so is, within the inherited updatePaintNode() function, you return a QSGNode which has the information for updating that frame. Looking through the Qt documentation, QNativeTexture is a struct that allows you to store a texture ID to an OpenGL image. With that, you can create a wrapper QRhi class from the QNativeTexture with some of the generic context of your display.

Finally, you can use the createTextureFromRhiTexture() function under QQuickWindow which allows you to create a QSGTexture from that RHI for a QSGNode that can be returned by updatePaintNode(). And, we're done! Yay!

To sum it up, here's the framebuffer pipeline:

gl-draw signal->receive gl-scanout->import GL texture->GL texture ID->QNativeTexture->QRhi->QSGTexture->QSGNode->QQuickItem

so much smoother! yes, I was very excited.

Socials

Website: https://kenoi.dev/

Mastodon: https://mastodon.social/@kenoi

GitLab: https://invent.kde.org/kenoi

GitHub: https://github.com/kenoi1

Matrix: @kenoi:matrix.org

Discord: kenyoy

15 Sep 2025 12:00am GMT

KWin Gamepad Plugin: Weeks 3-4

Picking up from weeks 1+2 ( research + prototypes with libevdev/uinput ), these two past weeks were about moving from "research-only mode" to turning ideas into programming logic that lives inside KWin to: detect gaming controllers and their input events, keeps Plasma awake on controller activity, handles hot-plug and pre-existing connections on startup, and lays down the first mappings from controller input to keyboard/mouse actions without stepping on other apps utilizing the controllers.

From the start my mentors and I have had a general idea of the features we wanted to add but weren't too sure how to implement them. After some thinking and experimenting they advised me to start off with a KWin::Plugin. This would allow us to start introducing the gaming controller functionalities to KWin while avoiding having to edit the core or guts of KWin. It would also be a great entry point for current and future game controller input objectives, allowing us to start small with a 1st party KWin plugin, build on it, and possibly integrate it into core functionality.

When it comes to creating KWin plugins I had a few options:

• Scripts: Written in QML/JavaScript and used for automating window management, tiling, shortcuts, etc.
• Effects: Implement visual effects on windows, the desktop, or transitions.
• Core/Native: These are built into KWin itself and extend KWin's internal functionality.

Since the plugin needs low-level device access, such as monitoring /dev/input/event*, listening to udev hotplugs, opening fds, and reacting to evdev events the best choice was to go with Core / Native plugin. As opposed to Effect and Script plugins which aren't designed to open devices or do long-running I/O, most simply just live inside the rendering/scripting layers.

I started off by searching for an example of how to build a KWin plugin so I could start learning how to build my own. Thankfully my mentor @zamundaaa provided me with some great examples:

• Example / Tutorial plugin located in src/plugin/examples/plugin
• Screenshots plugin located in src/plugins

Between both of these examples and mentoring I was able to piece together the scaffolding ( essential parts ) of a KWin plugin and was able to put together the first version of this plugin, gamepad plugin, located in: kwin/src/plugins/gamepad. At this point the plugin is structured as follows:

main.cpp // Entry point & Defines GamepadManagerFactory Class
metadata.json // Declares the plugin to KWin, define information about plugin
CMakeLists.txt // C++ Build/Installation/Logging wiring
gamepadManager.{cpp/h} // Plugin Logic: Defines GamepadManager Class
gamepadManager.{cpp/h} // Plugin Logic: Defines Gamepad Class

Implementation notes

GamepadManagerFactory

GamepadManagerFactory Class serves simply as the entry point for the plugin. It's a factory class, or a class used to create other classes / object types. Like the examples, it inherits from PluginFactory and declares it as its interface as well as pointing to the metadata.json file for this plugin. It initializes the plugin through its create() function which returns a GamepadManager.

GamepadManager

GamepadManager class serves as the central coordinator (the "brain" or "hub") of the entire project. While creating this I took a lot of inspiration from src/backend/drm/drm_backend.{cpp/h}, which itself is responsible for handling drm/gpu devices. GamepadManager covers many responsibilities. It owns and manages all gamepad devices, handles discovery (startup enumeration, hot-plug), lifecycle (adding/removing), and communication (signals when pads are added/removed, or when their state changes). Overall its responsible for keeping track of the current set of controllers and their status.

Detect hot-plug and pre-existing device detection:

For this part many of the DRM backend pattern were used. The first thing the manager class does on initialization is create two QMetaObject::Connections that monitor the current KWin session for devicePaused and deviceResumed signals. This helps track devices when Plasma goes in and out of sleep/suspend which causes devices to be Paused and Resumed. It then enumerates over all event devices located in /dev/input/event* to handle any pre-existing connections to game controllers. If it discovers an event device it adds the gamepad ( start tracking it and its input ).

// On init:
// Enumerate current input nodes to filter and add ONLY event nodes
QDir dir(QStringLiteral("/dev/input"));
const auto files = dir.entryList({QStringLiteral("event*")}, QDir::Files | QDir::Readable | QDir::System);
for (const QString &file : files) {
 const QString path = dir.absoluteFilePath(file);
 if (!isTracked(path)) {
 addGamepad(path);
 }
}

Finally using udev it monitors the subsystems and filter for only "input" subsystem events. It uses QSocketNotifier to produce signal notifications from udev events and creates a connections between that notifier and a memeber function, handleUdevEvent, that handles events coming from the udev monitor when an input device is detecetd. Some checks are performed to verify if the device is a gaming controller, such as expected input events and input event types. This include input events like BTN_JOYSTICK and BTN_GAMEPAD, which are commonly defined in gaming controllers. As well as checking for joystick or D-pad capabilities. If the checks pass the game controller is "added", or in other words, the device is wrapped in a Gamepad class, kept track of and its presence monitored.

// setup udevMonitor
if (m_udevMonitor) {
 m_udevMonitor->filterSubsystemDevType("input");
 const int fd = m_udevMonitor->fd();
 if (fd != -1) {
 m_socketNotifier = std::make_unique<QSocketNotifier>(fd, QSocketNotifier::Read);
 connect(m_socketNotifier.get(), &QSocketNotifier::activated, this, &GamepadManager::handleUdevEvent);
 m_udevMonitor->enable();
 }
}

Gamepad

Gamepad is a wrapper class. It's purpose is to be tied to a physical controller. One Gamepad object per physical game controller. This enables quick access/reference to the device and allows for the physical controller to be treated like an object. This class is also responsible for device input handling, Plasma Idle refresh, and button to keyboard/mouse mappings. In the future things might get split up into seperate files but as it is, it handles a lot. As with the GamepadManager, this class takes a lot of inspiration from DRM backend patterns.

Detect Input Events:

Once a gaming controller device is detected it gets wrapped in a Gamepad class object. Which in turn wraps the controller in a libevdev object pointer. This is the part that gives access to the controller through the libevdev API, making it easier to work with it and monitor its input events. Like GamepadManager the first thing this class does is use QSocketNotifier to produce notifications from the controllers fd, i.e monitor for input. It then creates a connections between that notifier and a member function, handleEvdevEvent, which handles all incoming input events from that device.

libevdev *evdev = createEvDevice();
if (evdev) {
 m_evdev.reset(evdev);

 m_notifier = std::make_unique<QSocketNotifier>(m_fd, QSocketNotifier::Read, this);
 connect(m_notifier.get(), &QSocketNotifier::activated, this, &Gamepad::handleEvdevEvent);

 qCDebug(KWIN_GAMEPAD) << "Connected to Gamepad ( new libevdev* ): " << libevdev_get_name(m_evdev.get()) << "at" << m_path;
}

Plasma Idle Refresh On Controller Activity

With the ability to monitor for all input events from the device, the plugin then uses that information to know when to reset Plasma idle timer. For this Gamepad imports/includes input.h file and makes a call to input()->simulateUserActivity() when an input event is detected from the controller. This causes Plasma idle timer to be reset and prevents the system from going into sleep/suspend mode while using only gaming controller.

// reset idle time
input()->simulateUserActivity();

Controller -> Keyboard & Mouse Mapping

Gamepad uses API function from libevdev to check for input events, identify the specific input event and map that to a keyboard or mouse input event. Using libevdev_next_event() it checks for the input event coming from that game controller. It then identifies the specific input event through its input event type, code, and value. To simulate a mouse and keyboard the core/inputdevice.h file is imported and used to declare GenericInputDevice which inherits from InputDevice. That GenericInputDevice effectively behaves like a virtual keyboard and mouse inside KWin's input stack.

When specific libevdev input event are identified, such as EV_KEY + BTN_SOUTH ( A button press ) OR EV_KEY + BTN_EAST ( B button press ), it call InputDevice::sendKey() to simulate keyboard key press and inject the desired keys into KWin input pipeline. In this case Enter for A ( BTN_SOUTH ) and Escape for B ( BTN_EAST ). To emulate mouse/pointer the plugin makes calls to InputDevice::sendPointerButton() for left and right mouse buttons, and InputDevice::sendPointerMotionDelta() for pointer movement.

Here is a list of all the buttons to keyboard/mouse mappings:

Face Buttons
------------
BTN_SOUTH → Enter (Qt::Key_Return)
BTN_EAST → Escape (Qt::Key_Escape)
BTN_NORTH
BTN_WEST
Bumpers
-------
BTN_TL → Alt (Qt::Key_Alt)
BTN_TR → Tab (Qt::Key_Tab)
Trigger Buttons
---------------
ABS_Z → Mouse Left Click
ABS_RZ → Mouse Right Click
D-Pad
-----
BTN_DPAD_LEFT → Arrow Left (Qt::Key_Left)
BTN_DPAD_RIGHT → Arrow Right (Qt::Key_Right)
BTN_DPAD_UP → Arrow Up (Qt::Key_Up)
BTN_DPAD_DOWN → Arrow Down (Qt::Key_Down)
Analog Sticks
-------------
ABS_RX / ABS_RY → Pointer Motion
Center Buttons
--------------
BTN_SELECT → Show On-Screen Keyboard ( WIP )
BTN_START → Meta/Super (Qt::Key_Meta)

Prevent Stepping On Other Apps

It's essential that the plugin doesn't emulate keyboard and mouse for the gaming controller when another app is reading from it. Most likely in such cases the device is being used for something else and not being used to navigate the desktop. To achieve this the GamepadManager class creates an instance of inotify object, and adds a watch device to the fd of each game controller that's added as a Gamepad. Whenever inotify produces a notification a function, GamepadManager::handleFdAccess, is called which increments a counter in Gamepad, Gamepad::m_usageCount by +1 if the event value is IN_OPEN or Gamepad::m_usageCount by -1 if the event value is IN_CLOSE_WRITE | IN_CLOSE_NOWRITE. The plugin will only attempt to emualte keyboard/mouse if m_usageCount is 0. This prevents emulation of keyboard and mouse when other apps have the game controller opened / in use.

// Process all inotify events in the buffer
for (char *ptr = buffer; ptr < buffer + length;) {
 struct inotify_event *event = reinterpret_cast<struct inotify_event *>(ptr);

 auto it = m_watchesToGamepads.find(event->wd);
 if (it != m_watchesToGamepads.end()) {
 Gamepad *pad = it.value();
 if (event->mask & IN_OPEN) {
 pad->countUsage(+1);
 } else if (event->mask & (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)) {
 pad->countUsage(-1);
 }
 qCDebug(KWIN_GAMEPAD) << "Device" << pad->path() << "in use by:" << pad->usageCount() << " other apps";
 }
 ptr += sizeof(struct inotify_event) + event->len;
}

Opt-In

Many of the native plugins that ship with KWin are enabled by default but for our gaming controller plugin we will disable it by default and make it an opt-in option. This will allow users to start experimenting and benefiting from the plugin without risking the possibility of breaking current game controller input on their system.

{
 "KPlugin": {
 "Category": "Input",
 "Description": "Enable KWin game controller input detection",
 "EnabledByDefault": false, <---------- Not enabled by default.
 "License": "GPL",
 "Name": "gamepad"
 },
 "X-KDE-ServiceTypes": ["KWin/Plugin"]
}

Testing

• Controller awareness at startup and hot-plugging: tested in development session, KWin logs show the plugin picking up controllers in both scenarios, works as expected.
• Preventing sleep/suspend: tested in development session. Set suspend timer to 1min, repeatedly press A and B back and forth, and at 5min no suspend was initiated, works as expected.
• USB and Bluetooth connectivity support: tested in development session, KWin logs show plugin picking up on the controllers in both scenarios, works as expected.
• Mapping from controller to keyboard and mouse: tested in development session, all buttons are map to expected keyboard and mouse, works as expected.
• Backoff On Grab: tested in development session. Verified mapping work, started Steam app, verify mapping no longer enabled.

Testing device: 8Bitdo Gaming Controller (USB/2.4h/Bluetooth)

What's next from here

• Integration into KWin Proper: Start pushing changes upstream for others to test.
• Map to Virtual Keyboard: Allow users to navigate over and get input from a virtual keyboard. Might open the way for logging in using only game controller.
• Test Cases: As per best practices when developing for KWin.
• KCM integration: A GUI option for users to toggle plugin ON/OFF. Ground work for more robust, user defined, button remapping.
• Use Config for Mapping: Using a config file to keep track of and read from all the button to keyboard/mouse button mapping.

Reference documentation:

• Example / Tutorial KWin Plugin: https://invent.kde.org/plasma/kwin/-/tree/master/examples/plugin
• Screenshots KWin Plugin: https://invent.kde.org/plasma/kwin/-/tree/33262fef1a6e4e3bcebc05181edbde2d9a72f38c/src/plugins/screenshot
• DRM Backend: https://invent.kde.org/yorisoft/kwin/-/tree/master/src/backends/drm/drm_backend.cpp
• Linux Input Subsystem (overview): https://www.kernel.org/doc/html/latest/input/index.html
• Libevdev Library: https://www.freedesktop.org/software/libevdev/doc/latest/
• Udev Library: https://man7.org/linux/man-pages/man7/udev.7.html
• Inotify Library: https://man7.org/linux/man-pages/man7/inotify.7.html

Checkout the source code here: KWin Gamepad Plugin: https://invent.kde.org/yorisoft/kwin/-/tree/work/yorisoft/gamepad-plugin/src/plugins/gamepad

15 Sep 2025 12:00am GMT

I'm happy to announce the 0.8.2 release of Subtitle Composer.

This release contains bugfixes and few improvements including:

• Fixed issues and crashes with newer Qt6 versions
• Fixed Waveform and VideoPlayer paint issues
• Fixed PGS subtitle mime type
• Improved Wayland compatibility
• Improved GoogleCloudEngine translations
• Added configurable whitespace detection to VobSub import
• Replaced deprecated FFmpeg channel code
• Require FFmpeg >= 5.1.5

As usual all binaries are available from download page.

Source tarball can be downloaded from download.kde.org.

- Mladen

14 Sep 2025 10:15pm GMT

It was the turn of the millenium when I got my first computer fresh at university. Windows seemed uninteresting, it was impossible to work out how it worked or write programs for it. SuSE Linux 6.2 was much more interesting to try and opened a world of understanding how computers worked and wanting to code on them. These were the days of the .com boom and I went to big expos in London where they showered you with freebies and IBM competed with SuSE and Red Hat for the biggest stall. IBM said that Linux had made it on the server and now was going to take over the desktop so I realised that working with KDE would be a good idea. And as a novice coder it was very perfect for learning Qt and how open development worked and I loved the free software ideals. Going to the pre-Akademy conference (it was called Kastle then) in Nove Hrady was a great intro to the community in person and in some ways I learnt more about software development in a week there then my years at uni.

So clearly this was a good way to make a career. I dossed around for a year until the Quaker geek collective heard tale of an African Spaceman who was funding a new Linux distro called SSDS (Shuttleworth's Super Secret Debian Startup) so I got into Debian packaging and made a point that KDE should be involved. Before long they came knocking and I went to the first Ubuntu conference in Australia. I spent about ten amazing years brining KDE to Ubuntu or bringing Ubuntu to KDE for what was already called Kubuntu (not my name choice), a successful community project I'm really proud of. At one point Nokia wanted to use it alongside Plasma Active to sell on a tablet thing along with phones, this could well have taken over the world but y'know, iPhone happened and Kubuntu never found a commercial use after that although it still gets used in big places like Google or the City of Munich or Weta digital (watch those Hobbit DVD extras). I loved being invited out to Nigeria or India to give talks and spread the world of open software. Looking back there's probably a million business cases that would have been possible but I'm not the best at being a future visionary. Eventually Canonical decided to stop funding it which is fair enough.

But then Blue Systems came along, another nice guy with deep pockets wanting to help and we carried on. When Canonical decided to kill off lots of community projects we came up with the idea of moving directly into KDE to make KDE neon. It has always been crazy how open source communities like KDE are reliant on separate companies to take their software out to the world so we wanted to change that, and I like to think we succeeded. Using CI systems we could create a much more manageable setup. Still the system was never as resiliant as it should have been and several times KDE neon ended up shipping a duff update which will have been very painful for users. We had three people working full time on it at the start but before long it was just me and a volunteer and the quality suffered as a result.

Last winter I drove to the Blue Systems schoße for a routine conference and was organising people to give talks when the guy who pays us started off by saying he was dying and the company would be shutting down. Which was very sad but it makes sense to end it on a high. After years of having no business modal and not knowing what the aims of the company were, which caused several people to genuinely go mad, we finally had a business model of sorts with Valve paying us to make Plasma up to the standards needed to ship it as Desktop Scope on the Valve Steam Deck games console. Nate had been given advanced notice of the company shutting down and had already started another company, Tech Paladin, to take on the business. Shouldn't this be run as a cooperative we wondered? No that was too complex he said. The next day I ended up at a funeral for some German accountants and when I came back there had been some more discussion and we watched a video about Igalia who make the other operating system for Valve. They are a cooperative socialist paradise and Nate said he'd look into doing that instead of the setup where he had full control and all the profit. It was clear there was to be no other discussion on the matter of our future.

A few weeks later we had an online meeting where I proposed a useful agenda but was ignored, instead Nate gave his updated plan for a business which was to give Dave a slice of the profit and otherwise he'd keep all the profit and all the control. So I gave my proposal I'd been working on for a company with equal ownership, equal profit, a management structure and workers rights. A couple weeks later we had anther video call but Nate called me first and told me I'd be excluded from it. No explanation was given beyond I had "made some comments and would not be happy". If someone is telling you what your emotions that is when controlling behaviour starts to become abusive. And thus ended my 25 years with KDE.

And what of my colleagues? Surely they wouldn't want a setup where they have no control over their professional life and all their profit goes to one person? Well dunno, they've stopped speaking to me. Nothing. Silence. Nil. Not so much as a "cheereo", nor "sorry we chose the option were you got excluded" and certainly no explanation. From people who I have worked with for some twenty years in some cases that hurts. I don't know why they stopped talking to me, I can only speculate and I don't want to do that.

We never had workers rights at Blue Systems, we were all on self employment contracts. This will continue at Tech Paladin. It is illegal but unenforceable when done on an international setup. But employment rights are not a luxury you can chose to do without if you enjoy your job and want some more flexibility in your work day. They are fundamental and life altering rights that change people's lives as I discovered when my adopted children were taken away from me. Nobody should be doing business with or taking money from Tech Paladin else be party to illegal workers rights abuses.

Then I started to get sad, being cut off from my life for the last 25 years was too much for me. All things come to an end and I've seen plenty people had to leave KDE because the money ran out or maybe they had a disagreement with someone in the project, but never a profiteering control struggle like this. I struggled to get out of bed on some days. I've given my life to KDE, I've seen it gone from a sure fire project to take over the world to being one open desktop project in a world of many to seeing the revival in recent years where we can honestly say we make some of the best software out there. I like to think I've been part of keeping it alive, progressing, relevant and at the forefront of commercial, government and community usage. It's been an amazing ride full of opportunities and adventures the likes of which I'm sure my peers from my university course have never had.

But in the end I lost my friends, my colleagues, my job, my career and my family. What's a spod who just tried to do the right thing for society to do? Dunno. For now, if you want me, you can find me surfing the endless wave whenever the sun sets over my digital nomad coliving paddleshack at the end of the world.

14 Sep 2025 8:56pm GMT

I was able to attend the talks at Akademy this year in Berlin! The last time I attended Akademy in person was in 2022, so it was really nice being able to come back and meet everyone again.

I was unfortunately not able to attend BoFs (development meetings) due to having to leave early. I did attend some meetings a few months earlier however, you can read more in my Plasma sprint recap post.

Talks 🔗

Akademy runs with two concurrent tracks of talks, and so sometimes there were two talks at the same that I both wanted to attend, I had a hard time deciding! Here are some of the ones I attended:

KDE Linux: Banana Growth Cycle 🔗

Harald released KDE Linux Alpha was to the public during the talk! I hadn't followed the project super closely, but it was awesome getting up to speed learning about the state of the project and the inner workings of how the distribution works.

The Role of New Languages in the Future of the Qt Ecosystem 🔗

I was introduced to Qt Bridges, which is an effort to go beyond Qt bindings for other languages and tightly integrate with them (ex. Rust, Python). Once this is more mature, it will likely be an easy recommendation for others to start learning Qt with, who don't want to use C++!

KDE Goals - One Year Recap 🔗

It was interesting to see all the work that had been done on the KDE Goals so far!

I am actually involved with one of them this time around ("We care about your input") through my work on plasma-keyboard. Blog post likely coming in a few months, once that work is further along!

Next-Gen Documentation Infrastructure for KDE 🔗

KDE's reference API documentation has been a bit of sore spot for me, since it didn't support QML very well. As a result, I usually go manually go through header files instead in the source code to figure out how to use libraries.

The talk went over Nicolas's work on doing the mammoth task of porting all of KDE's API documentation to QDoc from Doxygen, which properly supports QML. The new api.kde.org went live, and boy is it such an improvement! It's much easier for me to point new developers to the Kirigami documentation now.

Fedora KDE Plasma Desktop Edition is Real, Now What? 🔗

I personally use Fedora on my workstation and laptops, and so it was cool to get some history about how Plasma on Fedora was revived in the past, and plans for the future. Neal also expressed some interest in a Plasma Bigscreen spin (similar to the one for Plasma Mobile), which could be pretty interesting once it becomes more mature!

Plasma Mobile Power Management: Reliable Sleep and Wake Ups 🔗

Bhushan gave an update on his work power management work across the Plasma stack! He obtained an NLNet grant recently for the project, detailed on his blog.

Discussions 🔗

I was really happy to meet and discuss with quite a few people during the event.

I met Bart, Luca, Casey and Pablo from the postmarketOS project! As it is the main platform I test and develop Plasma Mobile with, it was really nice to finally meet some of their developers (I had met Bart and Luca at Akademy 2022)! I also was able to finally meet Florian, who has been collaborating with me in contributing to Plasma Mobile in the past few years!

I met Dorota, who has been working on Wayland input related things for the past few years, and is in the process of pushing through updates to text-input-v3, and Jakob who has been working on the KDE side pushing through the input related KDE goals! We discussed some input related topics, which was insightful as I worked on the client side through plasma-keyboard (and my limited Wayland knowledge).

I also discussed some Kirigami page navigation related topics with Marco. I'm doing a bit of investigation into how we can improve the way we navigate between pages in applications, and perhaps restricting the page left/right gesture into the side (similar to iOS).

14 Sep 2025 7:00pm GMT

I'm back from Akademy 2025 in Berlin, and what an experience it was.

At this point, I've gotten a reputation as a "big picture guy", so that's what I'll focus on here, rather than the details of my experiences in specific events. Lots of other folks are starting to write blog posts you can find on https://planet.kde.org about their Akademy experiences that I'm sure will be full of juicy details!

But basically, to me this year's Akademy felt like it had a theme: "KDE is on the cusp of something big."

Here's one example: at the very cool C-base hackerspace, I was talking with someone who mused that 15 years ago, Akademy was full of KDE hackers talking about the government one day using our software… and then fast-forward 15 years and our two keynote speakers are from the German government talking about using KDE's software!

Then we had a talk from the "End of 10" crowd about KDE's campaign encouraging people to upgrade to Linux rather than buying new hardware capable of running Windows 11. And then as if to reflect on the success of this initiative, Patrick Fitzgerald gave a talk about how to do massive migrations from Windows to Linux, with examples provided of cases where literally thousands of machines were migrated to KDE software at a small fraction of the cost of moving to Windows 11.

Till Adam gave a talk about how commercial work changes relationships with respect to his experience in KDAB, a software consultancy founded by KDE contributors. I found this talk highly relevant given that David Edmundson and I just started a KDE-focused company this year ourselves. Alexandra Betouni also gave a talk about rising to the top of a company. Hmm, lots of companies!

We heard about how Mercedes is rolling out a vehicle powered by KDE technology under the hood.

In the "hallway track", I had a fascinating discussion about how KDE's efforts to improve accessibility have the potential to be an industry-wide force multiplier.

And then I gave a talk myself about the big picture of all of these trends - that as the world falls apart around us, everything being on fire includes tremendous opportunities for change that KDE is well-positioned to benefit from.

Basically, at age 29, KDE is all grown up now. Our software solves real problems for real people, at scale. It works for governments and big businesses. It saves or earns money for a lot of people. Our competitors are beginning to falter and look weak. But through it all, KDE remains healthy and strong, and grows in stature.

So I found Akademy 2025 to be an unexpectedly serious conference, full of heavy topics and sharing of priceless wisdom from hard-earned experience. There was of course also a lot of fun hacking and group gatherings and renewing of social bonds, but throughout everything was that underpinning that KDE isn't just a fun little online community anymore, but rather a player with a growing significance on the world stage.

Pretty cool stuff, I think! Personally, I get energized by working on things that matter, and boy did Akademy 2025 leave me with the impression that KDE matters.

14 Sep 2025 6:50pm GMT

From the 3rd to the 5th of September, the Kdenlive team was reunited in Berlin for a sprint and to attend Akademy, KDE's annual conference. This was an occasion for us to meet in person since our team is spread across continents, and to join our forces to make Kdenlive better. And I must say this was one of the most productive sprints in Kdenlive's history!

We were kindly hosted by c-base for our Sprint so a big thanks to the team for welcoming us there!

Let's get into the details of what we did:

We started by reviewing and updating our roadmap, so it is easier to understand what we are working on, what we plan and when. Another important step towards improving our workflows is that we created issues for each of these goals where the details will be discussed, so everyone can follow and possibly help us on the road to success.

Dopesheet

Very exciting, I received a grant from the NGI Zero Commons Fund through NLnet to work on a dopesheet feature in Kdenlive. This will bring a much improved keyframing interface with powerful features. We discussed what core features we want in it and some drafts on how that would work. This feature won't be ready for the December release, but I will post updates on the progress of this task in the coming months.

We then reviewed specific parts of the UI that we would like to improve. All these ideas will be discussed in specific issues so that we can refine the implementation.

Menu reorganization

This task started two years ago but we never took time to finalize it. We progressed a lot on this and you can expect it to land in the December release. Among the changes, we decided to rename the Project Bin to Media, Render to Export, and reorganize the menus to make things more logical. We will make another blog to present these changes in detail once this is done.

Timeline toolbar

We want to cleanup the UI, make the timeline timecode display cleaner and get rid of the large Master button currently taking a lot of space.

Monitor UI

We plan to move the audio vu-meter to a collapsible vertical widget on the right side of the monitor to free some space in the toolbar, make the zone duration always visible and move the insert/overwrite actions currently in the timeline toolbar there.

Audio monitor

When selecting an audio clip, the Clip Monitor currently displays a huge audio waveform that is not that useful. We reviewed the UI to also display an overview at the top, making it easier to zoom and see where you are in the clip.

Layout and docks

We have several open issues regarding docking. One of the frequent request we have is to save the layout per project file, since sometimes you want very specific layouts for a project. We discussed how to make it happen and are also evaluating switching the library managing the widgets docking to KDDockWidgets that would bring us some very nice improvements like being able to detach the timeline or group several undocked widgets together

Titler

Our current titler does the job for simple tasks but many users would like to be able to use some animation presets to make their titles more dynamic. We discussed the possible options to make this a reality. Among the ideas, we could use Lottie animations, since our video backend MLT already has support to play them through the Glaxnimate module. Another option would be to implement a Qml producer for MLT, allowing to play Qml files directly as a video. Any help on that topic is welcome.

Website

We have some planned changes to make our website look better and discussed some of the options.

And all the rest

We discussed tons of other things and even managed to shoot some interviews of our team members. Less relevant maybe for users but we also reviewed some of the administrative and trademark issues, and CI/CD issues

Akademy 2025

Akademy was also an occasion to have interesting exchanges, notably with Glaxnimate's maintainer, Plasma developers and more. We are now back home with tons of ideas and TODO's, and the next release of Kdenlive, to be launched in December, will shine with some of the improvements we prepared during this week in Berlin !

If you would like to help our small team, you are always welcome to contribute by giving some feedback, talk about us, create a merge request or donate.

14 Sep 2025 2:10pm GMT

Despite the lack of posts (which we apologise for) the builds have continued to happen on the neon build servers. Packages for Plasma 6.4.5, coupled with KDE frameworks 6.18, and KDE release service 25.08.1 built on top of Qt 6.9.2 have just been released to the neon user archives. Live Image ISO's and containers are available for download from the usual location.

The builds will continue to happen for the foreseeable future and hope that everyone enjoys the latest and greatest KDE created software, if that's your cup of tea.

14 Sep 2025 9:54am GMT

This year's Akademy was in Berlin at the Technical University of Berlin. The experience, as usual, was amazing. Unlike in previous years, there was a huge emphasis on styling, unification, and graphical work. This whole wave of talks was invigorating.

As a side note, this year our A/V was vastly improved and this should make it much easier for our contributors and viewers online to see and understand what we did. As part of the organization, I will help process these recordings and make sure they are awesome.

Once again I spoke on the progress with the design system. This year's talk focused on our progress on icons. Definitively, one of the lengthiest pieces of work coming from the Foundations portion of the design system.

In addition to speaking on these topics, I shared the newly created (and definitively experimental) Ocean color scheme, light/dark, Ocean Plasma Style, and Ocean icon pack. In case you missed these assets, here you go: https://drive.google.com/file/d/1oLVq0SViOFB6lur3qn0bwV7_gHzqu2KM/view?usp=sharing

One thing to note, and after much discussion during Akademy, we have aligned more properly on the way that we should work in light of the addition of the design system.

In our current process, we use GIT as the source for our icons. Anyone can download and apply the icons on their Plasma system. However, this process is not quite geared toward designers. After all, all icons located in the repo are exported icons. They are one-layer graphics that only function with node work. If a designer needed to work with these assets, they would have to likely recreate them to gain the appropriate shape control needed to make desired changes.

This leads to overhead work and style inconsistencies. Above all, it leads to a state where the real source of the icon doesn't exist unless we dig through each individual computer where the icon was developed.

With the use of applications like PenPot or Figma, that question is resolved. Users are able to download an asset library owned by the design team at Plasma. The source is protected but it's also distributed in away that doesn't affect the master copies. If changes are needed, change requests can be submitted to master and the design team can decide to apply those changes or not.

Effectively, this means a change in the way that icons are stored. Moving the work from Git to PenPot/Figma seems like the best choice.

This requires communication, habit changes, risk management, etc. While I am speaking of this right now, we are "not" changing our current process to obtain Breeze icons from its repo. However, it means more information will come in the future as we develop a more effective way to work with a design system.

I am so excited to see the progress done in Union, and even more excited to start passing on design system components into Union to see how they fare against the newly created engine. Union is also under heavy development. I encourage you to watch Arjen Hiemstra's presentation at Akademy when it's published.

When this happens, this would be the second set of graphical controls that are executed via Union. I am sure many challenges lay ahead but I feel energized by it. I am sure we are on our way to resolving long-standing design and development issues that have slowed us down.

As a result of this year's Akademy, I created a set of action items for myself that I have to review to be able to continue. One major item for me is to develop our master component source in PenPot. Even though Ocean icons are not 100% executable in PenPot, other assets like buttons, sliders, progress bars, inputs, etc are executable. I will dedicate the time to create these items and leave Figma for components behind, shedding also any legacy branding coming from the design system sources and only focusing on what we need for Ocean styles.

With that, Akademy has been a thrill. I go home energized and happy for what we have accomplished. All this while keeping a vibrant community and a vibrant free desktop system for all Linux users.

13 Sep 2025 4:00pm GMT