unity-design team mailing list archive
Mailing list archive
Re: Quit vs Close - Quicklists
On 24/02/12 08:15, frederik.nnaji@xxxxxxxxx wrote:
100% nod and agree!
On Fri, Feb 24, 2012 at 05:50, Dylan McCall <dylanmccall@xxxxxxxxx
On Thu, Feb 23, 2012 at 12:01 PM, frederik.nnaji@xxxxxxxxx
<frederik.nnaji@xxxxxxxxx <mailto:frederik.nnaji@xxxxxxxxx>> wrote:
> the right-click menu in the launchers for e.g. Empathy or
> an entry labeled "Quit".
> Clicking this item does not make the applications quit, it
> their respective main window.
> Quit and Close should be treated in a distinctive manner, this
> to the mental equivalent of holding on to an appliance and
> appliance back into the tool shelf.
> Does this require further discussion?
There is some discussion about this in a bug report I filed a while
It was sent to ayatana-design in January, so I'm sure someone will
chime in about it in the future. Maybe you'd like to subscribe to that
bug report :)
And I agree "Quit" is flawed for two reasons: it doesn't quit, and the
launcher doesn't really express application state anyway. A running
application will disappear from the launcher when all its windows are
closed, at which point you will be unable to "quit" it from the
launcher. It creates false expectations, and (speaking as someone who
once sold computers to people) those never end well.
this is exactly the right bug to this discussion.
I was surprised to see that there are actually diverging opinions on
To me it is clear that quit means i want to leave something.
If a frontend window is closed, this means quit the visual part of
something, but if the frontend mentally represents an application with
all that it does, then all that it does should also quit if i say so.
If a frontend application interface has not true quit option, it
should not diguise a "close" option by calling it "quit".
This doesn't only confuse the user, it also fools developers into
believing they have already implemented the basic frontend controls