tdn@spice.cs.cmu.edu (Thomas Newton) (06/06/86)
Yes, "fun" things that you too can do!
1) Go into MS-WORD 1.0. Pull down a terminal desk accessory (I used the VT52
DA version 1.4). Type ^Q. The control character should go to the DA, but
WORD will interpret it as the Quit command (the same apparently holds true
for other things on the menus with a command-key equivalent).
2) Go into MacDraw 1.7. Pull down any desk accessory or accessories (Apple's
Alarm Clock will do for this demonstration). Then select a MacDraw window
or make a New one. Watch the desk accessory (or accessories) disappear.
Does anyone know whether these "features" are still present in WORD 1.05 and
MacDraw 1.9? (And in the case of the former, are the non-Laserwriter-related
changes worth the cost of upgrading from 1.0?)
-- Thomas Newtonborton@sdcc3.UUCP (Chris Borton) (06/09/86)
In article <1008@spice.cs.cmu.edu> tdn@spice.cs.cmu.edu (Thomas Newton) writes: >2) Go into MacDraw 1.7. Pull down any desk accessory or accessories (Apple's > Alarm Clock will do for this demonstration). Then select a MacDraw window > or make a New one. Watch the desk accessory (or accessories) disappear. > >Does anyone know whether these "features" are still present in WORD 1.05 and >MacDraw 1.9? ... Yes, this is still in MacDraw 1.9. That was the primary aggravation in my complaint that a program from Apple (be it Apple programmers or licensed) doesn't handle DA's correctly. To quote Inside Mac (The Good Book) page 4 of the Desk Manager Chapter, "The user can activate other windows and then reactivate the desk accessory clicking inside it." This is obviously not the case in MacDraw. My suspicion is that this limitation is linked to MacDraw's method of clearing the menu bar except for the standard (apple, File, Edit) during the time a DA is active. This is necessary since MacDraw fills the whole menubar. My question is, what is the 'official' Apple policy and implementation idea for applications with a full menubar? MacDraw may have been a first attempt; I don't consider it satisfactory in the least. Clearing the menubar may be OK, but closing all DA's upon window reactivation is not. By chance is this covered in the Addison-Wesley edition? --Chris ---- Chris Borton, UC San Diego Undergraduate CS & German Literature borton@sdcsvax.UCSD.EDU || ...!{ucbvax,decvax,noscvax,ihnp4}!sdcsvax!borton "Zuerst 'die Pruefungen,' und dann nach Davis bis 4 Aug wenn ich nach Goettingen fliegen werde. Ich werde Euch sehr vermissen...es hat mir viel Spass gemacht und auch habe ich viel gelernt"
sam@cci632.UUCP (Sam Mantel) (06/13/86)
> My question is, what is the 'official' Apple policy and implementation idea > for applications with a full menubar? MacDraw may have been a first attempt; > I don't consider it satisfactory in the least. Clearing the menubar may be > OK, but closing all DA's upon window reactivation is not. By chance is this > covered in the Addison-Wesley edition? > > --Chris How could clearing the menubar be ok and closing all da's upon window reactivation not be? If the da's window is still present, then the associated menus for it must still be there (according to IM). It would seem that the only 'clean' implementation of da's in a program that uses the whole menu bar would be to close the da's. What's so wrong with this anyway? In any sizable system, there will always be seemingly conflicting goals. Sam Mantel -- Roch, NY "Nobody promised it would be easy, and nobody promised it would be fair." Dr. Samuel J. Mantel, Jr.
oster@ucblapis.berkeley.edu (David Phillip Oster) (06/14/86)
No program should use the whole menu bar. One slot should always be left for desk accessories and out of pity to the poor translator who moves your program to a more verbose language. Desk accessories with windows should get their menu out of the way when their window is not the active window. MockWrite does it right (good work D. B.!)
olson@endor.harvard.edu (Eric Olson) (06/16/86)
It would seem that MacDraw's logic for DAs is not just to close all open DAs when you click on the main window. For instance, a desk accessory such as Hyperdrive Drawers, which consists only of a menu, remains open when I click on the main Draw window or open a new document. Extras, a DA which starts out with a menu and opens window(s) after pulls to items in that menu, stays open so long as I don't open a window with it. So, I guess MacDraw tries to close all open DAs when the Draw window is activated and the DA window(s) deactivate. Interestingly enough, Drawers (the menu-only DA above) goes away when this happens, but cannot be opened again (presumably it doesn't know it's closed). I consider this a bug. We should remember that not all Macs have the same size screen (in fact, there are 3: Macintosh, Lisa/Mac XL, and Lisa/Mac XL with the screen mod). So programs shouldn't be doing things because "they use the entire menu bar" because that's a hardware dependent thing. Ideally, the menubar would scroll left if I drag far enough right on it. -Eric