Extremely interesting... this will open new possibilities. Will these functionalities implemented into PlasMate, to give developers a simple way to write QML plasma widgets?
Luca Tringali >----Messaggio originale---- >Da: notm...@gmail.com >Data: 16/09/2010 15.11 >A: "Plasma"<plasma-devel@kde.org> >Ogg: QML and Plasma -> progress() > >Hi all, >the status of an AppletScript for writing plasmoids in pure QML is progressing >rather well, i thought to write a detailed status report/documentation before >significative design problems go too far in the implementation, be patient, is >really long, but it can be used as a basis for a future documentation. > >* It is now possible to have packages that specify a main qml file, just like >js plasmoids. > >* 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 > >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. >* QML AppletScript: to write applets completely in QML, (uses a QMLWidget >internally) >* only pure qml applets will have access to the "plasmoid" object? (or, the >plasmoid object could be registered from QMLWidget, only when it is actually >descendent of an Applet, but it would have to be in libplasma, instead of in >workspace/runtime) > >* Package: as in js bindings the package name resolution is accessible from >plasmoid.file() > >* 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? > >* 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 . > 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. > >* 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. > >* Something else forgotten? > > >Here is the status of the support to Applet properties and methods: > >== Methods that the ql applets should be able to reimplement: == > >* paintInterface -> no, no access to qpainters here (and was quickly becoming >deprecated anyways) > >* constraintsEvent -> formfactor, location, immutable and currentActivity >become notifying properties -> property binding > >* dataUpdated: DataSource qml item: alternative is to set a >QDeclarativePropertyMap on dataupdated -> but would be good to use it also in >c++ plasmoids > >* configChanged() -> qml applet reimplements configChanged() function in root >Item > >* popupEvent() -> qml applet reimplements popupEvent() function in the root >Item > >== Plasmoid functions/properties == > >Unique "plasmoid" oject registered in the root context >shamelessy copied from the js bindings has the following stuff: > >--properties (AppletInterface): > >* aspectRatioMode >* formFactor NORIFY formFactorChanged() >* location NOTIFY locationChanged() >* currentActivity NOTIFY contextChanged() >* shouldConserveResources >* activeConfig >* busy >* backgroundHints >* immutable NOTIFY immutableChanged() >* userConfiguring >* apiVersion CONSTANT >* rect >* size > >--properties (PopupAplletInterface): > >* popupIcon -> needs QIcon bindings for QML >* passivePopup >* popupWidget -> is it useful there? > >Should all properties that are not CONSTANT have a NOTIFY signal? that is >needed for qml property binding. > >--methods (AppletInterface): > >* void setFailedToLaunch(bool failed, const QString &reason = QString()) >* void setConfigurationRequired(bool needsConfiguring, const QString &reason = >QString()) >* void setAction(const QString &name, const QString &text, > const QString &icon = QString(), const QString &shortcut = >QString()); >* void removeAction(const QString &name); >* void resize(qreal w, qreal h); >* void setMinimumSize(qreal w, qreal h); >* void setPreferredSize(qreal w, qreal h); >* QVariant readConfig(const QString &entry) const; >* void writeConfig(const QString &entry, const QVariant &value); >* QString file(const QString &fileType); -> qml already can read files only >from subdirectories of the main script, i still prefer package even tough >could package return paths unreadable from QML? >* QString file(const QString &fileType, const QString &filePath); >* QObject *findChild(const QString &name) const -> useless? >* Plasma::Extender *extender() const; -> won't be possible to do much with >extenders: to set extenderitems in QML should be possible to have qml items >out of the root object i think (and only a single root is possible) > >--methods (PopupAppletInterface slots): >* void setPopupIconByName(const QString &name); >* void togglePopup(); >* void hidePopup(); >* void showPopup(); > >Cheers, >Marco Martin >_______________________________________________ >Plasma-devel mailing list >Plasma-devel@kde.org >https://mail.kde.org/mailman/listinfo/plasma-devel > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel