The last maintenance release of the 25.04 series is out with fixes to the volume and transform effects as well as some issues with guides.

For the full changelog continue reading on kdenlive.org.

Cameras!

Today, I am announcing a new release of Plasma Camera, a camera application for Plasma Mobile (though it can also be used on desktop!). This release ports the application to use libcamera as the backend for interfacing with cameras, finally allowing for it to be used on Linux mobile devices (such as the OnePlus 6).

The main porting work was done by my friend Andrew (koitu) a couple of months ago. It remained stalled on some issues, so I picked it up in the past week to complete the port and finish the application. Here is a link, which has more technical details!

Background 🔗

Cameras have been a long neglected area in Plasma Mobile, ever since the focus shifted from halium to mainline devices. With mainline devices, libcamera drivers have been developed for them, allowing for cameras to be used in applications over Pipewire (ex. GNOME Snapshot, Firefox, Chromium).

Plasma Camera was originally created in 2019 with halium devices in mind, using the official Qt Camera library as a backend for interfacing with cameras. This library allows for the app to work on Android and on desktop with USB webcams. Unfortunately, Qt Camera does not currently have support for using Pipewire or libcamera directly as a backend, and so is unable to interface with the cameras on the OnePlus 6 and Pixel 3a.

Porting Plasma Camera 🔗

Qt Camera is a fairly high-level API designed to abstract over many different platforms, beyond Linux. Since our focus is on Linux, we decided to take this chance to port Plasma Camera to use libcamera directly for best control over the camera pipeline and features. Note that this approach differs from some other camera applications that use Pipewire, which has a backend to communicate with libcamera.

The API for libcamera is fairly comprehensive.

In order to implement the viewfinder (camera preview), we create a worker thread that is responsible for polling the camera for frames. A series of “requests” with a framebuffers allocated to each were created, which we cycle through when polling for frames. Libcamera then gives us a frame for each poll request, in which we send to our application thread to display.

For simplicity, Qt Multimedia was used for media processing. Frames from libcamera are wrapped in QImages and sent to a QVideoSink to be displayed in the UI. Any transformations needed (such as rotation correction due to how sensors are mounted on phones, or mirroring for front-facing cameras) are done before the frame is added to the sink. For taking photos and videos, we reuse the viewfinder’s frames.

For photos, we simply write the QImage to the disk.

Videos are much more tricky. Using Qt Multimedia we can build a video processing pipeline. We create a QMediaCaptureSession to facilitate all of the inputs and outputs needed. We then attach a media recorder QMediaRecorder for writing the video, an audio input (QAudioInput) and a video input (QVideoFrameInput). We have a separate polling timer that polls at the framerate of the video (which can differ from the framerate of the viewfinder), copying frames one-by-one into the QVideoFrameInput instance (more on this later) to be encoded by QMediaRecorder.

In the future, it may make sense to investigate whether we could benefit from porting to using GStreamer directly for media processing. We currently use Qt Multimedia with its ffmpeg backend. While Qt Multimedia does have an gstreamer backend, it has some limitations and was thus removed from being the default backend as a result.

UI work 🔗

I also took the liberty of doing some substantial refactoring and reworking of the UI code. We dropped some camera settings for the initial port of the application, to be restored later. However some other features were introduced.

The application has these features:

• Photo capture
• Video capture
• Audio recording toggle for video capture
• EV setting (exposure value)
• Captured photo/video preview
• Video recording settings (codec, resolution, FPS, quality)
• Timer before taking a photo
• Warnings for when the encoder is detected to not be keeping up with the video stream
• Settings persistence

Results 🔗

With USB webcams, both photo capture and video recording work.

It also sort of works on phones. I tested on the OnePlus 6 and Pixel 3a. I suspect that most of the issues are simply due to the camera driver not yet being mature enough, as I can replicate most of the issues on other camera applications. The photo quality and colours are not optimal, and there appears to be a fixed focal length, and so far away things look blurry.

The viewfinder stream is fine on my OnePlus 6 and looks smooth. However, for my Pixel 3a, the frames start flashing light and dark colours when I point the camera at any bright light source. I suspect it is due to the camera driver overcompensating for exposure perhaps? Not sure 😅

Photo capture works on both devices, outputting the frame from the viewfinder at full resolution to the disk almost instantly. Though the quality of the pictures is reminiscent of early 2000s phone photography.

The video recording experience however isn’t quite usable unfortunately, the video encoder does not appear to be able to keep up.

Limitations 🔗

Video recording issues on phones 🔗

The main barrier to video recording seems to be the performance of the video encoder. I’ve noticed on both phones that many frame calls to QVideoFrameInput fail because QMediaRecorder’s queue is simply full and cannot keep up with the amount of frames coming in. This can be mitigated somewhat by playing with the video recording settings. I’ve generally found the MPEG2 codec to be substantially faster for devices, though it gives very ugly artifacting at low quality, and sometimes gives an error. Of course, lowering the resolution and FPS also can help too.

For each frame given to QVideoFrameInput, I also set its timestamp to ensure that the encoder places it at the correct place. However, when we start dropping frames due to the encoder being full, we end up with gaps in the video without a frame, which I suspect is what is causing the pixelated “corrupt video” effect (though it only happens with H264, and not MPEG2 encoding?). We cannot really queue frames for the encoder, because we would very quickly run out of memory. I have an open issue about this since I am not really sure how to address it yet.

Rotation issues 🔗

Device rotation can be a bit of a problem with the application right now. We already account for the screen orientation in comparison to the camera orientation, which is reported as a property by libcamera.

The viewfinder however can be a problem when the display rotation is different from the screen’s orientation (ex. rotated 90, 180, 270 degrees). This is done by the compositor (ex. KWin), the application only sees that the window size has changed. However, that means the viewfinder is rotated as well! We are able to adjust for this in taken photos and video by reading the rotation sensor data (with QOrientationSensor/iio-sensor-proxy), however we cannot do the same for the viewfinder because we don’t know which orientation the compositor has the application in, which could be different from the sensor due to rotation-lock and manual settings.

I recommend keeping an orientation lock on “portrait” mode when using the application on a phone until we find a fix, that way the viewfinder does not get mismatched from what you see. We are tracking this issue here: https://invent.kde.org/plasma-mobile/plasma-camera/-/issues/14

Missing camera controls 🔗

The drivers for the OnePlus 6 and Pixel 3a seem to be missing almost all of the libcamera controls. At least, calling camera->controls() (doc) gives only the Contrast control from libcamera. There are other controls that I would like to implement once they become available, such as focus windows.

Once these are implemented in the driver (or if it’s fixed as an issue on our side) and support is added in the application, we will have a lot more camera features to play with!

Conclusion 🔗

We finally have a base on to use for the camera stack on Linux mobile. I hope the application continues to improve as drivers and camera support get better over time on these devices.

So, give it a try! And feel free to come join us to talk about it in the Plasma Mobile matrix channel!

Kirigami Addons is a collection of supplementary components for Kirigami applications. Version 1.9.0 is a relatively minor release, introducing two new form delegates along with various quality-of-life enhancements.

New Features

I took over the work from Tomasz Bojczuk and finished the addition of the file and folder form delegate.

These two components wrap a FileDialog and FolderDialog respectively and like KUrlRequester in KIO provide a text field with autocompletion on desktop. Currently the autocompletion is a bit basic and is based on a Controls.TextField with a Controls.Popup, but hopefully with Qt 6.10 we can use Controls.SearchField.

Bug fixes

Outside of these two new components, this release includes minor fixes and improvements from Antonio Rojas, Nicolas Fella Soumyadeep Ghosh, Thiago Sueto, Volker Krause and Yuki Joou.

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.

A Temporary Solution for Job Tracking

This week, I revisited the KUiServerJobTracker issue in the PIM Migration Agent. After last week’s D-Bus debugging and architectural cleanup, it became clear that replacing it entirely was more complex than initially expected.

After discussing with my mentor Carl, he summarized the situation in an email to the KDE PIM mailing list. In it, he outlined the limitations we were facing:

“The agent relies on KUiServerJobTracker, which aside from requiring a port to KUiServerV2JobTracker, also has the issue that it links to QtWidgets while not using QWidget itself.”

The email resulted in feedback from Volker Krause. In his response he agreed with one of Carl’s suggestion that I ultimately pursued: rather than remove the job tracker altogether or build an entirely new progress infrastructure, I created a local copy of KUiServerV2JobTracker inside the kdepim-runtime repository and carefully stripped out its QtWidgets linkage.

This forked version is temporary and self-contained, with a clear path to removal once the upstream KDE Frameworks address the QtWidgets dependency—likely by KF7. It allowed me to retain proper system tray integration for job tracking (which AgentBase’s built-in D-Bus support cannot currently provide), while still meeting the goal of removing QtWidgets from the Migration Agent’s core.

Shedding the Final Dependencies

With the tracker replaced, I focused on removing the last traces of QtWidgets from the Migration Agent. This included cleaning up the custom D-Bus interface and eliminating now-redundant methods. The final dependencies were located in individual subcomponent CMakeLists.txt files, which were still linking against QtWidgets.

After updating those, the result is a fully decoupled agent:

The PIM Migration Agent’s core logic is now completely free of QtWidgets.

In addition, I integrated the manual migration tasks into the job executor, allowing them to report progress using the same job tracking mechanisms as the automated tasks.

A New Akonadi Capability: SingleShot Agents

The mailing list discussion also highlighted another inefficiency: the Migration Agent doesn’t need to run persistently. As Volker suggested:

“Keep it as an agent but give it a special ‘SingleShot’ flag… with Akonadi shutting it down again automatically once done.”

Building on this idea, I introduced a new Akonadi capability: SingleShot agents. This lets agents perform their work once and automatically exit afterward, conserving system resources.

The mechanism works as follows:

1. An agent declares X-Akonadi-Capabilities=SingleShot in its .desktop file.

2. When launched, the agent does its work.

3. Once finished, it emits a new finished() D-Bus signal.

4. The Akonadi manager listens for this signal and terminates the agent process.

This pattern fits well with agents like the Migration Agent that don’t need to remain active beyond their immediate tasks.

Current Status and What’s Next

Draft merge requests for both akonadi and kdepim-runtime are already open to gather feedback on the SingleShot capability and the updated job tracking approach.

The only remaining issue is that the finished() signal doesn’t seem to shut down the agent as expected when testing through akonadiconsole. Debugging this signal propagation is my focus for the upcoming week. Once resolved, the agent will fully behave as a lightweight, on-demand component.

This week’s changes not only complete the agent’s QtWidgets decoupling but also introduce a meaningful architectural improvement to Akonadi itself—one that may benefit other agents in the future.

Make sure you commit anything you want to end up in the KDE Gear 25.08 
releases to them

Next Dates:  

• July 10 2025: 25.08 Freeze and Beta (25.07.80) tag & release
• July 24 2025: 25.08 RC (25.07.90) Tagging and Release
• August  7 2025: 25.08 Tagging
• August 14 2025: 25.08 Release

https://community.kde.org/Schedules/KDE_Gear_25.08_Schedule 

Welcome to a new issue of This Week in Plasma!

Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This week we continued polishing up Plasma 6.4 in response to feedback. There’s also lots of work to report improving the UI for Plasma 6.5 in a few months, as well as work on larger topics happening in the background that’s still in progress. Stay tuned!

Notable UI Improvements

Plasma 6.4.3

The automatic screen scale calculator on Wayland will no longer give you a default scale factor that’s only a little bit higher than 100%, as these scale factors often result in a lot of blurriness. Now it will instead round the calculated default scale factor down to 100% if it would otherwise be only a little bit higher. (Nate Graham, link)

Plasma 6.5.0

Screencasts of a specific window now also include any popups that the target window creates. (David Redondo, link)

Changed the Bluetooth wizard to not show unnamed devices by default. This should make the list more actionable and faster to parse. (Sebastian Kügler, link)

When you mute the system, changing the volume in any way now un-mutes all playback devices, rather than only the active one. This prevents a situation where a non-default playback device remains muted and therefore plays no sound when you switch to it deliberately, or when the system switches to it automatically for some reason. (Oliver Beard, link)

The pop-up preview for a folder on the desktop that’s empty now displays a placeholder message so it’s more obvious what it is, and that it’s not just some weird broken UI element. (Nate Graham, link)

Did you know that KDE is working on our own virtual keyboard that we hope to eventually replace Maliit? Well, we are! The Plasma virtual keyboard got a lot of development attention recently, making it look better and fixing multiple usability issues. (Devin Lin, link 1, link 2, link 3, link 4, link 5)

The Plasma keyboard isn’t quite ready yet, but we’re pushing it forwards to help it reach that point hopefully soon!

Frameworks 6.16

Sorting by date in the open/save dialogs opened by Plasma or any KDE apps now shows the newest files first, rather than last. (Nate Graham, link)

Notable Bug Fixes

Plasma 6.3.6

Fixed an issue that could cause screen flicker when playing full-screen games after switching focus away from them. (Xaver Hugl, link)

Plasma 6.4.2

Fixed a bug that could cause KWin to crash if you removed some of the keyboard shortcuts for the Task Switcher and then invoked it with any of the remaining shortcuts (for example Alt+Tab). (Vlad Zahorodnii, link)

Fixed a regression that prevented the Global Menu widget’s “Single button” mode from working. (Niccolò Venerandi, link)

Reverted a change made to the Powerdevil power management system that prevented it from running for users whose uid values are extremely low or extremely high. (Bhushan Shah, link)

Fixed a regression that caused the screens on certain TVs to go black when turning on HDR mode but not using the TV’s “Game mode” setting. (Xaver Hugl, link)

Fixed a regression that caused some of KWin’s color-related functionality (HDR, ICC profiles, etc.) to not work properly on screens that actually send correct EDID information indicating they are in sRGB mode by default. (Xaver Hugl, link)

Fixed a regression that caused the animated previews for windows on other virtual desktops and shown in the desktop strip of KWin’s Overview effect to be frozen rather than continuing to update live. (David Redondo and Xaver Hugl, link)

Fixed a weird bug that could cause the popup of a standalone Audio Volume widget (not in the System Tray) to change its size after the screen it’s displayed on turns off and back on again. (Christoph Wolk, link)

Fixed a similar weird bug that could, under certain circumstances, cause your Plasma panels to disappear after the screen they’re displayed on turns off and back on again. (Vlad Zahorodnii, link)

Plasma 6.4.3

Fixed an issue that could cause the built-in RDP server to crash when closing invalid connections. (Harald Sitter, link)

Fixed multiple related issues that could cause certain screens to turn on again after being turned off, or vice versa. (Xaver Hugl, link)

Fixed an issue that caused windows created by their app in a very very special way to fail to open. (Vlad Zahorodnii, link)

Fixed two issues with Orca screen reader integration: one that caused “Learn mode” to not work properly, and another caused the use of “Flat review modifier keys” to unexpectedly insert text in any views that allow text insertion which happened to be focused. (Nicolas Fella, link 1 and link 2)

Plasma 6.5.0

Pressing the Esc key while on the Peers Properties dialog for a Wireguard VPN no longer breaks it. (Ivan Tkachenko, link)

Frameworks 6.16

Fixed two cases case where Kirigami-based apps (including Plasma apps like System Settings and Discover) could crash: one when you scroll with a mouse wheel while animations are globally disabled, and another one when software rendering is in use. (Aleix Pol Gonzalez, link 1 and link 2)

Other bug information of note:

• 2 very high priority Plasma bugs (down from 4 last week). Current list of bugs
• 29 15-minute Plasma bugs (up from 28 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.5.0

Updated the Plasma widget template so that it’s compatible with Plasma 6 and shows modern best practices for widget development. (Tobias Fella, link)

Frameworks 6.16

Improved the system’s ability to detect which GPU is the more powerful one for the purposes of the “Run this program using the more powerful GPU” feature. (Jan Drögehoff, link)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist!

You can also help us by making a donation! A monetary contribution of any size will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

After my initial status blog, I was really surprised to see so much support and excitement about Karton, and I’m grateful for it!

A few weeks have gone by since the official coding period for Google Summer of Code began. I wanted to share what I’ve been working on with the project!

VM Installer

Earlier last month, I was finishing up addressing feedback (big thanks again to Harald) on the VM installer-related MR. I had made some improvements to memory management, bug fixes related to detecting ISO disks, as well as refactoring of the class structures. I also ported it over to using QML modules, which is much more commonly used in KDE apps, instead of exposing objects at runtime.

After a bit more review, this has now been merged into the master branch! This was what was featured in the previous demo video and you can find a list of the full changes on the commit.

SPICE Client

Two weeks ago, I started to get back to work on my SPICE viewer branch. This is the main component I had planned for this summer.

It took a few days to clean up my code that connects to the SPICE display and inputs channel.

However, a lot of my time was spent trying to get a properly working frame buffer that grabs the VM display from SPICE (spice-client-glib) and renders it to a native KDE window. The approach I originally took was rendering the pixel array I received to a QImage which could be drawn onto a QQuickItem to be displayed on the window. It listens to SPICE callbacks to know when to update, and was pretty exciting to see it rendering for the first time!

One of the most confusing issues I encountered was when I was encountering weird colour and transparency artifacts in my rendering. I initially thought it was a problem due to the QImage 32-bit RGB format I was labelling the data as, so I ended up going through a bunch of formats on the Qt documentation. The results were very inconsistent and 24-bit formats were somehow looking better, despite SPICE giving me it in 32-bit. Turns out (unrelatedly), there was some race condition with how I was reading the array while SPICE was writing to it, so manually copying the pixels over to a separate array did the trick.

Here are nice pictures from my adventures!

my first time properly seeing the display… (also in the wrong format) ( •͈ ૦ •͈ )

I have also set up forwarding controls which listens to Qt user input (mouse clicks, hover, keyboard presses) and maps coordinates and events to SPICE messages in the inputs channel. Unfortunately, Qt key event scancodes seem to be in evdev format while SPICE expects PC XT. Currently, I have been manually mapping each scancode, but I might see if I can switch to use some library eventually.

Once I polish this up, I hoping to merge this into master soon. It’ll likely be very slow and barebones, but I’m hoping I can make more improvements later on!

still very lagging scrolling, but now we can read Pepper & Carrot!

What’s Next?

While relatively simple, I noticed my approach is quite inefficient, as it has to convert every received frame to a QImage, and suffers from tearing when it has to update quickly (ex: scrolling, videos).

SPICE has a gl-scanout property which is likely much more optimized for rendering frames and I plan on looking into switching over to that in the long-term.

I also need to implement audio forwarding, sending proper mouse drag events, and resizing the viewing window.

On a side note, I also helped review a nice QoL feature from Vishal to list the OS variants in the installation dialog. I’ve just been memorizing them up until now… :')

Hopefully, once I get the SPICE viewer to a reasonable state, I can get back to improving the installation experience further like adding a page to download ISOs from.

As I mentioned a bit previously, I also want to rework the UI eventually. This means spending time to redevelop the components to include a sidebar, which is inspired by UTM and DistroShelf.

Lastly,

I also wanted to make a bit of a note on my plans and hopes throughout the GSoC period. After working on developing these different components of the app, I started to realize how much time goes into polishing, so I believe that I need to prioritse some of the most important features and making them work well.

Overall, it’s been super busy (since I’m also balancing school work), but it has been quite exciting!

Come join our matrix channel: karton:kde.org

Another thing, I recently made a personal website, kenoi.dev, where I also plan on blogging!

That’s all, thank you for reading :D

Over the past couple of weeks, Timothée Giet has been working on a mock-up tablet and phone friendly UX for Krita. This is a PROTOTYPE, it’s not a working version of Krita. You can’t paint, for instance, or load an image. But you can play with the way the user interface works, and changes depending on orientation and screen size.

The amazing thing, for me, is that unlike our old Krita Sketch, this really looks and feels like Krita, only for mobile touch screens. It’s like this user interface speaks the same language as the desktop interface, krita-ese, I guess you can call it.

Just compare the difference:

There’s also a welcome screen:

It works really well and feels really good and logical. Now keep in mind that this is a prototype, and integrating Krita’s canvas with this prototype is going to be quite tough for really complicated technical reasons — and the prototype doesn’t connect to any of Krita’s code at all. So don’t go expecting this to show in the Play Store any time soon!

But I am still really excited!!! Timothée Giet is doing a great job here!

Today we're releasing Krita 5.2.10! This is a bug fix release. After this release we will focus on releasing Krita 5.3.0, the next feature release, and Krita 6.0.0, the first release based on Qt6.

[!NOTE] Note for users of keyboards with more than 12 function keys. Programs like WeChat regularly inject a spurious F22 keypress to get focus. From 5.2.10, Krita will by default ignore any function key higher than F12. If you have a keyboard or other device sending such keypresses, you can enable them by adding the following line to your kritarc file: ... ignoreHighFunctionKeys=false ...

Bug Fixes

• Raster layer opacity changes now properly clear the animation cache. Bug 499389
• Fix incorrect scaling of animated transform mask values. Bug 469881
• Allow resetting onion skins to default values. Bug 466977
• Fix a crash in clipboard handling. Bug 501560
• Resize canvas: reset the canvas size when toggling the "preserve aspect ratio" button. Bug 452605
• TIFF: Tiff files would append the entire image again on saving again because we didn't truncate the file on saving. Bug 500870
• Fix a crash when autosaving extremely big files.
• Make updating the rulers more responsive during canvas transformations
• Make panning more responsive
• Improve performance of the statusbar
• Fix the transform tool to show reordered layers preview Bug 503201
• OpenRaster: default group layers to non-passthrough mode, following the specitication. Thanks Wareya Na!
• Palettes: use the title field for the palette name for Adobe Color Book palettes
• Fix the brush preview when creating a new preset with canvas mirroring enabled. Bug 501153
• Fix handling of groups in palette files

Download

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

[!NOTE] We are no longer making 32-bit Windows builds.

• 64 bits Windows Installer: krita-5.2.10-setup.exe
• Portable 64 bits Windows: krita-5.2.10.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: from 5.2.10, the minimum supported version of Ubuntu is 22.04.

[!WARNING] 5.2.10 has updated the AppImage runtime, which is known to be incompatible with the old versions of AppImageLauncher. Developers of the AppImage runtime suggest to remove or update AppImageLauncher. See this report: Issue 121 More AppImage troubleshooting info is available here: FUSE

• 64 bits Linux: krita-5.2.10-x86_64.AppImage

MacOS

Note: We're not supporting MacOS 10.13 anymore, 10.14 is the minimum supported version.

• MacOS disk image: krita-5.2.10.dmg

Android

We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.

• 64 bits Intel CPU APK
• 64 bits Arm CPU APK
• 32 bits Arm CPU APK

Source code

• krita-5.2.10.tar.gz
• krita-5.2.10.tar.xz

md5sum

For all downloads, visit https://download.kde.org/stable/krita/5.2.10/ and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

Hi, I'm thrilled to be part of Google Summer of Code 2025 with KDE Community, working under the mentorship of Carl Schwan, Claudio Cambra, and Aakarsh MJ. My project, "Modernize Account Management with QML," aims to enhance the account management system in Merkuro, by transitioning its resource configuration dialogs to QML. This blog post introduces my project and shares the progress I've made in the recent weeks.

About the Project -

Merkuro currently relies on QWidget-based dialogs for managing account resources, which, while functional, are not optimized for modern platform usability, especially on touch devices or diverse platforms. My project addresses this by porting resource configuration dialogs to QML, a modern, flexible, and responsive UI framework, while maintaining compatibility with existing QWidget-based systems. The goal is to create a shared infrastructure that supports both QWidget and QML-based configurations, enabling a seamless transition to modern UI development without disrupting existing functionality.

The project has two main components:

1. Building a Shared Infrastructure: Creating a foundation that supports both QWidget and QML-based configuration dialogs for Akonadi agents, ensuring backward compatibility and scalability.

2. Porting SingleFileResource-Based Configurations: Migrating singlefileresource based configurations, such as the ical, vcard, etc to QML to provide a modern, responsive user experience.

Benefits to KDE Community -

Porting Merkuro's account management to QML offers significant benefits:

• For Users: QML-based dialogs provide a smoother, more intuitive, and visually engaging experience. QML's flexibility supports dynamic and touch-friendly interfaces, making account management more accessible on various devices, from desktops to mobile platforms.

• For Developers: The shared infrastructure improves modularity and maintainability, allowing developers to adopt QML at their own pace without breaking legacy systems. This sets the stage for future QML-based UI development in Akonadi and beyond.

Progress So Far -

1. Implemented Shared Infrastructure for Akonadi

To support both QWidget and QML-based configurations in Akonadi, I developed a new infrastructure in following way:

• AbstractAgentConfiguration: A new base class defining standard methods (load(), save(), etc.) for consistent configuration handling.

• AgentConfigurationBase: Updated to inherit from AbstractAgentConfiguration, ensuring compatibility with existing QWidget-based dialogs.

• QuickAgentConfigurationBase: A new class inherited from AbstractAgentConfiguration, enabling QML-based configurations via shared QML engine for dynamic UIs.

• QuickAgentConfigurationFactoryBase: A factory for QML-based configuration instances, complementing the QWidget factory.

This infrastructure, inspired by KCMUtils, enables Akonadi to handle both legacy and modern UI paradigms seamlessly.

2. Ported Knut Configuration Dialog to QML

I removed QWidget based code and then implemented Knut configuration dialog in QML.

And currently working on porting singlefileresource based dialogs....

Challenges Faced -

The progress came with several challenges that shaped my learning:

• Testing the QML Infrastructure: Validating the new QML infrastructure during development was difficult, as it required a functional QML-based dialog to test fully. I could only verify the infrastructure’s correctness after porting the Knut configuration to QML, which delayed feedback and required iterative adjustments.

• Navigating KDE’s Modular Ecosystem: KDE's ecosystem is vast and modular so understanding each of them is very important. Recently, I spent around hour looking for the Knut configuration dialog in Merkuro only to find out (thanks to Carl) that it actually lives in KOrganizer’s test suite! I was actually unaware of this.

And of course, compiling errors and warnings were always there to keep me company :)

Thank you and stay tuned for the next part, where I’ll share more updates and learnings from my GSoC journey!