Porting migration agent away from old configuration dialog

--nextPart6205120.lOV4Wx5bFT
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Carl Schwan <[email protected]>
To: KDE PIM <[email protected]>
Cc: [email protected]
Subject: Porting migration agent away from old configuration dialog
Date: Wed, 25 Jun 2025 00:05:22 +0200
Message-ID: <5935280.DvuYhMxLoT@fedora>
MIME-Version: 1.0

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.

- 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

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

I would tempt to prefer the first solution. But maybe someone has other ideas 
or suggestions :)

Cheers,
Carl
--nextPart6205120.lOV4Wx5bFT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEOf+pPK6cavwhKtACAjJUSCBORSoFAmhbISIACgkQAjJUSCBO
RSo3Nwf/R+3F1AA7LxJfpZiC1jQJDIK4dzpZTjZNuz4IJyT2+XqCj2AKsthLj1KC
htcZvKubcgKVyRPKSaa5rr7WknLa49w/a9+0R6kJV/G4ufKIo8kKtPPJMGQnfrna
RJD7J8Pnj3WJPQzCRRjLfqQP8KvL0nJCA09TaLH8Ub+YLJz6qIdsXuCpJusgzN4u
42mDBEZssIns+qf8aau5AgLKTHA+ClVIjgMH2p3fZaW8a4chlbxAoq2V6SmlTH9g
McYbTNhqR4+CyoNOdm34oS0IcpbEGgllxwRmGyPhY6VldCXs++yI/uk86yXoc0pz
2X5hYdI9Z0i++jhzK0z6OI4XEfEeIw==
=+YVa
-----END PGP SIGNATURE-----

--nextPart6205120.lOV4Wx5bFT--