Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: Dan Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 7:47 AM
Subject: Re: RGSG


>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

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


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.

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.

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

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

>John
>