Re: [Usability]Keeping the Quit menu item

[Havoc Pennington <hp redhat com>]

On Wed, Mar 19, 2003 at 05:21:48PM -0500, Ettore Perazzoli wrote:
> On Wed, 2003-03-19 at 16:41, Havoc Pennington wrote:
> > The user model for "Quit" involves the idea of a process. If you don't
> > know what a process is, you can't understand what that menu item does.
> 
> No, this is wrong.  "Quit" involves the idea of an application, not of a
> process.  "Quit" means "quit the application", not "quit the process". 
> In most cases it's the same thing, but the user doesn't care.  He just
> wants to quit the application -- i.e. "Evolution" vs.
> "/usr/bin/evolution".

What do you mean by "the application"?

I agree we have such a concept, but it isn't clear to me that the
concept of application that we have is a thing that can be started and
stopped (or quit, or switched to). I don't have any object on the
screen that represents "the application," that can be operated on.
What would it mean to "start gnome-terminal the application" vs. 
"open a gnome-terminal window"? Does that mean anything?

Is there any reason in the user model to believe that exiting "the
application" will remove anything from memory, or forget any cookies,
or otherwise be a worthwhile thing to do? Would I want to exit all
gnome-terminal windows at once?
 
My idea of an application is something like "a kind of window" or
"functionality provider" - a kind of window to use to view/edit a
particular file, a kind of window that has separate Preferences, a
kind of window that's available when you install a particular piece of
software.

You can't "start" or "quit" a kind of window. "Close all terminal
windows" seems clear, "quit terminal" doesn't really (I bet people
would be surprised if "quit terminal" closed all their terminal
windows - if I added that menu item I bet I'd get flamed hard the
first time someone used it, in fact).

I'm using the terminal as an example precisely because it
traditionally has one process per window, and so people expect Quit to
map to the window. ;-) Which shows that understanding Quit has
traditionally involved processes, not kinds of window or
functionality.

There's simply no reason I see why I'd Quit Evolution for example,
other than to exit the Evolution process. If I don't want an Evolution
window, I'd just close it. Why would I Quit instead? If there's a
reason for Evolution, what makes gnome-terminal or nautilus different?

> And right now GNOME is kind of in between, because while it doesn't have
> the strong application-oriented behavior that the Mac has, it still does
> things like grouping windows by application in the task bar.  So "Quit"
> still makes sense, since it refers to a concept that is exposed in the
> UI.

The taskbar grouping, however, is based on group leader, not window
class (in implementation terms). Though I've been thinking of changing
that since it seems to suck.

GTK maps 1 group leader to 1 process - which means gnome-terminal
--disable-factory affects window grouping. But that is not really
right, and is just because GTK doesn't have the API to fix it.
It should really be 1 group leader per "main window" I think.

If application means "kind of window" that would mean group leader
maps to a document/mainwindow plus transients rather than an
application I suppose.
 
I've struggled with the windows vs. applications thing a good bit with
the window list and metacity (there is an archaeological gconf key for
metacity, /apps/metacity/general/application_based=true).  I don't
think we're 100% clear on what application based would involve or what
"the application" means in GNOME right now. Metacity and the window
list are all window-based right now in most details.

> BTW configuration dialogs are another example of the "application"
> concept being exposed in the GUI; when you open a settings dialog from a
> window, its settings can affect the whole app, not just the window that
> popped up the dialog.

The settings affect all windows of the same kind.


I'd like to clarify the application vs. window based issue more, it's
a useful discussion. We should start on a higher level there though, 
not on the Quit menu item. ;-)

One interesting point is that Evolution is kind of different from some
of the other examples (browser, office suite) - it has this concept of
an "Evolution Window" that can be a calendar or todo list or mailbox,
and I can "File->New->Evolution Window" - and there's a way inside the
app of switching between calendar/tasks/mailbox. While one might
expect to have three apps that are integrated but you switch between
and launch them using the normal desktop mechanisms.

So Evolution introduces another level:

 Kinds of window -> Browser window
                    Terminal window
                    Evolution window -> Calendar
                                        Inbox
                                        Summary

"kinds of Evolution window" is the new class of things introduced.

Not sure this impacts the idea of an application vs. a window
or not, but it does give Evolution a different feel.

Havoc