Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!decwrl!labrea!polya!ali
From: ali@polya.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <2122@polya.STANFORD.EDU>
Date: 9 Mar 88 02:27:24 GMT
References: <8802181921.AA19069@cory.Berkeley.EDU> <682@sandino.quintus.UUCP> <5295@utah-cs.UUCP> <732@nuchat.UUCP> <7599@apple.Apple.Com>
Reply-To: ali@polya.UUCP (Ali Ozer)
Organization: Stanford University
Lines: 51

In article <7599@apple.Apple.Com> lsr@apple.UUCP (Larry Rosenstein) writes:
>>It has to call the operating system at least once every 100 milliseconds to
>>maintain desk accessories.  ...
>>It has to be built around an "event loop" that handles all events in the
>>system, and passes down to other programs the ones it's not interested in.
>>
>This is not much different than what you have to do on the Amiga in response
>to certain messages.  On the Mac, you can take advantage of frameworks such
>as MacApp, which handle these things automatically.  (A programmer using
>MacApp has to do a lot less work than an Amiga programmer.)

But one difference is on the Mac your code *has* to check to see where
the user clicked, and depending on where the click was, you take appropriate
action --- such as moving the window (if clicked in the drag bar), or 
activating another window (if clicked in another window), or calling
the menu manager (if the click was in the menus), etc. I was
shocked to find this out when I was doing my share of Mac programming.

You mention MacApp --- MacApp unfortunately has a learning curve like
the Everest --- I have friends who started learning it two years ago and
are finally beginning to create programs in it. Of course, even with
MacApp, it's still *your* application that does the grunge work,
while on the Amiga, the code to move/depth arrange/activate & deactivate
windows, etc, is all run as a seperate task. Thus these events will occur no
matter what the overall system load is. (Intuition, the task responsible
for these events, runs at a high priority). You can drop out of your
event loop, enter another one, or do whatever you want --- the user can still
play around with the windows & screens without any slowdown.

Finally, there's the issue of "smart-refresh" windows --- That was a shocker
too --- To find that you have to refresh your window yourself! On the Amiga
you are not only relieved of checking for input events the system can deal
with, you are also relieved of having to redraw windows when they get 
revealed. The system will keep the covered areas in its own bitamps
and restore contents whenever necessary. Of course, if you want, you can still
fall back to the "simple" refresh method of having the application redraw
the window whenever it's necessary to do so --- Except, on the Amiga,
where windows can be moved/depth arranged asynchronously with program
flow, this would cause problems and you'd have to pay attention to 
"refresh_window" type messages.

Having programmed both the Amiga and the Mac --- one thing is
apparent to me: The Amiga tries to offload as much runtime processing
from user programs as possible by making the programmer to specify 
many options at initialization time (which most of the time means compile
time). The Mac, on the other hand, lets you open a window real easily, in a
few lines of code, but then makes you do all the grunge work at runtime.
I guess the two are just different ways of looking at the world. In my
opinion, in a multitasking environment, Amiga's method makes much more
sense. 

Ali Ozer