Re: RGSG - contents of Program menu

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

-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 12:14 PM
Subject: Re: RGSG - contents of Program menu


>Dan Effugas Kaminsky wrote:
>>
>> >  The following menus should
>> >either describe further objects (e.g. a layout program that
>> >handles text document-editing differently than image-editing,
>> >leading to both "Document" and "Image" menus), or other large
>> >categories of functionality (e.g. "Format", "View", even "Print"
>> >if the print functionality is very advanced & complex).  IBM's
>> >research is important, but I don't think we should base our menu
>> >structure solely on frequency of use.
>>
>> So we should have a REALLY WIDE menu bar with *TWO* menus, and to prevent
>> things from getting too long we should folderize by category.
>
>Where on earth did you get that?


I had assumed you didn't give a hoot for multiple menus, since you has
switched from "menus the user uses most frequently" to "lets divide the
menuing system into app level and document level".  Kinda fudgy in the way
you wrote it.

>Off the top of my head, for an imaginary desktop publishing app:
>
><foot> Document Image View Format Print Help
>
>Document->Open
>Document->Close
>Document->Print
>Document->Properties
>etc.
>
>Image->Open
>Image->Close
>Image->Scale
>Image->Properties
>etc.
>
>View->Text Only
>View->Outline
>View->WYSIWYG
>etc.
>
>Format->Tabs...
>Format->Paragraphs...
>Format->Margins...
>etc.
>
>Print->Page Layout...
>Print->Print Settings...
>Print->Print Document...
>Print->Print Summary...
>etc.
>
>Granted that this is just a quick mockup, and none of the actual
>menu choices should be worth disputing, THIS is the concept that
>I am trying to express.


[Sorry, below makes NO sense without complete quote]

And what I'm trying to say is that everything could be put into Document and
it would make sense, though be a complete mess.  Document is a content-free
header--of COURSE it's a document, this *IS* a word processor.  File limits
the contents of the single most memorized menu in all of computing to
input/output stuff.

Am I *CRAZY* for thinking the latter is better?  I mean, can't File->Open
just be overloaded...if you load a file, you add a file to the present
project, if you load a project, well you just loaded a new project...or,
worse comes to worse, file->open file and file->open project