Plasma 2 DataEngine & QML bindings

[Mark]

On Wed, Jul 3, 2013 at 2:44 PM, Sebastian Kügler <sebas at kde.org> wrote:
> Hi Mark,
>
> 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:
>
>> > I'm looking into our dataengine and relevant QML bindings right now, I can
>> > now load a dataengine and use it from Plasma 2, but I have to convert the
>> > payload (::data() from a QHash to a QVariantMap.
>> >
>> > In src/declarativeimports/core/datasource.*) the data property returns
>> > QHash<QString, QVariant>. This doesn't seem to be consumable from QML,
>> > (javascript code sees a  QVariant(QVariantHash), but I can't iterate over
>> > it, it has no keys, no [] accessors, etc..
>> > Converting it to a QVariantMap instead makes it work from QML, but it's
>> > not
>> > actually what we want to do here. Or is it?
>> >
>> > There's some qscriptvalue magic that I don't understand completely in
>> > dataenginebindings_p.h, is this the necessary glue to do the conversion
>> > automatically (and more efficiently)?
>
>> 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?
>
> 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 :)

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel