hey guys, some of you may remember me rambling about actvities and session 
support. :) I've actually been working on this recently and I'd like some 
feedback from people who know more about the technologies involved.

now, in my current plan, closing an actvity will go something like this:
*plasma asks actvitymanager kded to close activity Foo, and draws a pretty 
busy-animation for it
*activitymanager figures out which session clients have windows on that 
activity, and asks ksmserver to save those clients under the activity's name 
(I'm glossing over a lot of details here btw)
*ksmserver goes about saving this sub-session (it doesn't actually know that 
it's an activity at all)
*ksmserver reports that it either cancelled, or successfully closed, that 
group of clients
*actvitymanager reports that that activity was closed (or not)
*plasma does its activity shutdown (it's both easier and prettier to do it 
after the windows) - unless it was cancelled in which case it just un-busies.
*context-aware applications may react to the shutdown notice (eg. closing some 
of their resources if they're on multiple activities)

and resuming the activity goes something like this:
*plasma tells activitymanager to switch to the closed activity Foo, which 
implicitly opens it
*plasma loads up its own containment stuff
*activitymanager tells ksmserver to restore that group
*ksmserver happily does so
*kwin somehow magically figures out how to reassociate those new windows with 
their actvities (erm, this part is a bit fuzzy still)
*context-aware applications may react by reopening things they'd closed, or 
telling kwin exactly which windows were on which activities

now, this isn't perfect - a perfect solution doesn't exist here - but I think 
it's close to optimal. :)
we get basic session support for all apps, instantly, regardless of whether 
they're context-aware (which none are, right now).

it's basic in that it's at the client level, not the window level; if a 
process is likely to have multiple windows spread across different activities 
(hopefullly that's just a few, eg. konq, FF and OOo) then it'll need to manage 
the details itself (with the help of KActivityConsumer I'm sure).
another good thing is that ksmserver doesn't need to be tied to activities; it 
just gets this extra little feature of subsessions (two dbus functions, that's 
all), and does what it's told, and maybe that could even become part of XSMP 
someday?

now, something that's less good about this design is that it puts code into 
the activitymanager kded, and ivan was worried about that because apparently a 
crash would take down all of kded and would be Very Bad, and so these kded 
modules are supposed to be very small. I haven't thought of any better home 
for the mapping code, though; it would probably be easier to do from kwin, but 
then you'd need a dbus roundtrip to kwin added into the closing...
the code in question I haven't written yet, but it needs to go something like 
this:

foreach x window:
    if activities contains activityID:
        get clientID
        clientsToSave << clientID
        if activities doesn't contain any other *open* activity:
            clientsToKill << clientID
ksmserver.saveSubSession(activityID, clientsToSave, clientsToKill)

where do you think that belongs... kwin, activitymanager kded, or ksmserver?
and btw... who maintains ksmserver? lubos?

thinking a bit more, maybe kwin could restore its activity associations by 
tracking the clientids - but due to the silly way xsmp is designed, if it 
wants to behave "well" after a crash (or other logout failure) it'd need to do 
some bookkeeping when an activity is about to close (but before it closes)...
maybe such session bookkeeping is better off in ksmserver, maybe it'd be 
better to make ksmserver activity-aware after all... or maybe I should just 
ignore xsmp's lack of autosave :P

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel