Re: RGSG - File Menu

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Frederick I Gleef <gleef@capital.net>
To: Dan Kaminsky <effugas@best.com>
Cc: Tom Vogt <tom@lemuria.org>; gnome-gui-list@gnome.org
<gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 8:33 AM
Subject: Re: RGSG - File Menu


>
>My responses have been split to keep separate topics on separate threads.
>
>On Sun, 2 Aug 1998, Dan Kaminsky wrote:
>> Gleef wrote:
>> >The discussion of the "File" menu needs to be a separate item (or
items).
>> >Personally, I think calling such a menu "File" should be a C3, perhaps a
>> >C2, but not a C1.
>>
>>
>> Users EXPECT File.  Do we gain enough by breaking this expectation?  File
>> and Edit are needed.
>
>Yes, we gain much by breaking this expectation.

Ahhh, more meat.

>  If you follow the
>archived thread on this subject, many good arguments for changing the
>convention were given.  Here are just some of them:
>  *  File really makes no sense for many of the things that are often put
>     in the left-most menu (eg. Exit, Setup, Print).  Changing the name
>     makes much more sense than moving these important items.

I went over why these were appropriate for file, and thank you for
responding to my reasoning.

>  *  File really makes no sense for many applications (eg. many games,
>     system monitoring tools, communications programs, other non-document
>     apps).

Ah, here's where we differ.  Should we really draw a line between what
resides in memory and what resides on the hard disk?  Is "Program"
appropriate to a monitoring app up until the time that the app lets you save
"snapshots" of time periods, and then suddenly it's a file app and now we
could use File appropriately?  What I'm getting at is that even if an
application doesn't let you save its state, there's still a state that it's
in, and this state could very well be thought of as a file.

>  *  People will easily adjust to the left-most menu being a different
>     name, as long as it is consistant and they can stil exit from it.


This is true.

By the way, you do realize that changing the leftmost menu name *wrongs*
portability.  It's one thing to mandate the locations of options and
settings, etc.  These are things that HAVE no established standard and that
GNOME *could* leak out to the rest of the GUIs out there.  But File?  Very
established, very accepted.

>Making the left-most menu consistently something other than "File"
>addresses these points, "Program" and "Main" seem to be among the better
>choices for something to call it. There still is some room for debate as
>to whether the traditional File functions (New, Open, Close, Save) would
>be better off in the left-most menu, or if programs that need them should
>have a menu called "File".  I think the consensus leans towards having a
>separate menu.


So, lesse, what exactly does the File menu get...how do you decide what menu
gets what...

>As for Edit, it only makes sense if you are actually editing something.
>This would mostly be a subset of the set of File-based programs.  It is
>certanly not needed.


No, because even if you aren't editing something in the current applicaiton,
you can edit it in another.  For example, xosview should be able to export
both the screenshot copy context and a text readout copy context.  A perl
script should be able to query a running xosview for status information
periodically.

>> They would only be high usage if they use the stuff from File, but if
they
>> use the stuff from File there's no need for File, but if there's no need
for
>> File then we remove File, and if we do that we piss users off for the
only
>> reason that "that's the right thing to do".

>>
>> Anyway, I'm not really sure why File is all that "right thing do doish".
>> Lets see, what kind of stuff goes into file...
>>
>> New:  Make a new file
>> Open:  Open a new file
>> Close:  Close the presently open file
>> Save:  Save the present contents into a new file.
>These are all indisputably file-oriented commands.
>
>> Print:  Print the presently open file
>Print is appropriate for non-file programs (eg. Print a snapshot of my
>game, print the webpage I am looking at, print the snapshot of the current
>SMP usage graph, etc.)  If you think about it, Print is more print the
>current view than print the file.


And you can save the current view into a file, or open up a file that gives
you this view, etc.  Anyway, what the heck does printing do but generate a
file to be printed...

>> Exit:  Quit dealing with all these files and get out of here.
>You are taking an absurdly file-centric view here.  Exit exits out of the
>program, regardless of presence, absence or relivence of files.


So lesse, why does the user quit?

1)  Done dealing with these files, wants out
2)  Sick of dealing with all these files, wants out
3)  All these files are taking too much memory, user wants out

There are maybe a few times where File doesn't make a HUGE amount of sense.
I grudgingly accept the idea that a Game menu is a good idea for a game,
maybe.

But, in general, I don't want to see a proliferation of being different just
because It's The Right Thing To Do, when honestly, it ain't.  There aren't
enough situations where one can really say, you know what?  This really has
NOTHING to do with files.

>> Send:  Send the present file.
>Send, fax or other communication commands probably share more in common
>with Print than with Save.  It is certainly


"Save To Printer"  "Save To Fax"

Well, if we can Print To File, we can Save To Printer, no?  ;-)

>> Settings:  Change the settings of this specific file(any other usage is
>> inappropriate).
>Programs need an entry for "Change the settings of this application".
>This entry needs to be in the left-most menu.  Some programs also need an
>entry for "Change the entry of this specific file".  It is clear that
>these need to be clearly differentiated.  There was much debate on what to
>call each of them, with no resolution.


Whoa, I disagree strongly with you here.  While it IS somewhat logical to
deal with SOME appwide settings, it's only logical to deal with default
status of new files and present status of active file.  Change the settings
of this application belongs elsewhere, in some kind of hard-set,
standardized location.  Anyway, "change the settings" is meaningless; we
have two types of settings:  Options and Preferences.  The former is
accessed often, the latter is accessed rarely.  They belong somewhat close
to eachother, but honestly I don't think I have enough research at hand to
decide where they should go.  This *really* is something that Tom, Bowie, or
anybody else with copious research should make the proposal for.

This is also the reason I haven't made a default keyspace proposal, though
I'm just gonna do it pretty soon if nobody else does.
>
>
>> Import:  Import the contents of another file into this file.
>> Export:  Export the contents of this file into something another file can
>> use.
>Import and export are primarily translation commands, but translation
>commands that require a File-centric mentality.  The function served by
>these commands are better handled within the Open or Save command than as
>separate items.  This will also allow easier piping, assuming an input
>pipe would get tied into Open, and an output pipe would get tied into
>Save.


I'd agree with you if Import and Export weren't so extensible and specific
in certain cases.  For example, would you really want to "open" your
TWAIN/SANE driver?  That's a bit too file centric, even for me :-)

>
>> Am I missing something here?
>
>You seem to be taking a very File-centric view of applications.  Take
>another look at just which applications really NEED files.


All applications have states, and few applications literally couldn't save
those states.

Here's a suggestion...I'd like to be able to save and load preference files
for EVERY SINGLE APPLICATION....