guido@cwi.nl (Guido van Rossum) (05/08/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
tecot@Apple.COM (Ed Tecot) (05/10/88)
In article <305@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: >In article <9332@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: >>In article <2887@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes: >>>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. One thing Phil did forget to mention is that since modal dialogs have their own event loop, there is no way to get the suspend and resume events to the application. _emt . . . . . . . . (darn inews!)
goldman@Apple.COM (Phil Goldman) (05/10/88)
In article <9448@apple.Apple.Com> tecot@apple.UUCP (Ed Tecot) writes: >>In article <305@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: >> >>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. > >One thing Phil did forget to mention is that since modal dialogs have their >own event loop, there is no way to get the suspend and resume events to the >application. Yes, the loss of suspend/resume events is a good reason. It still would be possible to get them, but much more difficult (it's unfortunate that the filter proc won't see them). No, the non-reentrancy of StdFile was not an issue. It probably *is* reentrant given that MultiFinder switches the low memory globals that drive it. If not, it would have been minor to make it so. The major issue, though, was User Interface. It is still possible with the current interface for an application to present dialogs that are modal within an app and those that are globally modal. This would not have been possible if the decision was made to make _ModalDialog modal to a layer. There was also a concern that the user interface presented nowadays on the Mac is not as clean as it once was. These concerns are natural when an interface is extended. What we have tried to do is to make the application interface more complex, if absolutely necessary, in order to keep the user interface clean while maintaining compatibility. Nothing has been sacrificed in the user interface itself. -Phil Goldman
thomas@uvabick.UUCP (Thomas Fruin) (05/17/88)
Ed Tecot writes: > One thing Phil did forget to mention is that since modal dialogs have > their own event loop, there is no way to get the suspend and resume > events to the application. That's why I hate modal dialogs! I try to avoid them as much as possible, a and when I _do_ have to use them, I don't call ModalDialog at all. Instead, 1) I put up the window with (Get)NewDialog 2) I disable the whole menu bar except the Edit menu 3) I set a global flag that tells the application a dialog is in front 4) and I simply keep calling the main event loop, which has code to handle modeless dialogs, as illustrated earlier. The advantages? The user gets to use the Edit menu ( a real bonus ), and you can keep using the main event loop (so all the correct events, such as suspend, resume and activate, get passed to the application). -- Thomas Fruin fruin@hlerul5.BITNET University of Leiden thomas@uvabick.UUCP University of Amsterdam hol0066.AppleLink 2:512/114.FidoNet The Netherlands