Re: App menu Help/About consistency

[Rick Opper <rickopper gmail com>]

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

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
> > setting.
>
> 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
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list