Path: utzoo!mnetor!uunet!mcvax!guido
From: guido@cwi.nl (Guido van Rossum)
Newsgroups: comp.sys.mac.programmer
Subject: MultiFinder and Dialog boxes (was Re: MultiFinder switch bug with custom WDEFs)
Message-ID: <305@piring.cwi.nl>
Date: 8 May 88 11:26:51 GMT
References: <242@uvabick.UUCP> <8700@apple.Apple.Com> <2887@midas.TEK.COM> <9332@apple.Apple.Com>
Reply-To: guido@cwi.nl (Guido van Rossum)
Organization: The Royal Society for Prevention of Cruelty to Amoebae
Lines: 88

[This article is not just a point-by-point reply to Phil; it contains
some more philosophical remarks near the end.]


In article <9332@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes:
>In article <2887@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes:
>>Perhaps what I'm really suggesting is that modal dialogs are only modal
>>with respect to that application that displays them, but that they should
>>be MODELESS with respect to OTHER applications running under MultiFinder.
>
>There might be some use for dialogs that are modal within their layer.
>This can already be accomplished by the applications themselves.  Hopefully
>these will not too often be used.

I disagree, Phil.  Herb's right, (true) modal dialogs are modal because
its application can't proceed further until the question is answered.
The machine and OS sitting on my desk have had true multiprocessing
built in from the start (but then again, windows were forced upon it
much later :-), and it works this way: an application that puts up a
dialog box blox, but other applications can still be interacted with.
Completely reasonable, and very useful (E.g., I may need to create a new
directory before letting my graphics editor continue its save procedure).

>>If the real problem is that Apple depends upon non-reentrant code (such
>>as Standard File) which uses modal dialogs, perhaps we should all be asking
>>when Apple will make this code reentrant.
>
>And modeless too, right?  Why shouldn't other application windows be allowed
>to be put in front of the StdFile dialog, as well as other layers?  What's
>the distinction (besides a change to the app interface)?

Please answer the question, Phil!  Was the non-reentrancy of StdFile a
reason or not?  Your cynism (if I read this well) looks like a rethoric
trick to duck the question.  Besides, what you suggest is not so strange
as it seems.

>Anyway...
>Do you really want multiple instances of StdFile?  I'd think that it would
>be nicer to *never* have to use it.

Now you're making more sense.  I heard a story that in the original
design of the Mac (or was it the Lisa?), the idea was to put the full
Finder in StdFile.  This would indeed have made for a very nice user
interface, but it was too expensive in memory space.  Now we're using
MultiFinder anyway, we can try again.

(Philosophical note)
I have the unpleasant feeling that, with all the investment in existing
hardware and software, new features added to the Mac don't have the
natural cleanliness of the original design.  If we were to design a
system from scratch with the same functionality, aimed at hardware with
the same power, we'd do many things slightly different.  E.g. (just
thinking aloud):
- Put the menu bar back in the window title, where it belongs; this
makes switching between applications much more natural.  (This was
also considered in the original Mac or Lisa design but rejected because
it cost too much screen space; with the bigger display this argument
goes away, and there's the current problem of having to move the mouse a
long distance to the menu bar, and then back to your window...)
- Greatly reduce the use of modal dialogs.  Many of these are used as a
substitute for hierarchical menus, or could just as well be modeless
dialogs (e.g., most option-setting dialogs; I have the feeling that
these are usually made modal because it's easy to program (no need to
keep track of the dialog state while engaged in other activities), or
even just because everybody does it like that (MacWrite and MacPaint
notwithstanding).  If I remember it well there's also the problem with
modeless dialogs that they require an extra mouse click to activate the
dialog window (unless you make it the ghost window which poses other
problems and doesn't generalize to N modeless dialog windows); putting
all controls in the main window has the obvious disadvantage of taking
up too much window real estate.
- Remove all functionality from individual programs that is better done
centrally, e.g., applications should know *nothing* about Desk
Accessories: no Apple menu, no passing of Edit menu items to DAs, no
SystemTask calls, etc.  (Then what's the difference between a DA and an
application?  None, except they are usually smaller, and correspondingly
harder to write, and more limited in their functionality (e.g., one
menu, one window onless you work very hard).)

...But I suppose it's quite useless to suggest all this; Apple might
lose its leading market position in the conversion process.  And there
is so much good in the existing Apple design that if somebody else
created and sold a system like this and wanted to do it really good,
they'd have to use a lot of ideas found in the Mac, and risk another law
suit...
--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net