🚀 go-pugleaf

In article <326@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes:
>[...]  Modal dialogs are put
>up by the application when it demands the users attention.  Therefore,
>it does not make sense to allow the user to switch, just as he cannot
>do anything else to the machine except respond to the modal dialog.  If
>the app's need is not that pressing it should put up a modeless dialog, or
>use the notification manager.  The point is, that it *is* the application
>writer's decision, not the OS's.  The OS provides the mechanism only, not
>the policy.

I wasn't going to say anything, but this is getting too ridiculous.
There is a point at which putting work onto the developer starts losing
rather than winning.  How many times have I been wedged because some bozo
thought that a dialog was *so* *important* that I'm not going to be able
to do anything else until I respond, or because some other bozo figures I
have nothing better to do than wait for a program to finish some lengthy
operation.  It doesn't even require an unfriendly application, just some
unanticipated situation where a program gets stuck in a loop.  It never
ceases to amaze how many people will take some expedient decision and
make into a "principle" to be held true for all time.  Some of the rationales
for Mac design decisions are getting uncomfortably reminiscent of IBM's
arguments for why their 25-year-old designs are still valid today.

Anyway, there are quite a few people at Apple that do believe pre-emptive
multitasking is important, that applications should be simpler to write,
that memory protection is essential, and that the OS should support true
distributed applications.  The key question is how to turn all of these
(well-known) ideas into new products that retain the advantages of the Mac. 

						stan shebs
						shebs@apple.com