Porting migration agent away from old configuration dialog

[Volker Krause]

On Mittwoch, 25. Juni 2025 00:05:22 Mitteleuropäische Sommerzeit Carl Schwan 
wrote:
> Hi,
> 
> Pablo (in CC) is currently porting agents and resources away from QtWidgets
> (y moving the configuration widgets to a plugin as part of his GSoC
> project. Currently he is looking into the Migration Agent which present
> some interesting issues to fix:
> 
> - The agent relies on KUiServerJobTracker which aside of requiring to be
> ported to KUIServerV2JobTracker also has the issue that this links to
> QtWidgets while not using QWidget itself. I fear since this is in a
> framework this can't be moved to a seperate target but worse case we have a
> copy in PIM and then have a todo KF7 to move that to a seperate target.

This sounds like something that should be fixed in KF, even if it means having 
a (deprecated) copy there until KF7. We'll eventually need that either way I 
think.

> - The second issue and arguably more complicated to fix is that the agent
> and the configuration dialog uses the same instance of KUiServerJobTracker.
> As the configuration view is a view showing the current migration status.
> 
> I see three ways to fix this:
> 
> - Make the migration agent not an agent but a process that is started at the
> start of the Akonadi Server and then shutdown as soon as the migrations are
> runs (if any). Then it's not really an issue if this rely on QtWidgets as
> it's a short lived process. Dependency wise this should still be in the
> kdepim- runtime repo, so not really sure how to elegantly start it from
> akonadi server

That, or keep it an agent but give it a special "SingleShot" flag in 
AgentType::capabilities(), with Akonadi shutting it down again automatically 
once done. Having the process around after it has done its job is wasteful no 
matter how much we optimize it.

> - We maybe don't really need a configuration view for that agent as we
> already have the notifications with progress report via the
> KUiServerJobTracker. But this is only on Linux/Plasma. On other platforms,
> we need
> 
> - Keep it as an agent and have a dbus protocol to communicate the job
> process between the configuration dialog and the agent. This sounds like
> quite some work for a small agent which is not doing anything most of the
> time and even more for a configuration dialog which I doubt most user will
> notice.

If this is only about indicating progress, AgentBase has built-in support for 
this, doesn't it? That's usually used to indicate syncing progress but it's 
not limited to that.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20250630/596f1756/attachment.sig>