KActivities library optimizations

[Ivan Čukić]

> > Without the blocking. the hell would break loose - it wouldn't be
> > backwards
> > compatible and every kactivities client would need to be patched.
> 
> according to lxr, that is:
> 
> * plasma-desktop shell
> * activities DataEngine
> * activities Runner
> * powerdevil
> * plasma-mobile shell
> * active web browser
> * kwin
> * tasks plasmoid
> * pager plasmoid
> * SLC

Most of them are easy tasks apart from plasma-desktop and possibly kwin. 
Plasma's activity handling is quite quaint (never got to use these words 
together before :) ). This comes to the talk about the limbo activity - if 
that was implemented in p-desktop and p-device, then we wouldn't have 
problems.

Essentially, we'd need to patch the more complex clients to support the 
special-case of service not running / information not yet retrieved.

> as this is the only way to guarantee no blocking anywhere, i think we should
> seriously consider making this shift in v2 of the library (for Frameworks?)

I agree we should introduce a new library for kf5. Making the partially-
blocking vs report-when-ready switch should be rather easy to do. It could 
maybe be done even before KF5 - the default behaviour would remain the same, 
but the clients that want it, could choose to be completely async.

Though I don't know whether it is actually worth it for the simple api (the 
currently prefetched/cached properties) - the only reason for it to block is 
if the d-bus daemon is screwed (will abstract nepomuk a bit more to make it a 
non issue as well) so the service, as far as the activities list, activity 
data and current activity are concerned shouldn't be able to block.

> at the same time we remove the deprecated calls. having looked at the code

+1

> i see it is marked as deprecated, even ... that at least makes one thing
> easier :)

:)

> > We need data models for it
> sounds good ...

Yup, data models will release us from all the sync/async problems I think. I'd 
even go that far to say that if we leave the current classes as very-rarely-
blocking and do the models, we will have two very convenient apis for both 
apps that don't care about potential blockage and apps that do.

Ch!

-- 
Acting is merely the art of keeping a large group of people from coughing.
  -- Sir Ralph Richardson
-------------- 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/20120905/2e95f76c/attachment.sig>