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 -------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel