Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Frederick I Gleef <gleef@capital.net>
To: Dan Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 12:50 PM
Subject: Re: RGSG

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


Agreed.  Level two conformance for spelling these out?  Or do we ban the
simple Close w/ a Level one conformance?

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


B is bad because it thrashes consistency, and A is bad because File
commmands are the *first* thing you use and thus should be the first in
their category along the line.  IBM did the research on this.  By the way,
could somebody provide a link to this research?  Or a ISBN #?

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


Or a screenplay...


>
>> 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 like the idea of File as Input/Output Central.  What part the the phrase
"Program" excludes ANYTHING?

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


You're ignoring Bowie's distinction between options and preferences.
Options are accessed commonly.  Preferences aren't.  The leftmost text menu
*really* should refer to input-output stuff, and thus only *new input
defaults* should hop in there.

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


I'm breaking my own rule here.

My own rule is that I should know how difficult something is to implement
before saying it should be done.

I'm gonna break that with Gnome Copy/Paste.

If GNOME doesn't have a copy/paste command up to par with every other modern
GUI in the past fifteen years, it's dead in the water.

Screenplays are nice.  Runboxes are nice.  File v. Program is nice.  So
what.

If GNOME has no screenplays, eh, it'll still be used.  No runboxes?  Who
cares.  File, Program, who cares, people will still use it.

If the style guide doesn't *MANDATE* *serious* clipboard functionality,
GNOME is dead.  Dead, dead, dead, dead, dead.  I live and breathe copy and
paste.  Yesterday, at the GNOME meeting when Copy/Paste was bugging out on
me, I pissed everybody off and choked hard.

I consider this a non-issue.  We're the GUI people.  Anybody who thinks
copy/paste isn't critical to GUIs isn't a GUI person.  If that makes me an
Interface Nazi as well, feh.  Qt/KDE, Motif, Windows 3.1, Windows 95, MacOS
allllll the way back, BeOS, everybody supports copy/paste.  Last time I sat
down at a CDE station and copy/paste didn't work(don't ask ME why, I was
just the user), I got up and went to a NT station.  It's that simple.

Silly toys like being able to paste sound files into LyX, those I can live
without.  But if text, graphics, and vectors can't be copied to and fro from
one application to another, I don't see a future in GNOME.

So, yes, I break my own rule.  I literally *DO NOT CARE* how difficult it is
to make copy and paste work.  If it's easy, great.  If it's hard, then
something is wrong with the GNOME design.

I'm surprised I have to say this.

That being said, hoping for Qt/GNOME intercopy isn't something I'm so
hopeful on, though it's a Priority Level 2 request out of gnome-dev.  I'm
actually wondering somehow if XLab's functionality could be hijaacked to
handle the copy/paste.

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


Anything that has room for an edit menu should have the edit menu.  Anything
that shouldn't should not.  If you copy solitaire, you should be able to
choose between copying the open cards as text or copying a screenshot.

Solitaire is a bad example.  Chess ain't.