I’m thrilled to announce that I’ll be participating in Google Summer of Code 2025 with the KDE community and my mentors Claudio Cambra, Carl Schwan and Aakarsh MJ!

This summer, I’ll be working on the Merkuro suite with a focus on a project called Merkuro – Porting Away from QtWidgets.

The Challenge: Why Merkuro Needs to Slim Down

Merkuro is a KDE application suite, aiming to provide a seamless experience for email, calendaring, and contacts. At its core, it leverages Akonadi, KDE’s powerful PIM data storage framework.

Currently, many Akonadi agents and resources (the components that fetch and manage your data from various services) load their configuration dialogs using QtWidgets. While QtWidgets is a robust UI toolkit, it’s also quite “heavy.” This means these components, by default, include substantial UI code, leading to:

1. Increased Memory Footprint: Each agent/resource can consume an extra 15-20 MiB of RAM just by including these UI elements, even when they’re not actively being configured.
2. Performance Hindrance on Mobile: For Merkuro to truly shine on mobile devices, where resources are often constrained, this overhead is a significant bottleneck.

The goal is to make Merkuro lean, efficient, and perfectly suited for both desktop and mobile environments.

My Objective: Decoupling UI for a Lighter Future

The primary goal of my GSoC project is to refactor these Akonadi agents and resources by decoupling their configuration dialogs from their underlying logic.

The plan is as follows:

1. Separate UI from Logic: I’ll move the QtWidgets-based configuration dialogs out of the core agent/resource code.
2. Dynamically Loaded Plugins: These UI dialogs will become separate, dynamically loaded plugins. This means the core agent/resource can run without loading any UI code unless a host application (like Merkuro or KMail’s settings) specifically requests the configuration interface.
3. Reduced Dependencies: By doing this, we can remove heavy QtWidgets header file inclusions from the core components. For example, we can switch from QApplication (which pulls in all of QtWidgets) to the much lighter QCoreApplication for the agent’s primary functionality.

This separation not only brings immediate benefits in terms of memory and performance but also lays crucial groundwork for the next big step: modernizing the user interface by transitioning to QtQuick/QML. With a clear segregation, future efforts can focus on building sleek, modern QtQuick UIs without wrestling with embedded QtWidgets code.

Key Deliverables: What I’ll Be Working On

Over the summer, I’ll be focusing on several key areas:

• Refactoring Core Components:
  • Targeting specific Akonadi agents in KMail (like archivemail, mailfilter, sendlater agents) and resources in the KDE PIM Runtime (like pop3, imap, google, ews resources).
  • The main task here is to strip out embedded QtWidgets dependencies from their primary functionality.
• Modifying Build Configurations: Updating CMake files to reflect these changes, ensuring unnecessary UI files are not compiled into the core components, and reducing overall dependencies.
• Creating Dedicated Configuration Plugins:
  • Implementing plugin factory classes (conforming to Akonadi::AgentConfigurationBase and Akonadi::AgentConfigurationFactoryBase interfaces). This ensures that host applications can dynamically discover and load these new UI plugins.
  • Providing accurate metadata (via JSON files) for each plugin to integrate smoothly with the existing Akonadi framework.
• Testing and Documentation: Rigorously testing all changes to verify the memory usage reduction and ensure the new plugin-based system works flawlessly on both desktop and mobile. I’ll also be documenting the changes for future developers.