Having overloaded Q_INVOKABLE methods where one takes a superclass of
another is a Bad Idea(TM), since the script engine cannot disambiguate
the methods. associateItem is more accurate than associateWidget for
these methods, anyway.
REVIEW: 104760
QML items derive from QGraphicsObject, but not QGraphicsWidget. We
actually only need QGraphicsObject (for the enabled property).
This allows calling (dis)associateWidget from QML (eg: in javascript
plasmoids) and passing in a QML item.
* allow queueing for un-ready remote services
* always double check that the RemoteServiceJob is really Ok to send; things like operation being ready may have changed, for instance
svn path=/trunk/KDE/kdelibs/; revision=1038181
Remember to document ALL parameters to methods. They may seem obvious to you, but I had to look at the code for at least two of the methods in order to document their parameters correctly.
*waves stick of EBN-ness*
svn path=/trunk/KDE/kdelibs/; revision=908604
these were found while testing the Krazy style checker, which I'm adapting
for the kdelibs style.
svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=870051
* add disassociateWidget() methods
* don't allow a widget to associated with more than one operation
* set the enabled status properly when we associate a widget
svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=852983
CCMAIL:panel-devel@kde.org
Can someone backport this to the 4.1 branch, please? Otherwise no-one can write services in 4.1.
svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=833339
the API. KConfigGroup instances are the whole operation description, not
simply the parameters.
svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=814507
