Re: RGSG

[Frederick I Gleef <gleef capital net>]

On Mon, 3 Aug 1998, Dan Kaminsky wrote:
>John Sheets wrote: 
> >Dan Kaminsky wrote:
> >>
> >> >ambiguity between the "file->close" command and the "application->quit"
> >> >command is a terrible thing to invite. i've given you my reasons why
> >> >file->quit is bad, can you give me reasons why application->quit is bad?
> >> >i'm firmly convinced we're doing the right thing by creating a new menu
> >> >for application-wide command choices.
> >>
> >> 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.
> >
> >Say what?  You're saying that we can't implement separate File
> >and Application menus in GNOME because ***Microsoft*** didn't?
> >Where did that one come from?  Could you give us a real reason
> >that refers to the interface itself, and not some other company's
> >specific implementation of one?
> 
> 
> Uh, OK, silly me for tweaking Microsoft a little for one of its biggest
> Interface Hall Of Shame mistakes in history...
> 
> Anyway, the *INTERFACE* reason is that Close now can mean:
> 1)  Close WIndow(whatever that means)
> 2)  Close File
> 3)  Close Application

This is an argument for not using just "Close" where there is any chance
of ambiguity.  There however is no problem using menu items such as "Close
File", "Close Spreadsheet", "Close Project", or whatever is most
appropriate to the application in question.

Close in the sense of "Close Window" is likely to be a minor confusion, as
some window managers include that in their menus.  There is nothing we can
do about this, besides making sure we are clear what we are closing.

Close in the sense of "Close Application" will be a bug.  Curently the
official (i.e. the one on the website) and the RGSG have "Exit" as the
item to make the application go away.  I do not expect this to change.
GNOME users should quickly get used to this use of "Exit", and there is
little likelyhood of confusion.

 
> >> So, since we establish we can't really have both an app menu and a file
> >> menu, we have to pick.
> >
> >I don't think we've established anything here.  Your assertion
> >that we must choose between the two is flawed.  Wanna try that
> >one again, Tex?

We have not established anything of the sort.  Personally, I feel that
having just one menu is easier and more elegant.  Others feel that
separating them out will have less confusion.

 
> Well look what I was responding to, dude:
> 
> >> >ambiguity between the "file->close" command and the "application->quit"
> >> >command is a terrible thing to invite.
> 
> You're right, just because the person I was responding to agreed with me
> does not mean everybody did.  But, yeah, I agree with this statement--I
> don't really think we wanna put users through this mess.
> 
> Uhm, I seem to remember typing up a bunch of stuff regarding the fact that
> Application would need to cannibalize most of the contents of File, and
> since A) The user expects that stuff to be in File, and  B) The stuff in
> File actually expands to full phrases that REFER to Files, the App menu is
> probably not the best idea.

Users from different systems will have different expectations.  Windows
users will expect that stuff to be in the left-most menu, "File." 
Assuming we are not naming the left-most menu "File", I see two scenarios,
neither bad.

A) There is a separate "File" menu, with all the commands to manipulate
   files in it.  The user will look in the leftmost menu, not see the file
   stuff, look in the "File" menu, find what he's looking for, and be
   happy from then on, knowing how to find the functions he needs.
B) There is no separate "File" menu.  The user will look in the leftmost
   menu, and see a bunch of entries like "Open File" or "Close
   Spreadsheet".  The user be happy from then on, knowing how to find the
   functions he needs.

Yes, there are users which don't have this level of compitence with
computers.  However, they genarally have a resource the above user did not
use, someone to ask for help.


> Here, I'll add a third thing...what's the hard and fast delineator for what
> belongs in the file menu and what belongs in the application menu?  By the
> way, I COULD see something like Application->Options or
> Application->Preferences...but when you get to that point, something like a
> Settings menu is more appropriate.

This is a good argument for making just one menu (I'll call it "Program"
as per the RGSG).  You no longer need to figure out whatehr what you want
to do is a "File" function or not.  You just go to the "Program" menu and
select whatever grey area function you want (Program->Print,
Program->Send Document, etc.)

 
> (I think Level 1 standardizing the location of settings is quite key, by the
> way.)

Agreed.  There needs to be two setting standards.  The Application
Settings must be in the leftmost menu, regardless.  Applications that have
file-specific settings should have a standard name and place for that menu
item.  The names of the two need to be need to be distinct, easy to
distinguish, and consistent.

I propose Program->Setup to configure the Application settings.  I
propose Program->Configure X (i.e. Configure File, Configure Project,
etc.) to configure document-specific settings.  Of course, if people
prefer the separate file menu, it would be File->Configure.


> >> 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.
> >
> >Keep a standard because two categories of apps (text & graphics
> >manipulation) use it?  What about the other categories that don't
> >use it?  Should they carry an empty Edit menu?  What exactly do
> >you mean by the "edit standard"?
> 
> Edit Standard = Anything that CAN be copyable SHOULD be copyable.
> 
> OK, lets think about exactly WHAT doesn't support cut/copy:
> 
> Games?  Yes, I listed this as an exception, but then again, screen shots
> should be the copy context here.
> 
> Sound Apps?  Copy active sound.  Allow copy context to be varied in the edit
> menu--have a separated section below cut/copy/paste that allows one to
> select between external apps recieving:
> 1)  A spectrogram
> 2)  A text file describing the app
> 3)  A CORBA embedding, much like OLE works on Windows.
> 4)  Screenshot, with this being just a quick jump to a libgnomeui function.
> (From a style sheet point of view, this is a C2 thing--we should highly
> encourage that anything that CAN by copied SHOULD be copyable.)
> 
> MIDI players?  MOD players?  Process viewers?  Preference screens?  I really
> don't see all THAT many times when, at bare minimum, control-c couldn't copy
> a screenshot.

Whether it's control-c or something else is a keybinding issue I won't go
into here.  My point is the current state of the art in GNOME does not
allow such flexible copying.  It should.  I think it will, but we
shouldn't make something a requirement because we assume it will be the
best way to interface with something not yet implemented.

In my opinion, the GNOME cut/copy/paste feature should be implemented
primarily through means other than menus.  The interface (whether it is
keypresses or mouse clicks or a combination) should be consistant, well
documented and universal.  Then the only programs which actually would
need an "Edit" menu would be those that expand on the GNOME features, and
those that have users that might need to be reminded (eg. a word
processor).

This will also keep the temptation away from putting edit menus in stupid
places (eg. older versions of Microsoft Solitare had an Edit menu).

-Gleef