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.

What’s Next?

For next week, the priorities are:

1. Re-evaluate the job tracking solution for the Migration Agent, now with a proper understanding of the D-Bus context.
2. Push forward with removing the final QtWidgets dependencies.
3. 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.