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