activitymanager api

[Chani]

summary for people who are not ivan:
we were talking off-list about needed additions to activitymanager kded, to 
support the shiny fun session stuff.

the new API that's already agreed on (modulo naming conventions) is:
 void requestCloseActivity(id);
 QStringList openActivities();
 QStringList closedActivities();
signals: 
 activityClosed(id); 
 activityCloseCancelled(id);

a session-close can be cancelled - that's part of the XSMP protocol already.
applications can also hold up the close to ask stuff like "do you want to 
save?"
due to this (and some odd loading delays that I don't want to remove without 
first understanding), ksmserver's saving and loading could take a while - and 
it can't do more than one thing at a time. I'm not certain what parts of this 
should be exposed to the user (via busy-animations) and what should be hidden.

On October 3, 2010 17:23:46 you wrote:
> > I chose "close" for symmetry with "open". stop/start was another pair I
> > considered. :)
> 
> I think start/stop is more natural.

eh, so long as it's something consistent :) I think I've used multiple terms 
in the plasma code, which is annoyingly confusing when I return to the code 
later...

> 
> > > In that case we need a method for returning closing/opening activities
> > > as well :)
> > 
> > parse error.
> 
> Yes, the list. You mentioned the list for running and stopped, but missing
> are starting and stopping. It could be one method with a parameter.

I think that's overkill: we will never have >1 activity in a transition state.

however, because of the blocking nature of the session stuff, it might be 
useful to be able to ask *which* one activity is holding things up by being in 
the middle of an open/close :)

QString busyActivity(); maybe? english doesn't have a good word for "opening 
or closing"/"starting or stopping"
transitioningActivity() ?

> 
> > yeah maybe. I want to think about that some more, maybe ask for some API
> > review. the question is whether to hide ksmserver's slowness, or embrace
> > it and make it easy for stuff like busy-animations to be used.
> 
> I'm for embracing. Some kind of async built-in :)
> 

*thinks*

yes, the busy-animation will be best, so that users can figure out why they 
can't open three activities in a row right away. :)

hrm. this means we will need an activityOpened(id) too, to signal that 
ksmserver has finished opening it and is ready to accept orders again ;)

..it's either that or we do some sort of queuing.

on the other hand, what we don't want is *applications* having to write lots 
of corner-case code to deal with an activity in limbo. how can we make this so 
that app devs still get a nice simple easy-to-use API?

-- 
Chani
http://chani.ca