Re: App menu Help/About consistency

So, an app can be kept running without any windows open then? Like on a
Mac where all windows are closed but not the app? In that case, the
app-menu would have QUIT, the window-menu would have CLOSE and SAVE, but
then which one would have OPEN and NEW? would NEW be split? -> NEW
WINDOW in app-menu, NEW DOCUMENT in window-menu?

just being the devil's advocate... I have often quit my browser when I
wanted to just close the current window. I don't think that's an issue
with QUIT. Quit should kill the app. the X button should close the
window. Maybe the app should quit it's self if there are no windows

If we're going to have apps running with no windows then we need a way
for users to see what's running - as opposed to what's open. QUIT would
need to be both in the app-menu AND the context menu for apps in the
dash... or something like that...

On Mon, 2013-11-25 at 19:56 +0100, Carlos Garcia Campos wrote:
Michael Catanzaro <mcatanzaro gnome org> writes:

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

Exactly, and those are the reason why we don't have Quit at all in Evince.

desktop-devel-list mailing list
desktop-devel-list gnome org
desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]