🚀 go-pugleaf

>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.
	This would be a reasonable belief, were it true that all
the sidestepping was done to provide additional functionality to
the window or menu manager or other user interface function.  More
often than not, it's done in the name of speed, or in not wanting
to find the documented portable solution, or to add functionality
to the operating system ...

>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.
	The mac "simplfies" things for the user by denoting one
application, the "current" application.  It is the only application
which can receive input from the user.  This is an extension of
the idea that only the current window receives user input.
>
>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?
	From the level of windows, menus, etc. the changes were,
by and large invisible.  The programmatic interface remains the
same but additional information could be hidden in the resources
to colorize the windows.  Resources, for those of you that don't
know it are templates for windows, menus, etc. that users or programmers
can easily change.  Functionality can't be affected much but appearance
can be.
	From the level of drawing primitives, all the old monochrome
stuff still works.  There are added calls to change the current drawing
color and similar stuff, but the basic primitives remain the same old
orthogonal set:
	{Fill,Erase,Frame,Invert,Paint}\
		{Rect,Oval,RoundRect,Arc,Region,Polygon}
and the line and text drawing primitives.
>
>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.
	I'll consider you impressed and surprised :-)
>
>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.
	Sounds familiar.
>
>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 one area I would consider lacking on the mac.  There
is only one CLUT per screen, where one per window would be kind
of nice.
>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.
	I think you'll be very and pleasantly surprised.
>-- 
>	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
>				uunet!steinmetz!barnett


	David W. Berry
	dwb@well.uucp                   dwb@Delphi
	dwb@apple.com                   973-5168@408.MaBell
Disclaimer: Apple doesn't even know I have an opinion and certainly
	wouldn't want if they did.