Pablo Ariño Muñoz

Weeks 7-13 on Merkuro (GSoC 2025)

Thu, 28 Aug 2025 00:00:00 +0000

Catching Up

These last few weeks have been pretty hectic due to me moving countries and such, so I have not had the time to write a blog post detailing my weekly progress, because of this I have decided to compress it all into a singular blog post talking about all the changes I have been working on and what I plan on doing in the future.

The NewMailNotifier Agent

In the last blog post I wrote I talked about the progress that had been made in the newmailnotifier agent, and that in the following weeks I would finish implementing the changes and testing its funcionality. Well, it ended up taking quite a bit longer as I found that several other files had to also be moved to KMail from KDE-PIM Runtime, and these ones were being used in the runtime repo. The files I have found so far and that I have been looking into are:

newmailnotificationhistorybrowsertext.cpp
newmailnotificationhistorybrowsertext.h
newmailnotificationhistorybrowsertextwidget.cpp
newmailnotificationhistorybrowsertextwidget.h
newmailnotificationhistorydialog.cpp
newmailnotificationhistorydialog.h
newmailnotificationhistorywidget.cpp
newmailnotificationhistorywidget.h
newmailnotifieropenfolderjob.cpp
newmailnotifieropenfolderjob.h
newmailnotifiershowmessagejob.cpp
newmailnotifiershowmessagejob.h

The Troublesome Migration Agent

The MR for the singleshot capability in the Akonadi repo was given the green light and just recently got merged. On the other hand, the MR with the changes for the agent received feedback and several improvements were requested.

Most importantly, Carl brought to my attention how recent MR’s by Nicolas Fella removed the job tracker from the migration agent, thus making it unnecessary to add it as a temporary folder. Both the requested changes and the removal of the folder have been carried out, while doing so I even realized that in my singleshot MR I was missing the addition of the new finished()signal in the agentbase header file, which I have now also added.

After doing this though, I once again focused on the problem that persisted, the singleshot capability not working properly. The migration agent would initialize without issue when running the Akonadi server but would then not shut down after completing its tasks. I knew that the isPluginOpen() method worked in sending the finished signal, as when I opened and closed the plugin the agent would shut down correctly.

With the help of my mentor Claudio, we found that the migrations were in fact not even running, the agent would start but the jobs would fail to run, because of this the logic implemented to signal the finilization of a job never had the chance to run, and thus isPluginOpen()remained untouched.

Furthermore, the way I had designed the plugin letting the agent know that it was open had proven to be insufficient, as the migrations (once we get them to run as intended) would emit the jobFinished() signal after concluding, thus triggering the isPluginOpen() method with the default value of false and shutting down the agent, even if the plugin was still open.

The times the singleshot capability did work (when opening and closing the plugin), we also found that the status would show as “Broken” and the statusMessage as “Unable to start”, which may need changing, but most troubling was that the opening of the plugin would not restart the agent, therefore only showing an empty config window. I need to find a way to either restart from the agent itself or notify Akonadi so that it restarts it when the plugin runs.

Current Status and What’s Next

The GSOC concludes next week and these last few weeks have not seen any MR requests from my part, so my plan is to continue with the refactoring beyond the end of the programme, working on completing the NewMailNotifier and Migration agents, as well as dealing with a few of the agents in KMail, namely MailFilter, MailMerge and the UnifiedMailBox.

As of now, the identified issues to solve regarding the Migration agent are:

The agent not knowing if the plugin is open or closed when emitting the finished() signal.
The migrations not running.
The status and statusMessage showing as “Broken” and “Unable to start”, respectively.
The agent not being able to restart itself.

In the case of the NewMailNotifier:

Complete the transfer of the UI related logic to KMail
Test the D-Bus connection and the modified slotShowNotificationHistory()

While there’s still work ahead, I feel that these weeks have been invaluable in terms of learning, debugging, and understanding the bigger picture of how the different Akonadi agents fit together. The experience has been both challenging and rewarding, and I’m looking forward to tackling the remaining issues with a clearer path forward.

Although GSoC is officially ending, this is just a milestone rather than a finish line, and I’m excited to continue contributing to Merkuro and the KDE ecosystem as a whole.

Week 6 on Merkuro (GSoC 2025)

Sun, 13 Jul 2025 00:00:00 +0000

Refactoring the NewMailNotifier Agent

With the Migration Agent and SingleShot capability now submitted for review, this week marked the halfway point of Google Summer of Code and a natural moment to shift focus to a new component: the NewMailNotifier Agent.

The goal remains the same—decoupling Akonadi agents from QtWidgets to make them lighter, modular, and easier to integrate across different platforms.

Reviewing the Architecture

The NewMailNotifier Agent is responsible for generating notifications when new email arrives. Upon inspection, it became clear that significant progress had already been made in decoupling this agent: its configuration UI was already implemented as a standalone plugin. For the most part, the agent could run headlessly.

However, one lingering QtWidgets dependency remained, preventing full decoupling. The focus this week was to identify and plan its removal.

Identifying the Remaining Dependency

With guidance from my mentor Carl, I located the source of the issue: a method named showNotNotificationHistoryDialog().

This method is exposed over D-Bus and instructs the agent to display a Qt-based dialog listing recent notification texts. While functionally useful, this forces the core agent process to link against QtWidgets—just to open a dialog. This runs counter to the goal of creating lightweight, headless agents.

Refactoring Toward Separation of Concerns

To address this, Carl proposed a more modular design that better separates responsibilities between the agent and user interface components. This week was dedicated to exploring and implementing that approach:

Revising the D-Bus Interface:
Instead of a method that opens a dialog, the agent will expose the notification history as a read-only D-Bus property. This allows client applications to retrieve the data without triggering any UI logic.
Relocating UI Logic to KMail:
The dialog used to display the notification history will be moved from the agent (in kdepim-runtime) to KMail, the primary user-facing application.
Delegating Presentation Responsibility:
Going forward, KMail (or any other compatible client) will read the history data via D-Bus and handle its own UI, enabling greater flexibility and maintaining a clean separation between data handling and presentation.

Current Status and What’s Next

The changes have already been started, and the updated D-Bus interface is mostly in place. Some parts of the dialog code have been moved to KMail, but the full integration still needs testing and a few finishing touches.

Next week, I’ll focus on verifying that everything works correctly, polishing the implementation, and preparing the merge request for review.

Once complete, this will remove the last QtWidgets dependency from the NewMailNotifier Agent and continue the ongoing effort to modularize KDE PIM components.

Week 5 on Merkuro (GSoC 2025)

Sun, 06 Jul 2025 00:00:00 +0000

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:

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.

Week 4 on Merkuro (GSoC 2025)

Sun, 29 Jun 2025 00:00:00 +0000

EteSync Resource Refactoring Merged

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.

Week 3 on Merkuro (GSoC 2025)

Sun, 22 Jun 2025 00:00:00 +0000

Tackling the Migration Agent

For week three, I finished resolving the configuration window issue for the EteSync resource by hiding the default configuration window and programmatically linking the wizard’s “Accepted” and “Rejected” states to the configuration window’s accept() and reject() methods. This ensured that the wizard cleanly replaced the built-in dialog without leaving a “zombie” window behind. I’ve submitted a merge request for these changes so it can be reviewed and integrated upstream.

With that resolved, I moved on to a new and intriguing component: the PIM Migration Agent. This agent is responsible for managing data migrations between different Akonadi versions or formats — a critical part of ensuring smooth transitions when updating KDE PIM components.

And like the other agents and resources, it was time for it to shed its QtWidgets dependency.

Decoupling the UI

Following the established pattern, I began by:

Creating a dedicated UI plugin for the migration agent’s configuration dialog
Removing the old configure() method from the agent’s core logic
Updating the relevant CMakeLists.txt files to support the plugin and cleanly separate UI code from the core agent

However, while this transition was relatively smooth, the plugin-agent communication needed more work to function correctly in this new structure.

Creating a D-Bus Interface for Plugin-Agent Communication

To enable proper communication between the configuration plugin and the migration agent, I created a new D-Bus interface:
org.kde.Akonadi.MigrationAgent

This interface allows the plugin to:

Receive status or configuration information from the agent
Send information back if needed (e.g., configuration changes)

To support this, I also:

Modified the CMakeLists.txt to include the interface and generate the corresponding D-Bus adaptor
Updated both the migrationagent and migrationstatuswidget files to use the new D-Bus interface for interaction

This ensures the plugin can communicate cleanly with the agent without relying on any hard-coded QtWidgets calls or tightly coupled logic.

The KUiServerJobTracker Problem (Still Pending)

While working on the migration agent, I encountered a significant QtWidget dependency:
KUiServerJobTracker, which handles job progress display by showing dialogs and notifications automatically.

Removing it is straightforward — but it leaves a gap:

How should the migration agent report progress to the user once KUiServerJobTracker is gone?

I’m currently exploring options for replacing it, possibly using a D-Bus-based mechanism where the agent broadcasts progress updates and a separate component (e.g., the plugin or a tray app) displays them. This would decouple the presentation layer from the agent’s logic, but I haven’t yet finalized the design.

What’s Next?

My immediate priority is to test the new plugin and the communication logic to ensure everything works correctly. In parallel, I’ll continue thinking through a robust replacement for KUiServerJobTracker, aiming for a modular, widget-free solution.

This week introduced new architectural challenges, but also laid the groundwork for cleaner, more maintainable agents. I’m excited to keep building on this momentum next week!

Week 2 on Merkuro (GSoC 2025)

Sun, 15 Jun 2025 00:00:00 +0000

From Refactor to Functioning Plugin

Hi again! Week two was all about turning last week’s refactored EteSync resource and newly separated configuration plugin into a fully working, stable component. While the initial plugin structure was in place, this week focused on making the pieces actually work together — and debugging some tricky issues that emerged during testing.

Removing QtWidgets Dependencies with KNotification

While testing, I discovered that the original EteSync resource code used QDialog and KMessageBox directly for showing error messages or status updates. These widget-based UI elements are too heavy for a background resource and conflict with the goal of keeping the resource lightweight and GUI-free.

To address this, I replaced them with a much cleaner approach: creating KNotification instances directly. This allows the resource to send system notifications (like “EteSync sync successful” or error messages) through the desktop’s notification system, without relying on any QtWidgets. As a result, the resource is now fully compatible with non-GUI environments and no longer needs to link against the QtWidgets library.

Refactoring Settings Management for Plugin Compatibility

Another major change this week involved how the resource handles its settings.

Previously, the configuration was implemented as a singleton, meaning both the resource and its configuration plugin were sharing a single instance of the settings object. This worked in the old, tightly-coupled model, but caused conflicts in the new plugin-based architecture.

To fix this, I updated the settings.kcfgc file to set singleton=false. This change allows the resource and the configuration plugin to maintain separate instances of the settings object, avoiding interference. I also updated both etesyncclientstate.cpp and etesyncresource.cpp to properly manage their respective configurations.

Solving the “Zombie Window” Issue

One final issue emerged after separating the UI: the configuration wizard now appears in a separate window from the main Akonadi configuration dialog. When the wizard is completed and closes, the original configuration window — now empty and disconnected — remains open.

Clicking buttons on this leftover window causes terminal errors, since it no longer communicates with a valid process. This results in a confusing and potentially buggy experience for users.

What’s Next?

My next task is to figure out a clean way to close the original parent window when the wizard completes, ensuring a smooth and error-free configuration flow. In addition to that, I’ll begin testing the full integration between the EteSync resource and its configuration plugin to ensure everything works correctly — from saving and applying settings to triggering synchronization. This will help verify that the decoupling is both functionally solid and user-friendly.

Week 1 on Merkuro (GSoC 2025)

Sun, 08 Jun 2025 00:00:00 +0000

Kicking Off with EteSync and UI Decoupling

The first week of my Google Summer of Code journey with the KDE community has nearly come to an end, and it’s been an exciting start. As a quick reminder, my project — “Merkuro – Porting Away from QtWidgets” — focuses on making Akonadi components leaner by decoupling their UI from core logic and reducing dependencies on QtWidgets.

Choosing Where to Begin

Originally, I planned to begin with the KMail agents. However, after discussing it with one of my mentors, Claudio, we realized that these agents may benefit from more than just UI decoupling — they are prime candidates to be moved into the kdepim-runtime repository. This would help consolidate Akonadi agents and resources for better maintainability and cohesion.

Because this is a larger architectural change, we agreed it would be more effective to tackle it later in the project.

Refocusing on Resources Within `kdepim-runtime`

I shifted my focus to the agents and resources already in kdepim-runtime. I was pleased to see that some groundwork for decoupling had already been laid for resources like DAV, Google, and IMAP, giving me a solid reference to work from.

With a clear direction, I chose the EteSync resource as my first decoupling target.

Decoupling the EteSync Resource

This week, I carried out three main tasks:

Refactoring the Core Code
I modified etesyncresource.cpp/.h and etesyncclientstate.cpp/.h to remove all UI-related logic previously embedded in the core functionality.
Updating the Build System
I adjusted the CMakeLists.txt to ensure the resource no longer compiles or links against any QtWidgets-based code.
Creating the UI Plugin
I created a dedicated configuration plugin consisting of etesyncconfig.cpp and its corresponding .json metadata file. All UI-related code now lives in this separate plugin.

Testing with Akonadi Console

To verify my changes, I’ve been using the Akonadi Console, a powerful tool that lets developers inspect and manage Akonadi agents and resources in real time. My goal is to ensure the refactored EteSync resource functions correctly in Merkuro, Kontact, and any other application that uses Akonadi.

What’s Next?

Before submitting a merge request, I plan to carry out thorough initial testing to ensure everything is stable and there are no regressions. Once the EteSync resource is confirmed to work cleanly with the plugin, I’ll move on to the next target in the decoupling process.

It’s been a productive first week, and I’m looking forward to building on this momentum in the weeks to come!

Start of GSoC 2025 Journey

Thu, 08 May 2025 00:00:00 +0000

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:

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.
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:

Separate UI from Logic: I’ll move the QtWidgets-based configuration dialogs out of the core agent/resource code.
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.
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.

Welcome!

Sun, 06 Apr 2025 00:00:00 +0000

This is my personal blog, a space where I plan to document various aspects of my work and interests. Thanks for stopping by.

Primarily, this will be a journal for my participation in Google Summer of Code 2025. I’ll be sharing weekly updates on my project: the progress made, challenges encountered, and lessons learned along the way.

Beyond GSoC, I also intend to use this space to write about my ongoing coding journey. This might include notes, tutorials, or thoughts on new technologies I’m exploring, such as Merkuro development, KDE projects, or C++ concepts.

Occasionally, I might also share other thoughts or experiences – perhaps related to tech, books, or other projects I’m tinkering with.

During the GSoC period this summer, I aim to post at least weekly. Afterwards, updates will be more sporadic, as inspiration or notable progress dictates. The style will likely vary, from more technical pieces to informal reflections.

While this blog serves mainly as a personal record, I hope that fellow GSoC participants, open-source enthusiasts, or anyone interested in these topics might find something of value or interest here.

You can find my work and connect on platforms like GitHub and GitLab.

“Code is like humor. When you have to explain it, it’s bad.” – Cory House

Links

Mon, 01 Jan 0001 00:00:00 +0000

Here I curate a selection of my favorite tools, platforms, and resources that I find indispensable in my workflows. Feel free to explore each entry and discover more about the technologies I use and recommend.

Search

Mon, 01 Jan 0001 00:00:00 +0000

Pablo Ariño Muñoz

Weeks 7-13 on Merkuro (GSoC 2025)

Catching Up

The NewMailNotifier Agent

The Troublesome Migration Agent

Current Status and What’s Next

Week 6 on Merkuro (GSoC 2025)

Refactoring the NewMailNotifier Agent

Reviewing the Architecture

Identifying the Remaining Dependency

Refactoring Toward Separation of Concerns

Current Status and What’s Next

Week 5 on Merkuro (GSoC 2025)

A Temporary Solution for Job Tracking

Shedding the Final Dependencies

A New Akonadi Capability: SingleShot Agents

Current Status and What’s Next

Week 4 on Merkuro (GSoC 2025)

EteSync Resource Refactoring Merged

The Job Tracker and a D-Bus Debugging

What’s Next?

Week 3 on Merkuro (GSoC 2025)

Tackling the Migration Agent

Decoupling the UI

Creating a D-Bus Interface for Plugin-Agent Communication

The KUiServerJobTracker Problem (Still Pending)

What’s Next?

Week 2 on Merkuro (GSoC 2025)

From Refactor to Functioning Plugin

Removing QtWidgets Dependencies with KNotification

Refactoring Settings Management for Plugin Compatibility

Solving the “Zombie Window” Issue

What’s Next?

Week 1 on Merkuro (GSoC 2025)

Kicking Off with EteSync and UI Decoupling

Choosing Where to Begin

Refocusing on Resources Within kdepim-runtime

Decoupling the EteSync Resource

Testing with Akonadi Console

What’s Next?

Start of GSoC 2025 Journey

The Challenge: Why Merkuro Needs to Slim Down

My Objective: Decoupling UI for a Lighter Future

Key Deliverables: What I’ll Be Working On

Welcome!

Archives

Links

Search

A New Akonadi Capability: `SingleShot` Agents

Refocusing on Resources Within `kdepim-runtime`