On Mon, 2013-11-25 at 14:36 +0000, Allan Day wrote:
In general I would say that they indicate that those items shouldn't be in the app menu, since they "are specific to a particular window or view", but I'd be interested to hear how other people would interpret this based on the draft guidelines, and whether they consider them to be useful enough.
"Actions that are specific to a particular window or view, or which act on content within an application window, should not be included." The middle clause is somewhat stronger than previous guidelines, and I think it makes a difference. I interpret that to mean that even if your app is single-instance, you're unambiguously not supposed to put anything that affects the window in the app menu. That's a big step towards making app menus more consistent and minimalist, removing the present conceptual divide between app menus for single-instance and multi-window apps. This means Documents, Rhythmbox, and Calculator need to find a new home for their View settings, for example. It also means we need to be more aggressive in removing actions that affect the window: for instance, many games place Undo in the app menu, and Epiphany puts Reopen Closed Tab there, both of which would need to be moved. I'm also pleased that these guidelines unambiguously address apps like Terminal, which does not currently place Quit in the app menu, and Evince, which does not currently put either Quit or About there. One area that could be clarified is the precise behavior of Quit: should it close the focused window only or all windows of the application (a current inconsistency between some apps), or even all windows on the present workspace? It's easy to forget that you have Web open on workspace three, and accidentally close it in workspace one, which sucks; but if Quit doesn't affect all windows, it's not really a global setting.
Attachment:
signature.asc
Description: This is a digitally signed message part