Re: RGSG - File Menu

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Tom Vogt <tom@lemuria.org>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 1:10 PM
Subject: Re: RGSG - File Menu


>and saving that state is what session management takes care of.
>
>this is not a user-interface issue.


Too high end for me.  I don't want to reopen my state of Lyx working on my
thesis, I just want to use lyx to open the damn thesis.

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


The *ONLY* thing you've established that CLEARLY DOES belong in a Program
menu is exit.

Bunch of stuff clearly belongs in print.

Some stuff is iffy.

Nothing else belongs in program, guaranteed.

Think about that, Totally Ornery Man T.O.M.  :-)   <---FOLLOWING MEANT AS A
JOKE AND SHOULD BE TAKEN AS LIGHTLY AS D.A.N., THIS IS NOT A FLAME, THANK
YOU.

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


Uh so the perl script should duplicate the functionality?  I thought we were
lazy here.

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


Why not?  Can't you envision emailing someone your xosview contents as text?
Or as graphics?

Anyway I like the gimp way...it's always in the root menu, but if there's no
room on them menu bar, trash it.

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


Your favorite secretary knows that her bosses' documents are in a physical
file by her desk.

>
>> >> 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!)


Clock applet shouldn't be killable via a right click -> file -> exit?
(That's for consistencies sake)

>5) laptop power runs low
>   (put it into the battery power display app!)

Shouldn't be able to close the laptop power app?  Shouldn't have
shutdown/sleep integrated in here?

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


AND THATS THE ONLY EXAMPLE YOU HAVE!  That's the ONLY thing that's clear.

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


I can find you a user who thinks of printing as a way of sending something
from the computer to the phsyical file by their feet.