← Back to team overview

unity-design team mailing list archive

Re: Settled: Re: Quit vs Close - Quicklists


Great decision! If the user "quits", the app has the duty to obey! If that wasn't users' will next time he knows the consequence! Also it should be possible for developers to add a "hide all windows" like "Open new Window" (e.g. Firefox does it).

In my opinion the launcher should work with a higher priority like a "task manager" to be able to kill non-responding apps. For Example: If a (self written) script, tool or program running in a closed loop it's hard to open the "system monitor" or "htop" ... right-click the launcher and quit!

Am 26.02.2012 08:26, schrieb Mark Shuttleworth:
No, "Quit" should quit. It might do so graciously, offering you the chance to save files, but the end result should be that the little triangle disappears altogether; the app is stopped.

Am 26.02.2012 10:02, schrieb Paul Sladen:
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

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

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'.


Follow ups