Re: Porting migration agent away from old configuration dialog

--nextPart5902680.DvuYhMxLoT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Volker Krause <[email protected]>
To: KDE PIM <[email protected]>
Cc: [email protected]
Date: Mon, 30 Jun 2025 17:15:55 +0200
Message-ID: <12696613.O9o76ZdvQC@vkpc5>
Organization: KDE
In-Reply-To: <5935280.DvuYhMxLoT@fedora>
References: <5935280.DvuYhMxLoT@fedora>
MIME-Version: 1.0

On Mittwoch, 25. Juni 2025 00:05:22 Mitteleurop=C3=A4ische Sommerzeit Carl =
Schwan=20
wrote:
> Hi,
>=20
> Pablo (in CC) is currently porting agents and resources away from QtWidge=
ts
> (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:
>=20
> - 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 hav=
ing=20
a (deprecated) copy there until KF7. We'll eventually need that either way =
I=20
think.

> - The second issue and arguably more complicated to fix is that the agent
> and the configuration dialog uses the same instance of KUiServerJobTracke=
r.
> As the configuration view is a view showing the current migration status.
>=20
> I see three ways to fix this:
>=20
> - 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 a=
re
> 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=20
AgentType::capabilities(), with Akonadi shutting it down again automaticall=
y=20
once done. Having the process around after it has done its job is wasteful =
no=20
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
>=20
> - 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 f=
or=20
this, doesn't it? That's usually used to indicate syncing progress but it's=
=20
not limited to that.

Regards,
Volker
--nextPart5902680.DvuYhMxLoT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iF0EABECAB0WIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCaGKqKwAKCRB/lszWTRLS
R6VkAJwPHTfZa/0r29rqtWsAh3u30wOj5wCgitGBTzK6HjijkZgQ7NSuIrYYbT8=
=iWch
-----END PGP SIGNATURE-----

--nextPart5902680.DvuYhMxLoT--