Re: RGSG - File Menu

[Tom Vogt <tom lemuria org>]

Dan Kaminsky <effugas@best.com> wrote:
> 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.

and saving that state is what session management takes care of.

this is not a user-interface issue.



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

it's  so easy. things that  work on files go to the files menu. things that
work on the program go  to the program menu.

some things will  not be clear (like print) and  will need discussion, but
there is ZERO doubt (except for Devil's Advocate's Neighbor D.A.N.) that you
CLOSE a file and EXIT a program.


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

why? a perl script should not take a utility that creates graphical displays
from /proc/* information as input, but query the source directly.

and even if, this would not justify an "edit" menu in xosview.


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

stop thinking files, please. think along the lines of your favorite
secretary who doesn't even know what the heck a file *IS* - and couldn't
care less.


> >> 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
4) has an important date
   (put exit into the clock app!)
5) laptop power runs low
   (put it into the battery power display app!)
6) to 28) more reasons


I'm dangerously close of doing what I complained about here, but I'm trying
to  show that you can justify about anything if you approach from this side.
the  more reasonable approach would be head-on. the most straight one you
can find. and that is that you CLOSE a file, but EXIT an application.


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

find a user who THINKS that, then  return.



-- 
The universe does not have laws -- it has habits, and habits can be broken.