Hi all, Since i've been working a bit in the Plasma Qml bindings I want to share some of the problems i encountered, hoping there is still time to have a soluion to it. Since is something that -iff done right- could be a qiute important part of plasma, is something i want got right from all parts involved before is too late(tm) (even if maybe already is for some things). So what's the status of QML plama bindings right now:
* graphics: -qml has some primitive shae of its own, like rectangles, circles, with gradients and whatnot, they are QGraphicsDeclarativeItems, this means you don't get a decent api if ever accessed by "real" language, have to reimplement all from scratch, don't have the usual properties we're accustomed to since qgraphicswidgets (sucks for using our animations, sucks even for using its -internal- javascript bindings) -it has also its idea of anchor-based layouts: while it's quite nice to use forget any meaningful size hints, so forget it will ever work correctly when a qml plasmoid is in qml layouts But the situation is not ugly as it seems (greatly due Alexis, yay!) now is possible to use quite conveniently any QGraphicsWidget from QML, it's possible to position them with the weird anchor based qml thng, or with QGraphicsLayouts. Now as QGraphicsLayouts there is a little problem, because there aren't bindings for them by default, they a re just shipped as examples, i had to include them in the plasma bindings code (with potential licensing problems since thy are BSD) they were in the default api for a while, then removed :/ Anyways, the result works quite good (well, as buggy as the usual qgrahicslayouts, so uaual administration, yay:) and is actually possible to have a QML root item with a real proper size hint:p Another problem is colors: it is possible to bind/access Plasma colors somehow? probably by binding an object that exposes just that? or could be the SystemPalette element used? (i.e. could it be written to with Plasma theme colors intead?) For graphics i think that's it, once those 2 problems are solved, tha's good to go :) * data: In playground right now there is a working implementation of dataengine bindings: there are a clock and a rss reader that use dataengines and ar written in qml. However there is a (big) problem: in orderto work, it makes use of a private Qt object: QDeclarativeOpenMetaObject: is this going to be private forever? and if yes, there should be -really- another way to export dataengine data, otherwise is not possible for it to go in libplasma, -really- Listviews: the qml rss feed reader in playground uses a qml item view to show the single rss items. Is a thing is really important to me because as i like to repeat every like 3.23 seconds, we don't have a real item view in plasma: while the standard qt views are old ugly and a disaster in proxy widget, on the other hand our implementations again and again are a bunch of duplicate code, quite inefficient and hard to maintain. The one that goes more near to a real item view is the netbook sal, but i really don't want to export it in libplasma, like never ever, because should become feature complete (code way bigger than it is) and would have to be maintained for years. Now while QML views a are quite limited, they are a good looking, not too bad working, easy maintainance compromise, so i would like to use those until (and if) a real graphicsscene based item view will be in Qt. now, common of many engines, when the result is intended for an item view the data is done like that: the engine calls setData with a data in this form: a key whose value is a qvariant that contains a -list- of Data, that would be the news items, the microblog entries, the opendesktop list of people, whatever... in my example qml news reader the binding to a qml list is quite rough and ugly, to say the least, but it works, a good way i think would be to map those lists to models or something like that, or find at least some way to make it less ugly, but the current way would be already prettier than the current completely by hand way :p ok, those were my concerns, i hope you made it till there, what i'm interested is to understand what is possible to do by ourselves, and what would still require modifications to Qt (like now, or maybe too late anyways or never ever) Cheers, Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
