Plasma and QML, considerations

[Marco Martin]

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