🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.mac
Article #7837

Re: Application State & Desk Accessories

#7837
From: Guido van Rossum
Date: Sat, 01 Nov 1986 12:30
44 lines
3179 bytes
>From: dubois@uwmacc.UUCP (Paul DuBois)
>[...] It's not so easy to tell, when there
>aren't any application windows, that a DA window has come up (so that
>Close should be enabled) or the last DA has gone away (so that Close
>should be disabled).

I suspect that there are a lot of applications out there that completely
reconstruct their menus whenever a mouse click in the menu bar is
received.  In particular I think MacWrite does this, because it takes
extraordinarily long (about a second?) from the mouse click till the
menu falls down.  It might be that most of the time is spent in the
AddResMenu call for the Font menu.

A different obeservation regarding the "Close" item in most File menus
is that I never use them.  I always click the close box.  I believe this
is true for most, even very novice Mac users: the close box is about the
first shorthand you learn to use, and soon you'll forget it has an alias
as a menu item...  Therefore it would not be a big loss if your Close
menu item were deactivated when a DA window was on top.  In fact a DA
might choose to have a window without a close box, which makes your
decision to activate the Close menu item equally wrong.  I believe that
in principle, an application cannot know enough about a DA to know which
menu items to (de)activate; the only rule is that the Edit menu should
have Undo, Cut, Copy, Paste and Clear, even though not all DA's actually
respond to these (the highlighted Undo is particularly bad, since it
makes novice users believe that they can Undo their actions).

Straying away further from the subject, often I miss a *keyboard*
equivalent to clicking the close box.  Now that Standard File Dialogs
can be operated completely from the keyboard, and so many other
operations have keyboard shortcuts, it is annoying to have to grab the
mouse to close a window.

And, finally, on keyboard equivalents: when a DA is active, key presses
are generally processed by the DA, not by the application.  This means
that the application, if it wants to be super-correct, should remove the
shortcuts from its menus -- *except* ^Z, ^X, ^C, ^V for the edit menu!
So here you have a reason why you *do* want to detect wheter a DA is
active, even if you don't want to activate Close, and we're back to the
original question: how to detect it and when to changes the menus?
The proper thing to do in my opinion is to check continuously in the
main loop, but update the menus only when a change is detected.
-- 
	Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>
Technical Details
Message-ID: <7126@boring.mcvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!seismo!mcvax!guido
References: <378@uwmacc.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!seismo!mcvax!guido
From: guido@mcvax.uucp (Guido van Rossum)
Newsgroups: net.micro.mac
Subject: Re: Application State & Desk Accessories
Message-ID: <7126@boring.mcvax.UUCP>
Date: Sat, 1-Nov-86 07:30:48 EST
Article-I.D.: boring.7126
Posted: Sat Nov  1 07:30:48 1986
Date-Received: Wed, 5-Nov-86 06:18:09 EST
References: <378@uwmacc.UUCP>
Reply-To: guido@boring.uucp (Guido van Rossum)
Distribution: net
Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam
Lines: 44
Apparently-To: rnews@mcvax