On Wed, Jul 3, 2013 at 2:44 PM, Sebastian Kügler <se...@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 <se...@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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
