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