Re: Huge Batch Reply: Tom

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: Tom Vogt <tom@lemuria.org>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 1:12 PM
Subject: Re: Huge Batch Reply: Tom


>Dan Effugas Kaminsky <effugas@best.com> wrote:
>> >text readout? hm, wonder what that will do to my .eps screenshots...
>> Isn’t text separated from graphics in a postscript file?
>I'd be very surprised.


I had thought this was true, because the last time I opened up an EPS file
in QuarkXPress(we can all feel safe knowing no matter how bad our UI turns
out, it can't be worse than Quark), I could edit text directly.

>
>> >no, it wouldn't - because of the very sentence we are talking about.
>> because
>> >we allow exceptions and because I DO believe that there is NO way to
write
>> >up C1 and C2 compliance levels in a way that allows exotics like kpt to
be
>> >compliant without allowing nearly everything. that's WHY we allow
>> >exceptions.
>> There still have to be things—GC0 things, if you will—we don’t give on.
>> Entries such as “An application that has been exited by the user must
>> actually kill itself within a reasonable amount of time; it may not
remain
>> an invisible process for any reason, including to cause reopens of the
>> application to appear faster.”
>
>this sounds very reasonable, BUT - a) there is no G0 level and b) no matter
>what you come up with, someone WILL find an exception. bet on it.


Style guide is a living document.  If a new application is released that
does something we never thought of but is generally considered very bad, we
put that specific (counter)action on the Experimental Mandatory list.

>
>> >> >aside from that, NOBODY in the whole discussion asked for the removal
of
>> >> the
>> >> >file menu.
>> Renaming the file menu is removing the file menu.
>eh? last time I checked, mv wasn't a symlink to rm.


Where's the file menu?

If it don't say file, it ain't a file menu.  Contents are irrelevant.

>
>
>> >> 1) IBM research--they'll open File up first.
>> >a) they're used to it
>> >b) it's the left most thing. ibm research - the leftmost thing will be
used
>> >most often, no matter what the <beep> it's called.
>>
>> I could see “About” being available before “Open”.  I could see
>>  “Preferences” being available before “Save”.  But “Create Screenplay”
(very
>> appropriate for gnomeprint but not for a spelled out menu) before “New
File”
>> ?!?  uh?
>
>that's why I and others are telling that the screenplay stuff doesn't
belong
>into the Program menu.


Oh OK!  Where does it belong then?  I thought Program took all
apply-to-entire-app stuff, at least that's what Sun's proposal says.

>
>> Wonder if users will treat the gnomeprint as the leftmost icon menu and
file
>> as the leftmost text menu.
>
>do a mockup and tests.


Yup.

>
>
>> >> 3) What happens in a file? Input/Output.
>> >try telling THAT to the secretary.
>> Get stuff in or shove stuff out.  Not too hard.
>I said "try", and you answer by GUESSING.
>
>please DO try. you'll be surprised by the amount of not-understanding.
>("eh? out of what? in? egypt?")


And the alternate?  "What does this footprint do?"  "It lets you do stuff to
the program."  "What does everything else do, then?"  "Also stuff to the
program, but on the data inside the program.  That does stuff to the program
itself, like preferences."  "Why is it a foot?"

>
>> >but IT IS STILL THERE. it can be reconfigured. it will be there no
matter
>> >WHICH file you open.
>>
>> Toolbar is useless without a file.  It’s a file modifier.  Not too
>> illogical.
>
>I give up.
>
>let's put the whole damn app into the file menu, because in the end all of
>it is there to manipulate some files.


Uh, file menu just ships the data in, toolbar/menus modify it.  Ram <-> Ram
I/O is what the file menu, in my mind, doesn't do.  It's Ram <-> External
device, be that hard drive, other computer, printer, whatever.

>
>
>> Uhm it’s kinda worked like this since the first Mac, maybe even the Xerox
>> PARCs.  There isn’t a UI that doesn’t use File:Quit or File:Exit.
>
>then we'll be the first.
>
>I have believed in doing what I thought was right for all my life. true,
>sometimes I payed dearly for that attitude, but mostly it was well worth it
>when I later found out that everyone screwed up except me and the two
others
>who did it their way.


Changing something just because one can and because one is the first ain't
innovation.

>
>> >("Document"->Close - does it need to be spelled out?) or spell it out
>> >("File"->Close Spreadsheet), it does not matter to the point I was
making.
>> >would be cool if you'd answer that point.
>>
>> Point answered:  If Close is spelled out(close document, close active,
>> etc.), File:Close and File:Exit don’t contradict.
>
>eh? File->Close document ? weird construction.


Close Document File.  I thought that made sense at least?

>
>
>> Exit belongs there, definitely.
>>
>> What else?  You act like there’s this wealth of items, yet you only have
a
>> SINGLE ITEM that obviously belongs there.  You’re gonna make the first
>> opened text menu one with a SINGLE OBVIOUS ENTRY?
>
>About belongs there, too (there's some discussion about About containing
>helpful items and such, but if you for just one second join me and 90% of
>users out there and take the dumb approach, then it's ABOUT PROGRAM.
>
>preferences belongs there - see the other mail.


Yeah, OK, three things, one of which is going to be accessed repeatedly.
I'm not sure why this necessarily has more priority than the significantly
more often used File I/O'ers.

Been waiting for someone to tell me.

>
>> I have no problem with an ICON menu that does that—Icons leave the File
menu
>> as the leftmost text menu.  In fact, I PREFER THIS SOLUTION.
>
>it seems the majority does. as long as it works out with users, that's ok
>with me.


Ditto.

>you know, it has been mentioned ONCE that the leftmost location might not
be
>perfect. other than that, everyone kinda agrees. so I guess that one
>mentioning is mood. especially because mockup tests have shown that it's
>terrible anywhere else. in addition, using an icon solves the problem.


I HOPE it solves the problem.  Did we try on the right, with quit on both
sides?  I have a feeling that'd be the most effective if it was only
tried...

>so first you run around screaming bloody murder and then it's just that
>someone cut his finger?


Well, lets see, at least *one* user would control-alt-delete his linux box
if she didn't obviously see a way to quit her app.  That's pretty bad when
there's no good reason for her to have to figure out where it went.

>how about we do it this way in the future: you state EXACTLY what's your
>point and then we'll go and discuss ONLY that point until it's resolved?


I don't see a good reason for the user to have to wonder where file went,
nor wonder where the trusty Exit is hiding.

>
>> actually the correct thing to do.  Should Program have an exit entry.
The
>> only one?  What’s GENUINELY WRONG with having it in File?
>you don't exit a file. simple as that.
>
>> Can we standardize between Exit and Quit?
>we already have. "Exit" has been the standard ever since the official gnome
>style guide version 1.


Exit.  Exit.  Exit.  OK.

>
>> >talking about proposals: how about to hear an actual proposal from you?
>> just
>> >to compare things...
>>
>> Working on a full fledged defense of file, as well as a number of other
>> suckers.
>
>by the time you're finished, the file menu will be as dead as cesar. :)


Doubtful.  I want to have a public conference on this topic.  Lets see how
many people agree with ya.

>
>> I look for logic.  Period.
>isbn 0-87773-446-1


Which?

>
>> >we are getting rid of a file-centric view. we are NOT getting rid of the
>> >"File" menu. we will, however, rename it to something more appropriate.
>>
>> Renaming is killing it.  If I don’t see a file menu, there’s no file
menu.
>> It was removed.  Period.
>
>so you DID symlink mv to rm on your system? tell me how it feels. :)


If I mv c:\WINDOWS to c:\SUCKER, and reboot, the system ain't gonna find
Windows.  I'm sure you can do the same thing to Linux by renaming /dev, or
/proc, or /usr, or any other root dir.

"oh but it's in the same place"  ;-D

>you're guessing again. I don't want to argue guesses.


Burden of proof is on you here.   Why would the user act different in Linux
than we've seen an almost unanimous manner in Windows, myself included?

>
>> I think the fifth level should be pulled out into some kind of
experimental
>> category, because level 5 compliant implies level 1, 2, 3, and 4
compliant.
>>
>> Any argument against?
>
>yes. there is no logical reason to have 5 include everything else.
>especially not 4.


We agree here.  There should *be* no level 5.
>> >I'd say KISS - first letter, bingo.
>>
>> Alt-O?
>
>for what?


Standard open command.

>
>> >hm. maybe the name of the menu shouldn't change per app, but per user
>> >context?
>>
>> ‘cept menu contents won’t change with context...a document menu with
“font”
>> and “paragraph”(two things that relate to documents but have NOTHING to
do
>> with I/O) will become a file menu with “font” and “paragraph”.
>
>not app or document context - user context. every user can have his own
name
>and every theme could. that way you could have a "star trek" theme where
the
>menu names fit in. or a fantasy theme where "file" would really look weird.


<CHEAPDIG><NOTSERIOUS>Not finding the quit entry at warp
nine....</CHEAPDIG></NOTSERIOUS>