Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!well!svc
From: svc@well.sf.ca.us (Leonard Rosenthol)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog interface (was Re: Movable-Modal WDEF 1.01 (LONG))
Message-ID: <16589@well.sf.ca.us>
Date: 9 Mar 90 18:03:19 GMT
References: <1831@esquire.UUCP> <4202@hub.UUCP>
Reply-To: svc@well.UUCP (Leonard Rosenthol)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 49

In article <4202@hub.UUCP> 6600pete@ucsbuxa.ucsb.edu writes:
>From article <1831@esquire.UUCP>, by baumgart@esquire.dpw.com (Steve Baumgarten):
>> Nisus ... *always* keeps the Edit menu enabled, so that you can cut
>> and paste anywhere, even in modal and StdFile boxes ... if there's any
>> way to add support for Edit menu items in modal (and non-modal) dialog
>> boxes, I urge the Human Interface group to consider it.
>
>Well, I think that would be Engineering's problem, if HIG could yank
>the right peoples' chains. But it doesn't strike me as the most easily
>done thing. Compatibly, that is. Perhaps the command keys should work,
>but the Edit menu would be a bear.
>
	Implementing the Edit is _NOT_ that much of a problem.  It can be
implemented quickly inside of any dialog box - the problem, however, is the
HIG!  The HIG clearly states that when a modal dialog box is up, that any
clicks outsdie the window should beep (or do nothing at least).  Also, most
users look at the window, do not see a title bar, and therefore know that
they can not get at the menus. (If the application were really good, it would
also grey the menus on entry to the modal dialog to make this more apparent).
	Now that we have a 'new type of modal dialog' - the movable modal, which
has a title bar, then it seems to me that supporting the edit menu (or any
menu for that matter) makes more sense.  Since I see the title bar, I assume
that I can get to the menus - and lo and behold - I can (hopefully ;-)
	I should also point out that FullWrite was the first application
(that I am aware of) to make menus avail inside of modal dialogs - but they
also wrote their own menu and window managers so they could do that since they
were their own 'Interface'...

>> By the way, Nisus also handles the issue of command-key equivalents in
>> dialog boxes with equal aplomb. [ description deleted ]
>
>I will suggest this to Welch. Might be neat to see if he could figure out
>how to do this system-wide. O'course, he has his deadlines... :-)
>
	Actually in his new product, Dialog Power (part of QuickTools), what
Andrew has done is to adopt a method similar to that of MSWindows for showing
the user what cmdKey will choose that button (or radio button or check box) 
by underlining the letter in the title of the button that is the cmdKey equiv.
(it's even in red on a CQD machine ;-)  I personally prefer this to the Nisus
method since the contents of my buttons don't change just because I held down
a modifier key.  I think that the Nisus method is a conceptually nice step,
but a _BAD VISUAL_ one.  I also don't think that the Windows/DialogPower 
method is perfect, but it's better.

-- 
+--------------------------------------------------+
Leonard Rosenthol        |  GEnie : MACgician
Lazerware, inc.          |  MacNet: MACgician
UUCP: svc@well.UUCP      |  ALink : D0025