Re: RGSG - File & Edit Menus

["Dan Kaminsky" <effugas best com>]

>> A project is a bunch of files.
>
>A Project is a Project.  It should not matter to the user whether the
>Project is made up of a bunch of files, one file, some database records in
>a database server, CD tracks, or a combination.


It shouldn't matter to the user if the project is composed of one file or
many.

One file is a file.
Database records are files within an organizer.
CD Tracks are audio files encoded according to the Redbook standard.

>>
>> New Project gives you a place to put a bunch of files.
>> Open Project lets you open up an organizer for a bunch of files.
>> Close Project lets you close an organizer of files.
>
>Computer software is moving away from the file-centric way of viewing
>things.  The GNOME Style Guide should not perpetuate


BS.  I count this as "we're modern just because we want to sound cool"
concepts--tell me when somebody comes up with a computer with no use for a
file system.  By the way:  Accessing the file system over the network, or
the disk drive in a raw manner because the application knows the file
structure better than the file system does, don't count.

>
>> Print Project lets you print out the contents of an organization of
files.
>> etc. etc. etc.
>
>Project-based systems almost never have this menu item.  You can print out
>various aspects of the project, in various views.  These aspects usually
>have nothing to do with the files of the project.  A Print Project item
>would only be of use to the developer, not the user.


Various types of projects print various types of information that have
SOMETHING to do with the underlying files.  If there ARE no underlying
files, some kind of information regarding what's gonna happen when files
happen to show up gets printed.

>Most games complicated enough to have save games, lately have a load game
>and save game item on the main menu.  They explicitly separate the user
>from the concept of files by only letting you access them by game, not by
>file.  It matters not to the user whether the game is saved in a file, as
>a portion of a file, or on their game server.  Do you honestly think that
>Ultima Online is saving your current status in a file on your computer
>when Save Game is hit?


I didn't know you could save game on a realtime world :-)

And no, the user shoudn't care where their save file is being
saved....locally, remotely, extraterrestrially....they just wanna save.

>Exit this game FILE is completely meaningless.  Exit means exit, whether
>or not you are dealing with files.


Well, like I said, there are TWO file contexts that Exit fulfills:

1)  All applications are files.  "Not Java apps...oops I was downloading all
those class files.  Not web pages oops I downloaded a web page..."  So, if
you exit an application, you are closing the file you opened to get into
that application.

2)  By extension, closing the file you used to get into the app closes all
"child" files.  So you're kind of trashing a two level structure in a
heirarchy--the file and all children of that file.

>How often do you need edit in: xload,

Copy my extremely high load to a mail to the sysadmin and complain that my
computer is broken.

> xanim,

Screenshot.

> xmp3,

Screenshot, track info, etc.

> or GUI front ends for
>FTP clients,

All the time.  Copy the URL from netscape, paste it into the FTP client.

> CVS,

CVS doesn't grant ANY information about what it's doing?  Nothing to
highlight, copy, and paste?

> PPP,

Uptime?

Screenshot?

Who are you to say that the user can't copy?

> etc.  An Edit menu makes sense in only two types of
>applications: applications which need something more advanced than the
>standard drag and drop functionality (eg. image manupulation software),
>and applications where editing is so important that new users need to be
>reminded of it (eg. gedit).


Well, uhm, the thing is the application that's doing the editing isn't
always the application that's doing the copying.