QML and Plasma -> progress()

[Marco Martin]

On Thursday 16 September 2010, Artur Duque de Souza wrote:
> 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).

yeah, DeclarativeWidget sounds more pimp

> > * 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 :)

for the theme i think probably makes more sense in the root context, since 
makes sense only one exists, the standard way of using qpalettes looks kinda 
weird to me, why should be possible to have 2 instances? it will work, but 
still, weird

> > * 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...

yeah, that's what i'm thinking..

> > * 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.

another thing that need a single implementation in the two places..
i just hope that the same implementation could work there

> > * 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.

i guess we could have a set of qobjects that bind the things that we need in a 
way that qml likes in kdelibs, (at start maybe even copies kept in sync before 
the api is finalized), the bindings of things to qscriptvalues in the plasma 
js bindings seems of not much use here if i understood correctly...
treating this like we can with a "normal" QtScript engine seems a bit out of 
question since is buried pretty deep :/

> > * popupIcon -> needs QIcon bindings for QML
> 
> The binding could just return directly the pixmap maybe?

yeah, for icons this could be good, still have to see how contact did.
for popupicons in particular perhaps could even make sense limiting to names

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

will do


cheers,
Marco Martin