Plasma 2 DataEngine & QML bindings

[Sebastian Kügler]

Hi Mark,

On Wednesday, July 03, 2013 23:33:13 Mark wrote:
> On Wed, Jul 3, 2013 at 2:44 PM, Sebastian Kügler <sebas at kde.org> wrote:
> > On Wednesday, July 03, 2013 11:41:20 Mark wrote:
> >> On Tue, Jul 2, 2013 at 3:18 AM, Sebastian Kügler <sebas at kde.org> wrote:

> >> Just a quick thought. Does it help if you expose the data as a
> >> QAbstractItemModel (or QAbstractListModel)? That way you stay in
> >> control of how the data is represented in the backend without
> >> conversions specifically for QML. It also makes it very easy to use
> >> the data in QML views
> >> 
> >> The downside is probably that you need to have a model class which can
> >> be a big pain to make (specially QAbstractItemModel).
> > 
> > We actually have that, and you're correct: it's a pain. That's mainly
> > because you have to set the rolenames pretty early on, otherwise the data
> > is not visible from QML,
> 
> That is actually the easy part imho :) I was actually referring to
> getting the required re-implementation of some KAbstractItemModel to
> work correctly.
> 
> > and it took us a lot of fixing. I haven't tested this code
> > path in PW2 though.
> > That's in declarativeimports/core/datamodel.cpp
> > 
> > For the simple case, where the dataengine just passes through a smallish
> > set of data, it works now (with QVariantHash), and I've actually already
> > moved on.
> > 
> > I want to change as little code as possible in there, since it's quite
> > brittle and could incur some serious porting costs for everybody.
> 
> understandable. On the other hand, since plasma 2 is roughly a
> complete rewrite, it might be best to to take a thorough look at that
> "brittle" part as well and just fix it up. Or it it the specific
> intention that the current dataengines keep working in plasma 2?

Yes, that's the intention.

These two things are orthogonal, however. In Plasma2's DataEngine API, we want 
to be able to expose QAIMs (or maybe KAIMS, even, I don't know the exact 
differences between in KF5). That "real model" exposure should happen in 
addition to the current QVariant*-based data sets. At least for libplasma2.
In the bindings, we have the DataModel, which does mapping from the QVariant* 
types, and does indeed provide a datamodel, this guy should then expose the 
(Q|K)AIM exposed from the dataengine.

QML code using dataengine is quite brittle, so I'd rather not change a lot 
regarding the current data APIs. Not more than really necessary, anyway. I 
agree that it can be done in a nicer way.

> > Btw, didn't you write a calendarcomponent which we could use in the QML
> > version of the clock? :)
> 
> Ahh, you remembered :) To be honest, it is bit-rotting somewhere. I
> don't even know where to be honest.
> Shall i put it in a scratch repository this weekend? Do note that it
> was not build with frameworks! It was made earlier this year with KDE
> 4.9 i think. 4.10 was about to be released or just released.
> 
> Besides that "minor detail" it still needs some work to be a full
> featured calendar replacement.
> 
> If t hat's all no issue at all then i happily put some life into it
> and push it to a scratch repository :)

That would be nice. The digital clock (and calendar) need porting, and 
especially the calendar seems a bit more complex to do. Whoever takes this on 
should at least find something kind of functional, and not have to start from 
scratch. If you could dredge it up, that would be really nice.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9