Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!santra!kampi.hut.fi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac
Subject: User Interface Response Time. [was: Re: A call for "3D look"]
Message-ID: <1990Feb6.131345.14236@santra.uucp>
Date: 6 Feb 90 13:13:45 GMT
References: <7432@tank.uchicago.edu> <497@fsu.scri.fsu.edu> <142@farcomp.UUCP>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 43

In article <142@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes:
>In article <497@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu ("Eric Pepke") writes:
>>What I don't want to see lost on the Mac is the feel of the interface.  
>>NeXT buttons look more like buttons, but Mac buttons feel a lot more like 
>>them.  When I click on a button, I don't want to wait a fifth of a second 
>>for the button to light up; I want it to light up NOW.  I don't know what 
>
>Hey all you Eunuch dweebs out there who have to have "true pre-emptive
>multi-tasking!"  Read the above paragraph carefully.  It illustrates the
>number one argument AGAINST pre-emptive multi-tasking on the Mac.  Unless 
>the dudes at Apple work some real magic in their implementation of "true pre-
>emptive multi-tasking" the feel of the Mac is going to be the pits.

The distinction with user interface feel is not between pre-emptive and
Mac-style multitasking. Both have the same problem with interactive work.
Just try to run Stuffit in the background and click a button on the front
application (It will take forever for it to react). A real-time multitasking
system should not have this problem. If the interactive task is given higher
priority than others, it will feel faster.

>I like the way the Mac feels and couldn't care less about being able to 
>format a disk while calculating Pi to 73000 decimal palces.  Those of 
>you (programmer types) who can't tell a pointer from a handle should 
>just stay over there where you are.

Now what is this supposed to mean? I wouldn't mind being able to use my
terminal program while a disk is formatting (although on the Mac, formatting
a disk is a CPU-intensive operation). I also wouldn't mind doing something
while a program is saving a large file (700KB or larger) to a floppy.

As it is currently, MultiFinder gives top priority to the front application
and leftovers for the others. (50% of the slots go to the front application
while the background applications share the rest.) This helps a little in
keeping the Mac interface up to our expectations.

If you feel like flaming this article, please mail me instead of wasting
useful net.bandwidth. I'm already having doubts about posting this article,
since this subject has already been beaten to death.

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|     Juri Munkki jmunkki@hut.fi  jmunkki@fingate.bitnet        I Want   Ne   |
|     Helsinki University of Technology Computing Centre        My Own   XT   |
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^