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:

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

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

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