Re: RGSG




-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 12:17 PM
Subject: Re: RGSG


>Dan Kaminsky wrote:
>>
>> So what happens to a project app?  The moment an app lets you
conglomerate
>> numerous files, does Open get shoved over to The Foot?
>
>No.  "Open..." and "Close..." will always be associated with
>single files.

They will?  Can't you open 800 files in GIMP using the open menu?  ;-)

>  This is the point that "damn guy" was trying to
>make.  That's why you don't want to confuse the two operations
>file->close and application->quit.  When you want to close
>something,  a file, or even a project, without shutting down the
>entire application, you use the File/Main/Program menu.  When you
>_do_ want to shut down the app, that's a completely different
>scope of operation (outside the app's control, really); thus this
>action should be in a different menu.


Think about the example that I mentioned earlier.  "And if there's no exit?"
"Control alt delete?"  [By the way--this little piece of research means we
REALLY should consider copying the windows convention for dealing with this
little death command]  If an application doesn't wish to exit
willingly(file->exit), the user will immediately ask the operating system to
kill the program for them.  There *are* two contexts for existing
programs--thank buggy windows for this :-)

>I would imagine that with such large project-bearing apps, you
>would have two Opens in the file menu (just like MS Visual C++
>does): "Open File" and "Open Project".


I have no problem with two opens in the file menu.  I do have problems with
Open bouncing around depending upon the application context.

>> Quick note--the foot looks nice, and SHOULD be there, but shouldn't have
>> those options.  Well, OK, it should have a "Quit Application" button just
>> like the File menu--that's one piece of redundancy I'll accept.
>
>This is exactly what Windows 95 apps do (or, more precisely, what
>MS Windows 95 does to Windows apps).  The File menu has an Exit
>(put there by the application), and the icon application menu
>just to the left of it has a Close button (put there by the OS,
>but modifiable by the app).  Same functionality, different menu,
>different name.  I _don't_ think we want to go down that path.


Like I show above, I have no problem with an application exiting itself and
an OS exiting the application.

>[BTW, this is a Microsoft convention.  If you generate a template
>app in Visual C++, that's how it comes out.  Close and Exit.
>Kinda funny that Explorer bucks this convention with two Closes.
>Talk about a moving target.]


Tell me about it.

>> Maybe the second menu of any system should always contain the edit
commands
>> at the top?
>
>And with the foot/Program menu, this would be the File menu?  Do
>you mean the first menu after the File menu?  What if the third
>menu is View...or Help?


Well, hurm.  Good point.

Maybe we can depend on the keybox to self-document control-c into the user's
mind as Copy.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]