DataEngines and models

[Marco Martin]

On Tuesday 24 December 2013, Mark Gaiser wrote:
> On Tue, Dec 24, 2013 at 5:34 PM, Marco Martin <notmart at gmail.com> wrote:
> > Hi all,
> > I decided to give a crack to an old pet peeve of mine (and quite a sore
> > point, if we look around in dataengines): integration of dataengines and
> > normal QAbstractItemModels.
> > Now, one could ask why not doing everything as imports of either qobjects
> > with an api or models.. fair enough and there are some reasons:
> > 
> > * we have invested a lot in a big number of dataengines already, their
> > design may be better, but ion most case precisely because they lacked a
> > way to have multi line models
> > * the design of the dataengines is still better for anything that has the
> > data represented with a single item (system monitor, date, battery...)
> > why? * because of its completely async nature, it's too easy exporting a
> > qobject with slow, sync methods
> > * data asked by multiple consumers is shared in the same DataEngine and
> > DataContainer instances
> > * services are neat for things async in nature like authentication on a
> > website or so, where blocking calls is a big no (and reimplementing a
> > similar job or future api every time in every import is meh)
> > 
> > So, in many cases i think that having imported models is just fine, but
> > in other cases would be nice to have dataengines and normal
> > QAbstractItemModels merged in one..
> 
> Hi Marco,
> 
> Lets go back to the beginning here for a second. The "DataEngine"
> principle exists because there was a good need for them in plasma but
> no solution from Qt. Hence DataEngines got created by Aaron if i
> recall correctly. At that point there was nothing else so that stuff
> was the best in it's class and served very well.
> 
> In today's world there is still no alternative to dataengines as they
> where initially designed. However, with the massive move to QML a new
> alternative became possible: QML Plugins.

they're not alternatives since they serve slightly differnt use cases.
making imports is fine, but 

> That leaves us with the question: What to use now? DataEngines or QML
> Plugins. I personally always found the dataengines a bit "magical" and
> hard to find what was possible in a dataengine and how to use it. Granted,
> this is something i can easily live with since i can read the code, figure
> out what it does and get it working.

the big difference was that they didn't support models and their use case was 
*not* the one of models, but it was then forced on it. now is just the same 
thing: implement the model, set the role names, done.


> Also you claim (or complain) about async and models not being async.
> That should not be an issue since models work with signals/slots. If
> data changes you simply notify the model of that. I don't see an
> issue.

no, i didn't say anything about models not being async.
models are async by nature, but other api that you can export in a qml import 
with qobject invokables is sync, unless you implement something job based 
(basically reimplementing dataengines and services from scratch). that's where 
they are useful, not to implement models. that's why that branch makes 
possible to use also a normal, boring model in an existing dataengine.

> I understand that there has been an heavy investment in the dataengine
> area in the past, but now it really seems more sane and clean to go
> for the QAbstractListModel version in a QML Plugin. It's clean and
> simple to use. You only need to describe a list of roles for the users
> to use. If you ask me, that should be the way forward.

for many things yes, but they are not mutually exclusive.
I see imports more as standalone, high quality,stable api public libraries, 
while dataengines more as q quick mean of data fetching.
Since now if you want to use a model in a dataengine you can just make a 
model, it also makes easier to port back and forward, because the 
implementation of the model can be the same.

If somebody wants to do things as imports i'm fine, as long as they guarantee 
the asyncness of the api and to maintain it as it was a public, frozen 
library. This branch is to make it not compulsory in order to have good 
quality models for the data (and you still have advantages, like having one 
single instance of the model, regardless how many views are on it, on how many 
plasmoids)

> 
> For the rest you said below: not commenting on that since i don't know.

kindof needed before commenting on something, isn't it? :p


Cheers,
Marco Martin