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.
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:
An agent declares X-Akonadi-Capabilities=SingleShot in its .desktop file.
When launched, the agent does its work.
Once finished, it emits a new finished() D-Bus signal.
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.
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!
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:
Krita Sketch, from 2012The main interface Timothee imagined for Krita.
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!
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:
Building a Shared Infrastructure: Creating a foundation that supports both QWidget and QML-based configuration dialogs for Akonadi agents, ensuring backward compatibility and scalability.
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!
This week I learned how to tweak the UI using Qt modules, specifically Qt GUI classes. As someone new to C++ and Qt, I’ve found that official documentation for any new technology is always helpful in understanding the basic concepts and framework. Reading official documentation is like using an encyclopedia—you may not read it cover to cover, but you can search for key concepts to help navigate what you’re trying to do.
Before and After
QPainter
After researching how the Assistant Tool is drawn on the canvas, I thought I could use that same logic to draw on the floating bar. In the process, I found that the Assistant Tool has a lot of nested logic, inheriting different widget classes, and referencing various Kis objects that need to be built. After debugging countless times to find where this tool is drawn, I found the QPainter class. To keep it simple, this class draws lines and shapes in different colors. For now my goal is to display a floating bar.
Files and Implementation
/krita/libs/ui/ kis_painting_assistants_decoration.h kis_painting_assistants_decoration.cpp _ new kis_selection_assistants_decoration.h kis_selection_assistants_decoration.cpp
The files I focused on are in the path above. For organization, I made new files in the same directory. In kis_selection_assistants_decoration, the QPainterPath class is used to build the floating bar. This is slightly different from QPainter, as a QPainterPath object only needs to be created once for complex shapes.
To display and test the floating bar I used kis_painting_assistants_decoration::drawDecoration() method call to call kis_selection_assistants_decoration::drawDecoration().
Conclusion
This week I took a deeper dive into how Krita's UI is structured in Qt. By exploring how the Assistant Tool is created, I learned, I learned how core classes like QPainterPath interact with the canvas. Through this experience, I gained a solid starting point for UI-related work in Krita. There’s still much more to learn and improve on, but seeing a visual element I wrote appear on the canvas was a big milestone!
Contact
To anyone reading this, please feel free to reach out to me. I’m always open to suggestions and thoughts on how to improve as a developer and as a person. Email: ross.erosales@gmail.com Matrix: @rossr:matrix.org
After four months of active maintenance and many weeks triaging bugs, the digiKam team is proud to present version 8.7.0 of its open source digital photo manager.
Improvements in Photos, KRetro and better keyboard navigation
Welcome to a new issue of "This Week in KDE Apps"! Every week (or so) we cover as much as possible of what's happening in the world of KDE apps.
As you might have noticed, the frequency of "This Week in KDE Apps" has not been very consistent lately. Particularly during the summer season, I (Carl) have a lot of social obligations and can't ensure regular updates with the small amount of time I have available. If you are a KDE developer, you can help by contributing your updates to the GitLab merge request on invent. In that respect, a huge thanks to Felix Ernst for doing that already for Dolphin.
Getting back to all that's new in the KDE App scene, let's dig in!
Akseli Lahtinen increased the click area of files and folders in the main view and overhauled their styling. It's (subjectively speaking) a lot prettier now! We are trying to make Dolphin more consistent with other list styles in KDE long-term (25.08.0 - link).
Méven Car added a colorful folder icon chooser to the context menu of folders (25.08.0 - link). The Dolphin context menu can be edited in Dolphin's settings window.
Aleksandr Borodetckii lowered the default scroll speed to follow the globally-configured scroll distance more closely. Scrolling one "tick" with the mouse wheel should now move the view by a similar distance in Dolphin as it does in KWrite. In details view mode we made sure that scrolling moves by full item height (25.08.0 - link).
Gleb Kasachou added a setting to optionally elide long file names at the end instead of in the middle, so when the Dolphin window is too narrow to display “a very long file name.txt”, you can now switch between showing “a very…file name.txt” or “a very long file….txt”. Both of these behaviors have been respectfully criticized in the past, so now everyone can set it to their liking (25.08.0 - link).
Bojidar Marinov fixed a visual bug in the default icons view mode in a livestream, as sometimes the file name would have one row of text outside and below the actual file geometry (25.08.0 - link).
Akseli Lahtinen fixed a long-standing issue that could cause Dolphin to crash while interacting with Samba shares (Frameworks 6.16 - link).
Kai Uwe Broulik fixed another long-standing issue where a random "Examining" popup would appear when connecting to a busy Samba share (25.04.3 - link).
Sune Vuorela made the list of certificates used to sign a PDF update when switching the active backend (GnuPG or NSS) (25.08.0 - link). If Kleopatra is installed and the GPG backend is selected, Okular will now propose to view the certificate details in Kleopatra (25.08.0 - link).
Abdus Sami made the number of items in the recent history configurable (25.08.0 - link).
Pablo Ariño ported the Etesync resource away from directly depending on QtWidgets. This decreases the RAM consumption by around 10MiB for each running Etesync instance (25.08.0 - link). Carl then ported the resource away from KWallet to the more multiplatform alternative QtKeychain (25.08.0 - link).
Merkuro Manage your tasks, events and contacts with speed and ease
Oliver Beard fixed various bugs in Photos. Sharing now works again (25.08.0 - link) and the bookmark functionality is now consistently called "bookmark" in the UI (25.08.0 - link). He also ported the thumbnailbar to a standard toolbar (link).
Carl Schwan made it possible to configure some shortcuts in Photos and added a command bar (25.08.0 - link). Additionally, he made it possible to configure which metadata details are available in the sidebar (25.08.0 - link).
Carl also optimized the main view a bit (25.08.0 - link 1, link 2 and link 3), unified the breakpoint at which desktop and mobile mode are switched (25.08.0 - link), fixed the video player which was not completely ported away from Qt5 (25.08.0 - link), and made a large number of small cleanups and code modernizations (link).
Jean-Baptiste Mardelle added an action to extend and collapse items in the effects and folders view. This allows navigating these views with the keyboard (25.08.0 - link).
Carl Schwan added support for Deutsches Jugendherbergswerk (DJH) email confirmations (25.04.03 - link).
Stephan Olbrich added support for Deutscher Alpenverein (DAV) membership cards (25.04.03 - link).
David Pilarčík added support for extracting multiple tickets from one PDF for Leo Express (25.04.03 - link) and improved the extraction of the luma extractor (25.04.03 - link).
Joshua Goins overhauled the server information page (25.08.0 - link). You can now view your server's extended description, terms of service and privacy policy (when applicable).
Efe Çiftci added a "Show Folders" action to Filelight that allows toggling the visibility of the folder list on the left-hand side of the window (25.08.0 - link).
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
Each contributor makes a huge difference in KDE — you are not a number or a cog
in a machine! You don’t have to be a programmer either. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. Any monetary
contribution, however small, will help us cover operational costs, salaries,
travel expenses for contributors and in general just keep KDE bringing Free
Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
This week, the merge request for the EteSync resource has been reviewed and successfully merged! This marks a key milestone in the project: EteSync is the first resource to be fully refactored, with its UI logic cleanly separated into a standalone configuration plugin.
Based on feedback from my mentors, I made a few final revisions before the merge. One important addition was a .notifyrc file for the EteSync resource. This allows the headless EteSync resource to make use of KNotification for reporting errors or status updates, integrating with the user notification system in a way that doesn’t depend on a UI.
With the resource no longer depending on QtWidgets, and its configuration interface now dynamically loaded, this change contributes to our broader goal of making the Merkuro suite lighter and more adaptable for mobile environments.
After the merge, my mentor Carl checked the memory usage using System Monitor. The improvements were measurable: the EteSync resource now uses approximately 9.5 MiB of RAM, compared to the 22 MiB used prior to the refactor.
The Job Tracker and a D-Bus Debugging
With Etesync out of the way, I turned my full attention back to the PIM Migration Agent. The next logical step was to resolve the KUiServerJobTracker problem I identified last week. My initial plan was to replace it entirely with the progress-reporting tools built directly into Akonadi’s AgentBase. But, while inspecting the Akonadi code, I realized this approach wouldn’t be viable for my use case.
Although AgentBase does provide D-Bus signals for job progress and status updates, these are low-level and do not integrate directly with the system tray or display persistent visual feedback to the user. In contrast, KUiServerV2JobTracker automatically presents progress as desktop notifications or tray-based UI elements.
Still, I implemented the changes, compiled the code, and launched akonadiconsole to test. The good news: the refactored agent started and the configuration plugin loaded. The bad news: they weren’t talking to each other. The D-Bus communication I had set up last week was failing.
This sent me down a debugging rabbit hole. My first hypothesis was that the agent needed its own .service file to properly register on the D-Bus session bus. I spent a good chunk of time creating and tweaking one, but the D-Bus connection simply refused to work as intended. The plugin and the agent remained strangers.
After much investigation I discovered the root cause, and it was a typical environment problem.
akonadiconsole was using the system D-Bus, while my development build of the agent was trying to register on the user session D-Bus managed by my Plasma desktop.
They were on two completely different communication networks! This immediately explained why my custom dbus interface had no effect—akonadiconsole was never even looking for it in the user session. To solve this I ran:
kde-builder - -run akonadictl restart
After this I ran the akonadiconsole once again and this time the D-Bus connection worked as intended.
What’s Next?
For next week, the priorities are:
Re-evaluate the job tracking solution for the Migration Agent, now with a proper understanding of the D-Bus context.
Push forward with removing the final QtWidgets dependencies.
Finalize the plugin-agent communication pathway with reliable, real-time interaction.
The refactor of EteSync and the progress made with D-Bus integration in the Migration Agent continue to move the project toward a more modular and future-proof codebase.
CarlSchwan
@pabarino:matrix.org
Dear digiKam fans and users,
