🚀 go-pugleaf

In article <7523@apple.Apple.Com> han@apple.UUCP (Byron Han, fire fighter) writes:
|In article <3996@vdsvax.steinmetz.ge.com> I wrote:
|> Someone once made the point that it is easy to grow downward than to
|> grow upward. That is, it is easier to convert a multi-application,
|> multi-tasking, color window system into a single color, single user
|> system than vice versa.
|
|Incidentally, the Macintosh windowing user interface evolved from the Lisa 
|Office System which was a multitasking multiple window, multiple application
|environment.  I don't think that there is much difference between a
|color and a monochrome windowing system.

Well, I suppose I wasn't clear. Designing a complex window system that
will work with monochrome or color, single user or multi user, small
hardware or big, floppy or disk, is a difficult job. Look at Sun's
window systems. There was the original, then SunWindows, SunView,
SunDew, NeWS and now NeWS/X11. It is even more difficult to provide a
migration strategy from the old window system.

In simple terms, no window system is ever complete. The better ones
provide the most flexibility.

I read somewhere that 35% of the current Mac software packages
do not obey the guidelines that will provide portability to future
window systems for the Mac. This figure in itself - I believe - 
lends some creedence to my claim.

Then there are issues that complex window systems must address.
Let's assume you have several applications running at once.
Now let's assume that one application wants to track the mouse cursor
as it passes through, while others are only interested in the
selection of an item from a menu.

SunView has a selection service that sits above all applications,
and analyzes the stream of input events. It distributes to the
applications the events they are interested in, in a concise 
and efficient manner. Mouse-ahead works even in these conditions.

I don't know how the Mac handles this task. I would assume that it is
a lot simpler because only one task runs at a time.

Another example is the evolution from monochrome to color.
How was the migration to a color system handled? Were the system calls
changed, and therefore incompatible? Or were new calls created, that
had similar functions to the monochrome but had new names and
features?

I would be extremely suprised, and extremely impressed, if the
original calls to the monochrome Mac toolkit were integrated into
the color version of the same. If you look at the complexity of
coloring single pixels, and applying boolean masking operations to the
screen, you can see that handling 1-bit deep and 2, 4, 8 or 24 bit
deep pixels are very different at the hardware level.

Yet the software interface should be the same, with only a few
differences. I am guessing about the Mac toolkit. But Sun's PixRect
package has only two special calls for color systems - setting and
getting the current colormap. All of the other calls are used for
both monochrome and color screens.

This leads me to a third example.  SunView allows applications to
specify the number of colors needed for each application. If possible,
the colormap will contain as many maps as possible in the 256 possible
values, allowing several tasks to run using just one colormap.

This sort of forethought is needed when planning something like the
color toolkit that is currently stored on ROM on the Mac II.

I know very little about the Mac toolkit, and have only tried to make
some educated guesses. Actually, I look forward to hearing how wrong I am.

But I wouldn't be suprised if the ROM on the Mac II needs a major
re-write when Apple finally get's the REAL A/UX window system working.
An upgrade that will be _required_ - before the new A/UX window system
can be used.
-- 
	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
				uunet!steinmetz!barnett