Xref: utzoo comp.sys.mac:13649 comp.windows.misc:212 Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!hc!lll-winken!lll-lcc!pyramid!voder!apple!dwb From: dwb@Apple.COM (David W. Berry) Newsgroups: comp.sys.mac,comp.windows.misc Subject: Re: A/UX window systems, Mac toolbox, etc Message-ID: <7598@apple.Apple.Com> Date: 8 Mar 88 19:00:51 GMT References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <3996@vdsvax.steinmetz.ge.com> <7523@apple.Apple.Com> <4015@vdsvax.steinmetz.ge.com> Reply-To: dwb@apple.UUCP (David W. Berry) Organization: Apple Computer Inc, Cupertino, CA Lines: 74 >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 > 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.