There are 2 Quit menu options in Quicklist

[Jay Taoko]

For applications such as Tomboy, that feature a dynamic menu item, there are 2 "Quit" menu items. One is provided by the dynamic menu item of the application, and the other by the default menu item of the application launcher.

[Dylan McCall (dylanmccall)]

I have some concern about this patch as seen in lp:unity revision 711. If I understand right, it uses a string comparison and if the quicklist has Quit that item is stuck somewhere else, presented as THE Quit Application item (whether it quits the application or not). Crafty, but will this hold up across different locales? I suggest checking with the translation people, if you haven't already :)

In addition, I think this might be a HIG violation, for what it's worth. We're using the same button to do two different things: normally it closes all windows in an application, but sometimes it forces that application to stop (no matter what it is doing, like "close windows and stop playing"). While the label suggests the latter in all cases, that isn't at all how it works now (bug #616447) so people will get used to the less destructive window closing behaviour and they may be confused - or, worse, hindered - when the button does something else for the odd application that has a quicklist containing "Quit." The end result could be people not using the button because it seems unreliable or erratic.

[Mark Shuttleworth (sabdfl)]

Dylan, I concur. The Unity "quit" option should not be a product of
guesstimation. I would suggest:

 - the Unity launcher "quit" should be the nuclear "kill it properly" option
 - unless the app talks to Unity and says "here's a gracious way to kill me"
 - and even then, Unity should do it the firm way if that doesn't appear
to be working

Mark

[Stefano Candori (cando)]

@Dylan @Mark
After your considerations I've re-looked to my patch and I'm convinced it's written properly ( and DBO too... :) ). I'll try to explain briefly:
1) There are no translation problems because the "Quit" name that I compare it's not the displayed label but only the key of a dictionary ( where the keys are "Launch", "Open in a new window" and "Quit" and the values are the respective Dbusmenuitem objects). In my patch i compare only the labels of these Dbusmenuitems that are already translated.

2) Mark, the patch does exactly what you suggest: if the app has "a gracius way to kill itself" we show its Quit entry, otherwise we show our Unity Quit, that does what is necessary( and if it doesn't it's not related to this bug).

Hoping you've understood, I'm here for any other clarification.

Stefano

[Paul Sladen (sladen)]

Would it be worth having some visible differentiation; between "Quit" and "Force Quit"? The menu could be replaced/overridden by "Force Quit" if the application has not responded within some determined interactivity timeout (typical 100-3000msec, the same timeframe at which the window is dimmed for being non-responsive).

This would subconsciously provide the with the knowledge of whether the delivery mechanism will be a polite WM_DELETE_WINDOW/SIGQUIT or a defenseless kill -9. On platforms such as the iPhone the mechanisms are accessible to the user via the home button, where the user either sends a quick press to return to the main menu and a 2-second button press which kills the foreground application out-right.

[Mark Shuttleworth (sabdfl)]

On 04/01/11 00:08, Paul Sladen wrote:
> Would it be worth having some visible differentiation; between "Quit"
> and "Force Quit"? The menu could be replaced/overridden by "Force Quit"
> if the application has not responded within some determined
> interactivity timeout (typical 100-3000msec, the same timeframe at which
> the window is dimmed for being non-responsive).

It should not require that the user go back and "quit harder". We know
the user wants to quit. Either the app listens, or we force it.

Mark