Plasma::Service in plasma2

Sebastian Kügler sebas at kde.org
Thu May 2 14:14:24 UTC 2013


On Thursday, May 02, 2013 15:53:28 Marco Martin wrote:
> following the last monday api review i started to port Service to
> QVariantMap,  in the branch qvariantmapservice in plasma-framework
> 
> ie now you do from c++
> QVariantMap op = storage.operationDescription("retrieve");
> op["group"] = "Test";
> Plasma::ServiceJob *job = storage.startOperationCall(op);
> 
> instead op being a KConfigGroup.
> In QML the api is exactly the same (and this actually fixes it for qml,
> where  kconfiggroup couldn't work in qml2 anymore)
> 
> the branch now works correctly (the storage test passes) there are two 
> problems still tough:
> 
> * the operation description always has an "hidden" key "_name", because is 
> needed in Service::startOperationCall (the operation name was before in 
> KConfigGroup::name())  yhis is not really clean.
> 
> * It may require Plasma::DataEngine::Data back to a QVariantMap as in
> Plasma1  (with all performance issues it means), besides this would be
> needed for qml to directly read DataEngine::Data, the storage service, that
> is always available for use from anywhere in qml, it saves and restores
> Data instances, so QVariantHash, that is not currently usable from QML

On that note, I think I've found a problem in our API review. We're removing 
operationDescription, but that's needed in some UIs to display text on 
actions. Imagine the following: We have a bunch of buttons that map to 
operations in a service, those are dynamically provided by the service. The 
operationDescription is the text on the button. We removed that, so no sane 
way to label the buttons anymore. None that I see, at least. :) This happens 
in the declarative toolbox code.

So put operationDescription back in?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Plasma-devel mailing list