Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!crdgw1!grymoire!barnett From: barnett@grymoire.crd.ge.com (Bruce Barnett) Newsgroups: comp.windows.news Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? Message-ID: <4448@crdgw1.crd.ge.com> Date: 6 Jan 90 12:59:21 GMT References: <13324@granite.BBN.COM> <8912302010.AA11723@super.super.org> <13323@diamond.BBN.COM> <1558@riscy.dec.com> Sender: news@crdgw1.crd.ge.com Organization: GE Corp. R & D, Schenectady, NY Lines: 126 In article <1558@riscy.dec.com> graham@fuel.dec.com (kris graham) writes: |I have heard a lot about the so-called "Technical Superiority" of NeWS. |Anybody care to educate us non-believers of this claim. I have never |thought of Postscript as a friendly language to program in.....or love a |windowing system that makes the implementation of a print screen facility |more tedious than necessary ; Well, PostScript is not a "high level" language, designed to make the programmer's life as easy as possible. Instead, is is a language designed for quickly generating graphical images. There is very little syntactic "sugar" that has been added. So the programmer's job is harder, but the execution is faster because the parsing is simpler. But some of the advantages of NeWS as I see are: 1) the user's program can execute in the server or the client. Or both. One example was mentioned in the Sun Technology article discussing the IBM 3270 emulator with graphic support. Who keeps track of the text and graphics in the window? The implementation desided that the text would be maintained in the client, while the server maintains the graphics. One benefit from this model was that it became possible to redisplay the graphics, changing the position, scaling factor, zooming in our out, changing the colors, etc - WHILE the IBM was still sending new graphics to the server. Another example is all of the NeWS programs that have no client code - the entire application resides in the server. You could have an illustration program work over a low speed modem. You could down load the program to the server, and transfer the diagram back when you are done. but inbetween there would be no network traffic! 2) The Graphics image is PostScript, of course. This gives you automatic scaling and rotation. Also - text is now treated the same as graphics. A text program can be a WYSIWYG editor with little effort. 3) Flexibility - Because the entire window system is based on the PostScript model, there are very few limitations. You can make a new shape, and use it for a cursor, character, icon, button, menu, or window. The distinction between these window concepts is very fuzzy. So you can have "icons" that contain "icons", windows containing windows. The "winwin" program is a simple ROOMS-type extension to the server, allowing you to organize a group of windows and icons into super windows, allowing you to switch between one set of tools and another. A "character" could really be a button or a window. This simplifies a HyperText system, for instance. Don Hopkins has done a lot of "blurring" in this direction. :-) His Pie Menus and HyperText system, for instance. He published some code in this newsgroup that transformed the cursor into a pulsating rainbow. As I also mentioned, you can draw a new thing on the screen, and use it to modify/redefine an existing button, menu choice, window shape, etc. Don also wrote soft menus - some code downloaded to the server that lets you cut/modify and paste menus from one aplication to another. Another example mentioned here was the integration of dozens of workstations to a large "Strategic Command Display". Each user could move the mouse up to the top of his/her workstation, and it would appear on the large display on the far wall, where it could be used to manipulate the information shown to everyone. Also - because of the syntax of PostScript, you can redefine the "reserved words" - well, actually, there are no reserved words in PostScript. You can redefine the entire language on the fly, changing constants into procedures. As an example, I changed the FillColor constant (which colors the background of the window) into a procedure. I made a table that listed machine names and colors. The procedure got the host name the client was running on, and returned a different color for each machine. This let me have several windows on the screen, and all of the icons and windows with a pale green were remote programs on the same system. It only took 10 lines of code downloaded into the server. Note that all of the above DID NOT require any modification of the server. It was done with dynamic extensions. 4) The window system is object oriented. The windows/ icons, buttons are all different objects in the object hierarchy (at least with the tNt toolkit). Subclassing icons and windows is easy. You could subclass every program and define new methods that apply to them. Send them a "refresh", "update" "Print HardCopy", "Return to original position", "revert to original defaults", "save to file", etc. method, much like we send kill signals. And you can add new methods on the fly, like a "send contents to a Laser Printer" or "start collecting a histogram" method to all windows of a certain class. I must admit the ways people have extended X is amazing. There must be a dozen new techniques to add the sort of feature to X that NeWS had all along. (Of course NeWS has evolved too - due to the influence of X). |One of my co-workers, Larry Timmins, has been involved in multiple ports |of applications originally done with Sun's toolkits. On average, for every six |months (calendar time) that the customer/software house put into the project, |only one month was needed with DECwindows' XUI toolkit. Using the Intrinsics |-based toolkit reduces the network requests and ultimately has proven itself |over and over. I don't understand. First of all, Sun has several toolkits. The older applications (SunView) did not have any networking support. I don't see how the number of network requests can be reduced from zero. The NeWS server allows the entire application to reside in the server. If there are a large number of network requests, the code can be re-written to eliminate this. The only other package I know about is XView, which is very new. It supports the older SunView model, in a manner that is easy to convert from SunView to X, but may not be tuned properly. There is a new document that tells people how to convert the old PixWin code to the new Xlib code, making better use of the native technology, instead of using code who's function is backwards compatability. I would like to hear more about this "reduction in network requests", because the argument doesn't ring true. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett