Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: sun <as387@yfn.ysu.edu>
To: Dan Kaminsky <effugas@best.com>; gnome-gui-list@gnome.org
<gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 9:32 AM
Subject: Re: RGSG


>Dan Kaminsky wrote:
>
>> Well, we can't have file->close in one menu and application->quit in
>> another, if only because microsoft screwed up so much and made "close"
refer
>> to "close window", though they were thinking the user would think ALL IE4
>> windows would close if exit was selected.
>
>i thought we agreed we weren't going to let past mistakes of microsoft
>(or kde or anybody else) dictate what would and wouldn't go into the
>style guide, that we were going to borrow the best from all of these and
>do what's intuitive in spite of prior mistakes, etc. etc. etc.?


PEOPLE LOOK AT THE CONTEXT OF THE MESSAGE I WAS RESPONDING TO.

The damn guy WROTE that inviting confusion between Application->Exit and
File->Close was a bad thing, and I agreed with him, even tacked on another
reason of a company that made a mistake.

>closing all the files in an application is _not_ the same as quitting
>the application. you _can_ have an application (a process) running
>without having any documents or files open by that application. this is
>a pretty basic difference here; we shouldn't have to do any convincing
>that these two menu commands should be kept _separate_. "close" and
>"quit" very clearly mean very different things.


Agreed, though I prefer Exit to Quit. Close (file), Close All (Files), and
Exit (Application File and all children files).

>> So, since we establish we can't really have both an app menu and a file
>> menu, we have to pick.
>
>this is, in fact, _exactly_ what i've been talking about all along, and
>the fact that you think we can't tells me i haven't been doing my job.


I happen to disagree pretty strongly.  I'm gonna do the research though, and
see if what I THINK is going to happen DOES.

>okay. starting again. witness the basic menubar. (see the enclosed
>"mockup.gif")


Couple comments:

So what happens to a project app?  The moment an app lets you conglomerate
numerous files, does Open get shoved over to The Foot?

Let me tell you *WHAT I THINK* a user is going to do as soon as they see
this app.
1)  Where's the help?
2)  Huh?  What happened to quit?  Why can't I get out of here by pressing
quit?  Huh?
3)  [After finding Options]  Where are preferences?  Why aren't options near
preferences?  Why do I ALWAYS have to look around so damn much?

But I'll do the research and get back to you.

Quick note--the foot looks nice, and SHOULD be there, but shouldn't have
those options.  Well, OK, it should have a "Quit Application" button just
like the File menu--that's one piece of redundancy I'll accept.

>> Application->Open...  does this open a new
>> application?  Or a new file?  Application->Save...  does this save the
app's
>> state, or the state of a file?  Application->Import...   Does this import
>> another application?  Or a file inside.  Yes, I agree, application->quit
>> makes sense, though you're still closing all files.  But, then, most
users I
>> see nowadays want to click the X in the corner to deal with it--in
essence,
>> we have an application *bar* nowadays.
>
>as you can see by the enclosed mockups, "open" and "save" don't belong
>in tmfkap, for the very reason you named. similarly, "quit" doesn't
>belong in "file" either. i still don't understand why i'm having such a
>hard time with this.


Because it's so hard to draw the line.  Listen to all the people talking
about projects being on this magical plane above files.  Your mockups are
quite helpful; thank you for doing them.  Unfortunately, they illustrate
exactly what I thought they would:  Key settings are being hidden from the
user.

>> Any app with text requires cut, copy, and paste.  Any app with plain old
>> graphics requires at LEAST copy(copy the clock app and it gives you
either a
>> graphic of the time or the time spelled out).  It's really inapprpriate
to
>> change the edit standard here.
>
>so you've said, and so i've agreed with. now disregard all programs with
>editable text. it's late, i'm getting frustrated, and i refuse to draw a
>picture of an application, say a log monitor program, with "copy" in the
>"entry" menu along with "monitor" and "highlight," because there aren't
>any other sensible choices for an "edit" menu in such a program. (you
>can't paste or delete log entries from a log monitor program).


Hurm.  Valid point.  Suppose an application *ONLY* allows copying.  What to
do with Edit?  Well, Control C should always work, but we could also tack
the GIMP solution--edit in the root menu--on as our standard Edit location,
in addition to wherever it wanted to hang out on the menu bar itself.

>i've already agreed with you on applications that deal with variable
>content. please don't provoke controversy where there is none. please
>look where i'm pointing, instead, and concede that sometimes it may be a
>bad idea to require an "edit" menu, because not all apps are designed
>the same.


I accept that all apps MIGHT not need an edit menu *only* because for some
apps it really *would* be a tremendous waste of space.  You have a point.

Maybe the second menu of any system should always contain the edit commands
at the top?