Activities API

[Ivan Čukić]

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