Re: Document vs. File menu (was Re: RGSG)

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

-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: Dan Effugas Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 10:32 AM
Subject: Re: Document vs. File menu (was Re: RGSG)


>Dan Effugas Kaminsky wrote:
>>
>> >You never print the file explicitly.  If you did, you'd get a raw
>> >stream of binary/hex digits.  You print a _representation_ of a
>> >file.  What you actually print is a conceptual interpretation of
>> >a file, as seen by the application.  If the application sees it
>> >as a document, you're printing a document.  If the application
>> >sees the file as a music score, you're printing a music score
>> >(and the command would go "Score->Print").
>> >
>> >If this does not address your intention, please be more clear.
>>
>> Raw outputted to filter outputted to printer, just like default inputted
>> into the new file.
>
>This is supposed to be more clear?  Hmmmm.


Sorry.

Look at it like this:

cat rawfile | file_filter | page_setup_printer_filter | lpr

>> Score->Print?  So I guess we'd see Score->Transpose, Score->Quantize,
>> Score->Change Timing, and generally anything else that any other menu
could
>> have...well, it makes logical sense.  You Quantize a Score, just like you
>> Print a Score, right?  And you Transpose a Score, just like you Open a
>> Score, right?  Forget about that I/O stuff, the user doesn't get it
>> anyway...
>
>Exactly my point.  Are you agreeing, or being facetious?


Uh?

So you're saying there's no such thing as a menu entry that doesn't belong
in the leftmost menu, A.K.A. the SINGLE MOST MEMORIZED AND UNDERSTOOD
SEGMENT OF THE ENTIRE MENUBAR?

Let me list off everything, then, that would/could be in a menu entry of
Microsoft Word according to what you say:

Document
===
New
Open
Close
----
Save
Save As
Versions
---
Page Setup
Print Preview
Print
---
Send To
Properties
---
[history list]
---
Exit(maybe if you leave it there)
---
Find
Replace
Go To
---
Links
Objects
---
View->Normal, etc.
Toolbars
Map
Header and Footer
Zoom
---
Insert->Break etc.(oh around 15 entries)
---
Font
Paragraph
Bullets and Numbering
--
Columns and Tabs

and ON
and ON
and ON
===

I think that's the big problem with your solution.  If you rename File to
what the application does, something like 90% of the entries can concievably
be shoved into the "what the application does" menu.  If you don't have an
automatic reaction to "wait a second, maybe something that MODIFIES the file
shouldn't be IN THE FORMER-FILE MENU", then the above serves to show
you...EVERYTHING can be justified with "Document->X" when it's a word
processor that the document menu is sitting around in.  After all,
everything modifies the document...and I would HOPE it would, what else
WOULD it do?


>> You said if you don't have a document, you won't have pages to set up.
>
>I should have been a little more precise there.  I meant that if
>a given application doesn't deal with "documents", then it won't
>deal with printing "pages" per se.  It may still print, but the
>objects that it sends to the printer should be conceptually
>identified as the same objects the application sees.  I think we
>should stay away from the "Page Setup" menu item (because it's
>too document-oriented), and stick with the more generic "Print
>Setup".  This would avoid the problem altogether.


You print pages.  Physical, real world, can put it in your hand and then
shove it through a printer *PAGES*.  Why drop the real world link?  Even if
the app doesn't have pages, 99.9999% of the printers out there now do not
use rolls of paper.

>> Page Setup exists *independantly* of outgoing files but is not called
*without*
>> an outgoing file.  In other words, if you have no documents, you can set
the
>> print margins to be used on the up and coming files even without any
open.
>> And since Page Setup modifies Print, which is actually a file level
>> object(the file gets translated into printer language), Page Setup
belongs
>> with Print in File.
>
>I'm not sure what you're getting at.  You keep explaining things
>without getting around to the point (unless your point was that
>Page Setup belongs in File, which was my point too, only I was
>calling the "File" menu "Document" instead).


That was the point.  We're agreed here, and now I want to see what you reply
to against "by the way, besides being hell on a keyboarder, how the heck do
you propose to prevent the contents of the leftmost menu which has proven to
be the most consistently scanned and utilized from being filled up with
random stuff that has no purpose being there?"

File is not Misc.