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