Change Details

### 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 <a href="https://doc.qt.io/qt-5/qtqml-cppintegration-topic.html">the metaobject system and models</a> 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.

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

### 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 <a href="https://doc.qt.io/qt-5/qtqml-cppintegration-topic.html">the metaobject system and models</a>. 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.