Declarative UI Integration, reprise

[Marco Martin]

On Thursday 24 September 2009, Alan Alpert wrote:
> Hello Plasma Devs,
>
> Firstly, I've just written a blog post about the Declarative UI plasma
> integration ( http://labs.trolltech.com/blogs/2009/09/24/qt-declarative-ui-
> and-plasma/ ). It explains the vision of Declarative UI, as it relates to
> Plasma, and what we hope to achieve with it. So if you don't know why the
> integration exists you might want to read that first.
>
> Thanks for the feedback you gave on the initial Declarative UI plasma
> integration. Between addressing that and a lot of internal feedback an
> awful lot has changed in Declarative UI since then. I've tried to update
> the plasma integration to the modern day, and also cleaned it up a little.
> I think that all the concerns from your previous feedback have been
> addressed (please correct me if I'm wrong) so I'd like any more
> constructive criticism you have. I'll just enumerate some of the key
> changes since last time:
>
> -Declarative UI is using Graphics View, which simplifies the integration
+1
> -Has a simple implementation of exposing the Plasma Widgets in QML (look at
> the examples that have 'Plasma.PushButton { ... }', like picture.qml)
+1
> -Names of most elements have changed, and you need import statements to get
> any items at all.
+1
>
> After one round of changing everything, we're in a more stable period so
> now's a good time to play with the technology. I'm hoping that by now it is
> close enough that you can use it to write plasmoids fine - with the caveat
> that you still need the declarative UI version of Qt (we still haven't
> merged into mainline Qt). It has the viewer plasmoid and QML script engine
> like before, but also has a KineticApplet class that you can subclass, to
> write a C++ applet with a Declarative UI front end (and thus still have a
> conventional settings dialog). The examples are still about the same,

i'm compiling the branch right now, then i'll be able to give more in depth 
look.

just quickly looking at it 2 things comes to my mind:
-in the qml the word Plasmoid is used for the main applet. technically it 
indicates more the packages of scripted plasmoids that can contain the code, 
the desktop file, the graphics etc.. could even make sense there but maybe 
PlasmaApplet would be more correct?

-most important: KineticApplet subclasses Applet, but plasma applets can 
subclass also Containment and PopupApplet, that are in turn Applet subclasses, 
in particular i think about 90% of todays applets are PopupApplets, so it 
should be possible to use it for different types, that wouldn't be possible 
subclassing just KineticApplet.
A solution that comes to my mind is, (even if still keeping the scriptengine 
to do applets -just- with qml) making a widget that will contain more or less 
the code kineticapplet contains, but usable inside normal applets (that could 
or could not have other standard imperative code or other widgets in a normal 
layout, together that one) this would make it yes, more tricky but way more 
powerful.

> you'll have noticed by now that I have little in the way of design talent
> to spruce them up. A picture.qml example has been added, all it does is
> show using plasma widgets and animation in a slightly less useless way than
> the widgets.qml.
>
> I've noticed the discussion about JS bindings for plasma, my interpretation
> is that these allow you to write imperative JS code to setup a
> QGraphicsWidget in the standard imperative way, including writing an

yes, thay are bindings to use the plasma api in a normal imperative way, so no 
overlap. the ones we have right now exposes only a subset that can be 
considered "safe" to use, full fledged ones are planned too.

> imperative painting function. If so then there's no problematic overlap,
> it's just another binding language but please correct me if I'm wrong.
> Mixing imperative with declarative gets confusing easily and needs to be
> handled carefully so I'd rather avoid mixing JS bindings and QML at this
> point. I suspect it would be easy to do, but hard to do well.

i think if we will go with the reusable widget way it should be quite 
straightforward.

>
> I welcome feedback, or any suggestions on how this can be made more useful
> for Plasma. In particular I'd welcome feedback on how we're integrating
> with existing code. I'm hopeful that we can integrate existing items
> without having to re-write anything at all (like the integration currently
> does), without compromising the usefulness of the integration.


-- 
Marco Martin