> that's basically how xsmp already works, btw: what I'd be adding is a way to
> tell a process "please save/close only these windows, not everything".
>
> processes that haven't been upgraded to understand that would just ignore it
> and their windows would be closed when *none* of them are ne
> what about an old application doesn't support this tough? abort the activity
> close? trying and hoping?
IMO, aborting close for those would be ugly. If the app doesn't reply,
"true" should be considered as the answer.
It will break the atomicity, but it will be more what-the-user-expects.
Che
> ..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
Yes, it is not really atomic. If there is an option to change xsm
> neh, it'd be awkward api. activityClosedOrCancelled()? yuck.
Ok
> no, it's quite literally impossible. ksmserver won't do it.
> unless you want to implement a queue for activities to sit in and wait for
> ksmserver to handle them... but that'd be overcomplicating things imho.
It is needed for
p.s. It will be no longer a kded module
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On 6 October 2010 21:40, Chani 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
