Plasma::Service in plasma2

[Aaron J. Seigo]

On Thursday, May 2, 2013 15:53:28 Marco Martin wrote:
> * 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.

startOperationCall could take a parameter, so:

QVariantMap op = storage.operationDescription("retrieve");
op["group"] = "Test";
Plasma::ServiceJob *job = storage.startOperationCall("retrieve", op);

but then we're making porting work for developers which is bad.

we can't subclass QVariantList as it will eventually get lost somewhere on copy. 

i need to test how well the QObject C++ bindings work with QML.. e.g. if C++ operator overloads 
are proxied through. if so, then operationDescription could return a QObject and it could all be 
masked by that. i have a build going right now that will help me know if this is the case and i will 
test it later today.

otherwise .. i don't see a better solution.

> * 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

meh. well, at least is seems these collection classes got an overhaul in Qt5 so they hopefully 
perform better now. still, sorting is slower than not sorting. ah well .. :/

-- 
Aaron J. Seigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130503/7053840a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130503/7053840a/attachment-0001.sig>