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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
