On Sun, 26 Feb 2012, Jo-Erlend Schinstad wrote:
> Or will the launcher wait a certain amount and then kill it,
Waiting, then killing, is generally how forcible-quit systems work.
You send the application a (polite) signal/request, and if it is not
effected during some $timeout you forcibly terminate the list of
processes belonging to that application.
You may have seen sometimes that when an application stops responding,
its window is faded to grey. This detection is already there to some
extent.
> updates to be sent, etc. This can take some time.
The design desire is likely to be "make this closure process faster
than the Quit threshold". These closure updates are a nice-to-have;
If the power goes off, the kernel crashes, or a digger goes through
the ADSL connection, the closure updates would not be sent either.
If the user has asked that the application to Quit, that's probably
what they should be getting. At the very least I'd expect eg.
Transmission, to stop tying up resources (screen real estate and
disk/memory).
If applications avoid that request still further, by forkbombing new
copies of themselves against the user's will, then I can foresee a
situation where you'd ultimately enforce it with individual sandboxes.
That said, the user is in control here, and applications really should
be designed to respond to the users' wishes, within the temporal
expectations of those users'.
-Paul
--
Mailing list: https://launchpad.net/~unity-design
Post to : unity-design@lists.launchpad.net
Unsubscribe : https://launchpad.net/~unity-design
More help : https://help.launchpad.net/ListHelp
