Huge Batch Reply: Tom

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

Tom:

>you want every app to be responsible for taking screenshots? talk about
code
>redundancy!

Agreed.  Anyway the app shouldn’t have to do anything...the
Program/Gnomeprint menu should be autogenerated and should just call the
Xlab window grab code.

>text readout? hm, wonder what that will do to my .eps screenshots...

Isn’t text separated from graphics in a postscript file?

>c'mon, it's not so difficult. there ARE cases where any justification for
an
>edit menu is at best artificial.

Content-Context Copy isn’t universal.
App-Context Copy is.

More on its way.

>besides - how do you want to hit ctrl-c in an app that doesn't take input?

Corba, or see my upcoming Edit proposal...

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

>although this looks kinda cool, the interface hall of shame says it's a bad
>thing to do. I agree there. we REALLY have to experiment with new users,
who
>- I almost bet - will utterly miss that menu for a long time, especially if
>we don't rename the "File" menu.

Lets look at their reasons...
1) Doesn’t provide any extra info.  Really?  Heh, that gnomeprint IS
clickable...
1) Distracts the user.  FROM WHAT?  FROM THE ITEM THEY’RE HIGHLIGHTING?!?
1) They ignore my commment—this allows multi-word entries; big deal for
internationalization.

>> >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. If there's no file menu,
there's no file menu. What part of NO FILE MENU is not clear?
I asked "What, you want both a Document menu and a File menu" because people
DO want to get rid of the File menu. How the *hell* can I be defending File
if people aren't attacking it?

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

Wonder if users will treat the gnomeprint as the leftmost icon menu and file
as the leftmost text menu.

>> 2) Screenplays make this quite clear(but they make anything clear :-)
>screenplays won't (be played). it's like help - the top three hotline
>questions are usually answered in detail in the online help.

Maybe users will be more willing to open screenplays?  TV generation—users
hate to read, especially off of a glowbox.

>> 3) What happens in a file? Input/Output.
>try telling THAT to the secretary.

Get stuff in or shove stuff out.  Not too hard.

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

>you are right about the first thing. your are WILDELY GUESSING at the
>reason. may I offer another two possibilities? a) because that's how it
>usually works on windoze. b) because it's in the leftmost menu which (ibm
>research) they'll look into first.

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.

Can we standardize GNOME with File:Quit, File::Quit, File->Quit, or
File|Quit?  What do y’all think?  I prefer ::, but heh.

>> Settings belong in an *edit* menu, no? What do you do...you edit
>> settings...
>
><sigh>
>
>forget it.
>
>I'm really not going to discuss this in the amount of space it's taking up
>currently. the line of argumentation has been made clear a couple of times,
>everyone seems to agree. if you don't follow along, maybe it's time to
>accept the majority vote in this one.

There’s a majority opinion on the location of settings?  Didn’t notice.

Anyway, I kinda agree.  I like the idea of preferences(not options) sitting
around in a gnomeprint.

>> >"File"->Close
>> >and
>> >"Program"->Exit
>> >does anyone see any source of confusion there? I don't. your point is
mood,
>> >dan, exactly BECAUSE of the "Program" menu.
>you're nitpicking and avoiding the argument. replace "File" with "Document"
>("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.

Of course File:Close and Program:Exit don’t contradict.

>cut doesn't work in "Program" because you don't cut the whole app, you cut
a
>text OUT OF it. a point might be made for "Help" and I think that's worth a
>discussion. "Exit" belongs there, logic for this has been laid out in
detail
>in other mails. "Close (document)" does not because it doesn't affect the
>app as a whole, only its contents. and so on. this is actually a pretty
>sharp distinction.

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?

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.

>> 2) So where are you going to PUT program, anyway? If it doesn't kill
File,
>> by your own admission it doesn't belong in the left side, and by your own
>> admission you don't want to kill file. But, if it doesn't belong on the
>> left side, and if it doesn't kill File, it really doesn't get most of the
>> advantages "everyone" here seems to want.
>it does not kill file, correct. at this moment it is leftmost of file, but
>there might be a reason to move it somewhere else. this is NOT decided
upon,
>it has been mentioned only ONCE (so you CAN read carefully if you want!).

Gee, if it’s not decided on, you don’t have that consensus you keep talking
about.  (Remember, you’re talking to a MAJOR stickler for details.)  The
location of Program is kinda critical, ya know.

YOUR turn to respond to the point I made.  As I show above, you can’t
win...if it ain’t on the left side, or if it is on the left side, it loses
both ways.

>> 3) The research. Ask some users what they do if there's no Quit. They
>> control-alt-delete. On a Linux box, that's instant shutdown right now.
>> (That needs to change.)
>total bullshit. sorry, but this is so stupid, it hurts.
>
>T H E R E I S A Q U I T
>
>simple as that. question answered.

There’s a quit in the wrong place.

Users DO NOT have a problem with quit inside of file, so you aren’t fixing a
“bug”.  You’re trying to be correct, which is commendable if this was
actually the correct thing to do.  Should Program have an exit entry.  The
only one?  What’s GENUINELY WRONG with having it in File?

Can we standardize between Exit and Quit?

>> 4) Lets say somebody *disagrees* with you about what's a Program menu
thing
>> and what's a File menu thing. Now users are going to have to hunt back
and
>> forth "I wonder where THIS app decided to put print"
>there will be no disagreement. the style guide will lay out in detail what
>belongs into the Program menu. period.

People will follow good ideas.  Ideas that users will be pissed about will
be ignored.

>> Tom, there are more proposals out there than your own.
>right. nearly all are variations, like using an icon instead of the name
>"Program". you introduced the idea of killing file, then keeping file, then
>doing both or nothing.

A bit more in depth than that.  Look around.

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

>> I don't fear dissent. I fear committee rubberstamp.
>I fear that one guy stops the whole show. if there would be any discussion,
>that would be fine. look at the 250k mails today. not much mails that
>weren't either from you or to you, eh?

The Program/File distinction sounds great to everyone.

Strange how nobody really knows what REALLY belongs in Program, besides
Exit...not good for the #1 menu!

I look for logic.  Period.

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

Speaking of file centric, maybe a preview for my white paper, but it’s
better to be file-centric than filetype-centric...oops, now my sound app
supports video, better change the menu again...

>> The way I see it, everything gets shoved into default 99 percent of the
time
>> for 99% of users.
>
>exactly that's the key. the user DEFINES the default. look into the
>archives. keywords: "panel" and "lsm"

User ain’t gonna do any work.  Users don’t even click on a category when
installing stuff in Windows.  They just don’t.  Even I just don’t.  Period.

Is this really something to argue about?  I’ll send you a list of what’s in
my NT start menu...think I have that by choice?  Naw, laziness...and that’s
a relatively easy thing to fix, both before the mess and after.

>> People who refuse to write docs whoever, might still do a screenplay good
>> enough for SOMEONE ELSE to write docs.
>>
>> That's A Good Thing.
>
>point taken. I'm not sure though. we shouldn't encourage screenplays
INSTEAD
>of help files. maybe we should allow it, but we surely shouldn't encourage.

Yeah, I agree...sorta.

I LIKE the idea of really really usable HowTo’s.

>any way to realize this red stuff? it strikes me as being superior to
>screenplays for two reasons in addition to your own: a) it's much easier
>scriptable, without having to be "vorturner" as the germans say. b) it
>allows for interaction, feedback and adjusts itself automatically to the
>speed of the user.

Not a bad idea.  Screenplays could “breakpoint” at each major point and
force the user to “dance along” with the script.  Only issue is how to mark
it up...oh, and there’s no way it could mark up the present user context,
that’d require large amounts of AI.

>this is not a kaminsky law, but maybe you'll accept it still. it's from one
>of my professors. he used to say that EVERY time you write something, there
>is something wrong with it unless you have a "miscellaneous" section.
>
>there is ALWAYS an exception and NEVER a perfect concept.
>
>what you can do is take the exceptions into account and make them at least
>stay within sight.

Accepted, I just don’t like it.

One of those things...justice is impossible, but it’s worth working for(as
long as you have a reasonable concept of Justice...most debaters out there
define Justice as the right thing to do...gee, that’s descriptive).  You’ll
never reach Justice, but you still try to get closer...and closer...and
closer...

>I see your point, but I also see more. for example that people are used to
2
>and that indeed people sometimes exit and expect their work to be saved
(for
>example, my mail-editor is set up that way. when I hit alt-x it saves the
>file, exits and the file is sent as a mail.
>
>I would consider 3 to be a nice option though, subject to user
>configuration. possibly a G3 feature and a gnome-wide setting (i.e.
>identical for all of the user's apps).
>
>
>any comments? if some more people like this, I'll put it into the ideas
>section and maybe further up.

Check out my comments(dual column save selector), but yeah, I like the idea
for an option for Microsoft Word style autosave.

>I like that. L for Level is way too generic. G seems a good compromise.

G3 is a mac.

GC3 is my pick, haven’t heard of anything that competes with it.

>> o 5 Levels of Compliancy per guide.
>
>I think this is already agreed upon.

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?

>the current draft of RSG opts for "exit".

I personally go for Exit.

>what specific reasons are for/against each one? I guess that's something
>only native english speakers can answer.

Quit implies quitting a job, harshly.  You don’t quit most jobs, but you’ll
exit the office.  One closes a door though, not really relevant.

>> The GIMP). Of course, you'll still have to come up with a decent
>> default layout because it takes time to reconfigure everything. Why not
>> implement something like this?
>
>my #1 reason why not is that it won't get used. EVER. not by our target
>audience, the simple user.

Uh no, we’re not making a dumb interface, that’s KDE ;-)  And sysadmins LOVE
power...might assist with getting us high Orange Book certification.

>new users will be afraid of ANY change we make. any and all. it doesn't
>matter, because switching to a new environment they do EXPECT changes.
hell,
>they're usually afraid of all the new stuff if it's just a switch from win
>3.1 to win 3.11

Users have less problems with changes when they have a problem with the way
it’s done now.

My girlfriend was VOCIFEROUS about this. The end result in the SG gets
ignored and apps will just do what I say they should do—have two variants of
quit/exit.

>I'd say KISS - first letter, bingo.

Alt-O?

>as I understand it, they'll still OPEN it most often, no matter what's in
>there. probably for a long time before they learned it.
>it's just that if you search for something, you usually start left. unless
>you have some idea where it might be, off course.

I officially apologize to whoever I was complaining about his favor of
research.

Research RULES.

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

>thinking about xlab recently, I found an idea how to maybe implement macros
>in gnome.
>
>we need gtklab. an xlab-like-thingy that works on the gtk level. something
>that can log all callback function calls, so they can be replayed.
>
>there dan, fetch. :)

Yeah, figgered that out a while ago.  Good to know you agree with me that
this is a Good Thing.

BTW, it’s interesting that we took Marc Vertes by surprise, he thought this
was just a tester app...

>> Irrelevant. I was responding to those who said "Quit or Exit should just
>> send a SIGKILL."
>
>then I guess you've been talking to the air. :)
>
>I can't remember ANYONE saying it should do that. nobody. nada. you've got
>a problem that doesn't exist. good koan.

Sun implied this.  He apologized.  Anyway, if Exit does anything more than
SIGKILL, it has a i/o context...merely checking to see if all files have
been saved is enough.