Re: [Usability]Keeping the Quit menu item



On Wed, 2003-03-19 at 18:09, Havoc Pennington wrote:
> On Wed, Mar 19, 2003 at 05:21:48PM -0500, Ettore Perazzoli wrote:
> > 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.

Well you have the application menu, which starts the application.

It is also true, though, that the situation is blurry after you launch
it.  There is no object on the screen that tells you that the
application is running (besides the items in the window list -- which
are per-window but not per-app), sometimes apps have one instance per
document and sometimes they have one instance for all the documents,
etc.

But this is a flaw in the UI, it doesn't mean that we don't have the
concept.

> What would it mean to "start gnome-terminal the application" vs. 
> "open a gnome-terminal window"? Does that mean anything?

In the current situation, gnome-terminal works in a document-centric-y
way, so "starting" or "quitting" the app doesn't make sense.

On the other hand, the terminal could work as an application, like
Terminal does on OS X.  In that case it would make sense; the terminal
windows would be part of one single app, Quit would close all the
windows, Close would close the current window but not quit the app, etc.
 
> 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.

This is not a strict enough definition of an application though. 
Windows can behave in different ways depending on what the programmer
wants them to do.

The real issue is, we don't have a clear model for apps vs. windows vs.
documents in GNOME, we basically leave it up to the programmer to do
something sensible (and often s/he doesn't ;-)).  That's why we have
programs that work in an "application" kind of way, programs that work
in a "document-driven" kind of way, and programs that are somewhat in
between.

Given that there is no common model, it's difficult to make rules like
"no quit menu".  They would not work for all the apps.

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

Traditionally in the Unix world, maybe, but I am pretty sure that the
Windows users out there don't think about processes either when they use
the "Quit" menu.

> 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? 

It depends on whether you want to close the window or quit the app.  :-)

> If there's a
> reason for Evolution, what makes gnome-terminal or nautilus different?

These can both work in an app-like way, with the exception that you
never want Nautilus to quit and hence you don't want a Quit menu item
there.  (Actually, Nautilus already works like that.)

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

Yeah but then in that case the program must be designed to handle the
various process as one single "app".  Otherwise it doesn't make sense.

I think the client leader based grouping is fine.  On the other hand, it
would be useful to have a rule that says that applications should only
run one instance of their process, and thus get rid of the possible
inconsistency between having multiple processes and having a single
process with multiple windows.

Of course, then we would have to add support for this to GTK...

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

Yeah I agree, right now it's a mess.  We should have a better defined
model, and enforce it in the development platform.

> 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. ;-)

I agree 100% -- that's why I brought the issue up.  The discussion felt
backwards to me.  ;-)

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

What is different about it is that you can't define what Evolution is
based on the type of window -- but as I already said, that's not a
correct way to define what the application is in the first place.

-- Ettore

Attachment: signature.asc
Description: This is a digitally signed message part



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