QML and Plasma -> progress()

[Artur Duque de Souza]

On Thursday 16 September 2010 15:11:42 Marco Martin wrote:
> * Plasma widgets are binded in the QML language, with the Plasma.* prefix
> * QGraphicsLayouts are binded in plasma bindings themselves, it is not going
> to be in Qt sadly (but QGraphicsWidget subclasses are starting to work
> pretty well with anchors/positioners as well)
> * Plasma::Svg and FrameSvg are implemented as QDeclarativeItem subclasses
> binded as Svg and FrameSvg. in the future plasma widgets are going to be
> reimplemented in QML probably, those will be the classes for theming

Awesome work Marco! :D

> To use QML in Plasma there are 2 ways:
> * Plasma::QMLWidget -> i a qgraphicswidget that loads a qml file in it, and
> keeps the context/engine/etc, it shortens an otherwise long and repetitive
> task of loding qml files with eventiual parse error management, to be used
> in c++ plasmoids, where complex logic is needed.

Maybe call it Plasma::DeclarativeWidget instead of Plasma::QMLWidget? Not sure 
about this though, just something that crossed my mind (as the Qt item is 
QDeclarativeItem).

> * Theme: defining a Plasma.Theme{} element in qml will obtain an object with
> the Plasma colors as properties  -> should be an object always registered
> to the root context instead? maybe by QMLWidget itself so it is always
> accessible?

Good question. At first I thought about "sure, let's put it directly on the 
root context". Now I'm not so sure again :P But I would say that yes, it may 
be a good idea to already put in the root context :)

> * DataEngine: a Plasma.DataSource{} object can be defined in QML, this
> connects to a single dataengine source, das the source, dataengine and
> interval properties. its Data property is a QDeclarativePropertyMap, that
> maps perfectly DataEngine::Data (but is a qobject, so it can notify all
> properties that change) to access the time  of the tiime dataengine one can
> do: dataSource.data.time .

\o/

>     This can be used from both qml plasmoids or outside. I'm not completely
> sure it's the right approach, alternatively in the dataUpdated of the
> AppletScript QDeclarativePropertyMaps named as something like
> dataengine+source could be assigned to the root context, connections would
> be done in the oncomplete{} slot of qml items. uhm... in the end i think
> i'll leave the DataSource approach.

It seems more "declarative" using the DataSource approach....the other being 
"too magical". I don't think it's bad, but the DataSource approach seems just 
more "declarative" and then I would stick with that...

> * Service: still to be defined, if Plasma.DataSource is the right way to go,
> it could have a service() method that would essentially call
> serviceForSource, then bindings for kconfig would be needed, but this part
> is still fggy to me.

Aaron did something regarding services for the JS bindings. Or at least he had 
a very good idea for it AFAIR.

> * paintInterface -> no, no access to qpainters here (and was quickly
> becoming deprecated anyways)

Another great shoot! +1 for you :D

> * constraintsEvent -> formfactor, location, immutable and currentActivity
> become notifying properties -> property binding

Nice......

> Unique "plasmoid" oject registered in the root context
> shamelessy copied from the js bindings has the following stuff:

This is something that we need to work out: kde-pim also copies some stuff 
from the js binding. If we could share all this stuff it would be great 
(instead of duplicating code). But we need to figure out a way of doing this 
without having proper access to QML's script engine.

> * popupIcon -> needs QIcon bindings for QML

The binding could just return directly the pixmap maybe?

> Should all properties that are not CONSTANT have a NOTIFY signal? that is
> needed for qml property binding.

I think so....

=======

Great job Marco, and awesome mail :) Thanks for the follow up!

Cheers,

-- 
-------------------------------------------------------
Artur Duque de Souza - MoRpHeUz
-------------------------------------------------------
http://claimid.com/morpheuz
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100916/802431c9/attachment.sig