Port away from DataEngines
Open, Needs TriagePublic

Description

History

DataEngines were a piece of tech from the KDE4 era. Effectively the idea was to provide an abstract mechanism to expose arbitrary data or plugins to a scriptable format usable by various language bindings. A valid task at the time, but Qt5 provided a much more efficent mechanism to do this capitalising on the metaobject system and models.

DataEngines mostly form a now unnecessary layer of indirection that makes QML code hard to parse and suboptimal to run. They also don't solve the more generic problem that we have other QML consumers wanting the data we are exposing.

We kept with them for Plasma 5 as there's some valid, perfectly working code exposed through them, and have been slowly porting away.

Task

The task isn't to port all existing DataEngines. Some already have replacements under different names, some aren't widely used.

We want to find all existing applets that use DataEngines and make sure there are modern new QML bindings we can port the repsective applets to.

Those bindings should be with their respective framework where applicable, others will need some discussion.

Porting

We don't drop anything in Plasma 5. We can make any new plugins exposing API if needed

For Plasma 6 we don't need this on day 1. We can ship https://invent.kde.org/mart/plasma5support in workspace. But now we *don't* promise compatibility throughout Plasma 6 and can do a slow port.

alex added a subscriber: alex.Mar 14 2022, 6:54 PM

If we were to put the Dataengines code in a compat library as part of Plasma (for internal usage), I would argue that it makes sense to deprecate the DataEngine related methods in Plasma::PluginLoader.