Re: RGSG
- From: "Dan Kaminsky" <effugas best com>
- To: <gnome-gui-list gnome org>
- Subject: Re: RGSG
- Date: Mon, 3 Aug 1998 13:00:08 -0700
-----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]