Hi all,
In the current activities api, we were tried to make a synchronous api to
something that is async - dbus.
It works for the basic use-cases, but it is not pretty. There are a few
methods that are going away in the new version (the previously deprecated
ones), so I've been thinking about changing the api to be async as well.
First of all, the commonly used class KActivities::ResourceInstance is not
affected, so most of the current users (non-plasma) will not need to be
changed.
There are a few possibilities of how this could be done.
- Returning QDBusPendingReply<type>
Really don't like the idea of exporting the fact that dbus is used in the
backend.
Also not really pleasant to use. Creating watchers and all.
- Returning QFuture<type>
Better. (maybe even my favourite of the currently existing solutions)
But, still, creating watchers to wait for it would be PITA for the users.
- Returning KJob
Nice, but it tells nothing about the data being returned and how is it
returned.
- Returning KActivities::Future<type>
That would have a signal when a computation is finished, and a method
.then(SomeFunctor) like boost::future (1.55-dev) and std::future will have in
c++14.
So, the usage could be something like this:
activities.name("someid").connect(this, SLOT(gotName(QString)));
activities.name("someid").connect(this, ThisType::gotName);
activities.name("someid").then([] {
::: // process the name
});
This would be the API-wise the best solution, and a lightweight one (just
wrapping the dbus events).
The issue is that it would be a library-specific class (I'm expecting a
'what about putting it in coreaddons').
So, what do you think?
Ch!
--
I don't really trust a sane person.
-- Lyle Alzado
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
