Plasma5Support

[Aleix Pol]

Hi Marco,
I'm not sure I fully understand what the plan is there. Why are you
calling it plasma5support? Is it so it can be deprecated?

The second link with the port got lost in the way somehow (you added
the same URL twice). It might help understand what you have in mind.

Including the dependency of the split out code should be fine indeed.
On the other hand, the old DataEngine classes will need to stay to
maintain ABI so maybe the DataEngine classes can also just stay as
they are (?).

I know, it's a bit messy... :/

Aleix

On Mon, Apr 26, 2021 at 12:44 PM Marco Martin <notmart at gmail.com> wrote:
>
> Hi all,
>
> I've been working on splitting dataengines out of libplamsa, as a new library
> called plasma5supoport https://invent.kde.org/mart/plasma5support
> (if we want to throw away other pieces non dataengine we can throw away them
> there too)
>
> It fully works (and a port of the dataengines in plasma-workspace is here
> https://invent.kde.org/mart/plasma5support)
>
> It's still not perfect, as is not totally a drop in replacement yet, which may
> or may not be acceptable: you gave to port also the qml part of plasmoids
> using it by importing the plasma5support qml plugin and replacing all the uses
> of PlasmaCore.DataSource, DataModel and so on.
>
> IT would be fine for out plasmoids, but any 3rd party plasmoid from the store
> using dataengines would be broken once we ship ported plasma-workspace
> dataengines.
>
> I still think it's worth starting this port in plasma5 times in order to have
> the least amount of work to be done in the strict qt6 porting phase.
>
> the only solution i can think of though is including the standalone dataengine
> library in plasma-framework itself, so porting plasmacore.DataSource etc to
> use the new library internally, shich would be a pretty transparent migration
> (that could potentially break 3rd party plasmoids using 3rd-party dataengines,
> but do 3rd party dataengines exist anymore? unlikely..)
>
> --
> Marco Martin