Huge Batch Reply: John

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

John:

>This bandstanding is getting very old.

Well, it’s easy to get hot and heavy about this....EVERYONE here is guilty
of it...myself included.

> Dan, the point we have
>been _trying_ to make to you is that the user will understand the
>interface better if it talks the user's language. That's it.
>That's the whole point. No one is denying that data can almost
>always be thought of as a file or virtual file, given a
>flexible-enough file metaphor. That part of the argument is
>immaterial. You keep trying to re-prove it, and we keep trying
>to tell you that we understand already.

Ah, but you don’t understand yet.

>I'll say it again. "Session" is more intuitive to an audio
>engineer than "File". Both menus will potentially do the exact
>same thing. The only difference is that the title in the menu
>bar will have different letters in it. The "Session" menu _IS_
>the "File" menu.

There is zero implication that Session has anything to do with I/O, although
it’s a strong argument to say that the leftmost menu should include only I/O
options.

Think about the following options that are logical under a Session menu:

1)  Jam:  This is Jam Session; take all the instruments and samples and mix
them together according to some kind of preset randomize settings.  Oh, sure
this really belongs in Edit, but heh, Session is so nice now...
2) Manage:  Trigger Session Management features.  Oops...
3) Play.  Play Session, why not, makes sense, and this would play the
present session settings.
4) Stop.  Stop Session.  Stop playing the present session.

Look at this for a sec...the entire application is a session manager, so
everything fits into the session menu.  If it didn’t, it wouldn’t be much of
a session manager application, would it?

Document gets even worse...why not put font in the document menu....

>While it's true that you could argue that everything is
>ultimately attributable to a file somewhere, the flat out point
>is, the user does not care. The user wants an interface that is
>easier for him/her to understand. "File" is generic, universal,
>while "Session" is specific and clear.

Too specific.  What happens when I add video playing to a sound app.  Now I
change the Sound menu to the Media menu?  What happens when I add
interactivity?  Is it now the Interactve_Media menu?

>So tell me, how is "File->Open" more clear to the audio engineer
>than "Session->Open" is?

File specifies I/O.  Session could fit ANY menu in the entire app, and it
BETTER if the entire app is a session manager.

>[Response to menu proposal]

As far as I’m concerned, we should suggest what you describe.  I think it’s
key or administrators to be able to do this.

Yes, I know a bunch of people came up with this and I’m responding in your
batch.  Bleagh.

>> One could take this a little step further... bring in some more GNOME
>> stuff. This is something that is used in the old atari ST GEM/MiNT
>> userinterface. Under the application menu one would have the stuff as in
>> mockup2 together with a list of all the currently open (GNOME)
>> applications. Which you could use to bring the selected app to focus. To
>> illustrate:

>the idea is nice, but doesn't fit into the concept of a menu to take all
the
>app wide commands.

It does fit with the idea of GNOME being the GNOME menu...remember what the
users said?  “I would think pressing quit in GNOME would quit all of GNOME”
Not a terrible idea to have EITHER gnomeprint grab stuff out of the minbar,
or some variant.