activitymanager api

[Chani]

On October 6, 2010 23:27:58 Marco Martin wrote:
> On Wednesday 06 October 2010, Chani wrote:
> > [crap, I suck at reply-to...]
> > 
> > On October 6, 2010 21:57:57 you wrote:
> > > On 6 October 2010 21:40, Chani <chanika at gmail.com> wrote:
> > > > 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();
> > > 
> > > At least in the service, I went for ListActivities(Status)
> > > 
> > > >  activityClosed(id);
> > > >  activityCloseCancelled(id);
> > > 
> > > What about having one method with a bool?
> > 
> > neh, it'd be awkward api. activityClosedOrCancelled()? yuck.
> > plus, everyone but plasma will be ignoring the cancel signal.
> 
> closed*OR*Cancelled?
> what this signal is supposed to do? a closing has been cancelled, an event
> where we are not sure if it was closed or cancelled or? ...
> 

genau. ;)

so the order of events is like this:
*user clicks the stop button on an activity
*plasma requests for it to be closed, and puts a busy animation over that 
activity's icon
*activitymanager kicks off the session-close
*eventually, ksmserver either finishes closing it, or it gets cancelleld. it 
has a signal for each event.
*activitimanager gets ksmserver's signal and re-broadcasts it (so that nobody 
goes depending directly on ksmserver)
*if it was a cancel signal:
**plasma gets rid of the busy animation
*else (it was successfully closed):
**plasma closes its stuff (containments)
**other processes close any extra stuff they had

..hrm. I just realized, the one-process-many-windows processes closing their 
windows after the rest of the session is done is not quite optimal, because 
they don't get the cancel option. a slight ugliness. maybe it's worth 
extending the xsmp protocol, or .. augmenting.. it... - this wouldn't change 
the fact that such processes would have to be activity-aware to behave 
perfectly, just allow them to be full participants in the session when they do 
so...
something to think about for 4.7 :)

a slightly more annoying problem is, xmsp is still very much designed to be 
save-on-close, going so far as to discard anything saved if the save is 
cancelled. :P and the activitymanager's list of activities, like most modern 
things, is saved whenever the config is sync'd to disk. so an xorg crash right 
after opening an activity would be verrrry annoying...

-- 
Chani
http://chani.ca