Re: RGSG

[sun <as387 yfn ysu edu>]

Dan Kaminsky wrote:

> As for defaults, default settings define how a new file is input into the
> application.  We're still in I/O land.

point is, i don't want to limit the file menu to i/o because sometimes
there _will_ be some things that need to be changed there that don't
specifically deal with i/o. we need to quit splitting hairs on issues
like whether or not * is i/o-related because that's not what should
dictate its placement: the _scope_ of the command is. application-wide?
stick it in tmfkap. document-wide? stick it in "document" (or "file" or
whatever).

> And exactly what prevents you from putting "new session" inside of file...a
> "metafile" is just another file, you know.  And that's ALL a project is,
> just another metafile, just another file, just another piece of guidance for
> I/O.

all i'm proposing is to change the name of the menu to reflect what the
file _contains_ (in a general sense) so the user can directly relate to
it, rather than through a metaphor. how the user's data physically
resides on storage (a single file or a collection of files, or a
database, or whatever) should be transparent to the user.

i only propose this because it's user-friendly for the computer to talk
to the user on the user's terms, using the user's vocabulary, as opposed
to making the user learn the computer's terms and its own specialized
vocabulary.

i will say no more on this topic. quite a few on the list have gotten
this so far; i am agreeing with tom that you are only trolling now for
"devil's advocate" sake.

> >please present an argument that proves using concrete terms makes the
> >interface harder to learn.
> 
> Well...
> 
> 1)  Keyboarding.  Spoke about that earlier--keyboard changes for each app ->
> harder to learn.

this needs to be discussed on the list: we have two options for keyboard
shortcuts. which is better?

1. each menu has a keyboard shortcut, like windows and kde:
alt-<firstletter> drops down that menu. the arrow keys and "enter" can
be used to select the appropriate command.

2. only the items _in_ the menus have shortcuts, at the programmer's
discretion. using keyboard shortcuts won't drop down a menu, just
execute the command, mac-style.

and dan, the answer here is that if we choose to go with #1, then the
first menu after tmfkap will have the keyboard shortcut
alt-<firstletter>, whether it be "file," "session," or "document."

if we use #2, then the title of the menu doesn't matter, because
"ctrl-s" will always be save, "ctrl-a" will be save as, and "ctrl-w"
will be close [window], regardless of what the menu is called, and
regardless of whether we're saving documents, spreadsheets, graphics, or
files.

> >i don't think we're going to get it past the rest of the group, though.
> >yes, it makes logical sense, but it _is_ a good idea to present help to
> >new users immediately, on-screen, without requiring any mouse clicks or
> >keystrokes to be discovered.
> 
> Oh, heck yeah it's a great idea for new users, but why not allow experts to
> theme away any menu entitled help all the way into the gnomeprint?  This is
> a programmatic issue...if it's easy to do, cool, but no big whoop if it's
> not doable.  GO/G4 in my book.

right, easy enough to leave this user-configurable. so "help" would go
into tmfkap too if the user sets that among his global gnome settings.
cool.

> >> Quit is not a kill process, and I would scream bloody murder if it was.
> >
> >start screaming, buddy, because here's where i prove you wrong.
> >scientific proof you can use on your own desktop. ready?
> >
> >1. run the gimp.
> >2. create a new picture.
> >3. scribble some stuff in the picture.
> >4. go into a console or xterm and type "ps aux | grep gimp"
> >
> >see? gimp is a currently running process.
> 
> I'm with you so far.
> 
> >5. right-click in your newly scribbled picture to bring up a menu.
> >6. choose "save" from the "file" menu, give your picture a name, and
> >save it to your hard drive.
> >7. right-click in the picture again, and this time choose "close" from
> >the file menu.
> >8. go to a console or xterm and type "ps aux | grep gimp"
> >
> >we still have a process running, right? okay, we just closed a data
> >file, said "i'm done with all this stuff," and got rid of it. however,
> >the process is still running. this is a good thing, because guess what:
> 
> Uh, ok, we have an app open with 0 files.  That I have 0 files open isn't a
> bad thing...
> 
> >9. woops, you changed your mind and want to make some changes to that
> >picture. or you want to start a new picture. or you want to open a
> >different picture. doesn't matter. click on "file" in the toolbar and
> >choose "new" or "open" as appropriate.
> >10. select your document (if you chose "open") and make some changes to
> >it.
> >11. right-click in the picture and select "save."
> >12. go into a console or xterm and type "ps aux | grep gimp" and make a
> >note of the output.
> >13. go to the "file" menu and choose "quit."
> >14. go into a console or xterm and type "ps aux | grep gimp"
> >
> >how did the output from step 14 differ from the output from step 12?
> 
> You saved.

so what are you saying here: you're surrendering to me here because you
acknowledge the _difference_ between saving and quitting?

the two are still different. we agree to this below. i've already stated
my case that quit must give the _option_ to save, but the two functions
are still entirely different and this procedure for testing proves it.
the argument, therefore, still stands.

> Why should I scream?  You saved.  Quitting didn't kill any unsaved material.

hai, so desu. and so i have successfully proven that quitting and saving
are separate functions of the program, regardless of whether one has the
ability to redirect you to the other.

> >oh, wait. you can't. because you killed the process.
> 
> No, the process exited gracefully.   It checked to make sure all work was
> done, it was, and it left.  This is a different thing from a SIGKILL, which
> says OUT NOW.

okay, this is my fault: i used the wrong term. i should have said quit
_ends_ the process instead of _kills_ the process since that already
means something else in linux-speak. the argument still stands. quit is
separate from save, and does not inherently perform any i/o function. it
is a command whose main job is to affect an entire process, not just a
file.

> >run a few of your test subjects through this procedure. ask _them_ what
> >the hell quit does. when you've compiled your scientific results, get
> >back to me.
> 
> I will ask my test subjects this question:  "If you press quit, and the
> application has unsaved files in memory, should it ask you if it should save
> them or should it destroy your work?"  Oh boy I wonder what the response
> will be ;-)

then run them through my scientific procedure and ask them if they would
classify "quit" as a process-level command or a file-level command.

again, get back with me once you have compiled your results.

> You know, this is odd, I just used Clarisworks a few hours ago, and page
> margins were under Format->Documents.  Different version?

wow! you found one command, out of the example i gave, one command that
works differently! congratulations! i bet you feel proud now; i bet you
feel your whole viewpoint is justified.

okay, too much sarcasm, i'm sorry.

look, the point is, we're splitting hairs with this one and you aren't
looking at the general structure i'm proposing, but trying to fight me
on every individual setting. progress is not made in such ways. further
clarification:

> However, I don't have a problem with printer settings, including page
> margins, getting shoved into the file menu, because these are filewide
> settings that modify printer output.  That sticks with the I/O theme of file
> very nicely.

but i'm not proposing an i/o-based menu, remember? i'm proposing a
document-wide command menu. please try to separate these out and judge
my proposal on its own basis, rather than trying to squeeze my proposal
into the way it's done now.

printer configuration dialogs, in the claris works example i gave,
indeed are document-wide settings and do belong in the document (or
"file") menu.

i mentioned things like the number of columns because some basic word
processors may offer this as a single, document-wide setting. adobe
pagemaker, otoh, would _not_ put this setting in the document menu
because you can set a different number of columns on each page. it's not
a document-wide setting, therefore it shouldn't go into a document-based
menu.

too easy.

probably claris works falls into the same category with adobe pagemaker.
the point is, look at the structure, not individual usage. you _will_
understand this structure by the time i call it quits, dan: you may not
agree that it's the way it should be done, but you _will_ understand my
proposal on its own merits, rather than crammed into your own box or on
the terms of what we have now. i've made it a personal goal. :)

> >depends. if options pertain to an entire file, then they belong in the
> >file menu. if you're talking about options to be applied only to a
> >selected portion of a document, then sure, "selection" or "options"
> >would be a better place for them.
> 
> Holy hogwash, the man and I agree.  See, here's your problem sun.  When you
> gave your examples, you listed things that weren't really applicable to the
> entire document but rather to subsections.

well, if this was unclear i apologize, but as i previously stated, some
of these settings (like number of columns) _may_ be document-wide
settings, depending on how it's designed.

> I'm edgy on putting that kind of functionality in the prog menu, but I
> understand why one might.  In fact it's probably the most logical place, but
> that means separating preferences from options--not necessarily good.

glad to see the concession made. if we concentrate more on structure and
philosophy, the little hair-splitting issues will take care of
themselves.
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin