From don@brillig.umd.edu Wed Jun 1 15:29:21 1988 Date: Wed, 1 Jun 88 15:29:21 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Sunview under NeWS From: nye@ati.tis.llnl.gov (Scott Nye) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Sun released a paper entitled "Sunview Direction Statement" (January '88, I believe) which discussed these issues. To summarize briefly: Sunview 2.0 will be based on the new merged NeWS/X11 server. The server will handle any device specificities, so Sunview programs which use old (pre Sunview) Sunwindows calls, and some Pixrect and CGI calls may not work under Sunview 2. Sun also stated that for the first release of Sunview 2, Sunview 1.1 compatibility would remain. If you are using a device which is connected to the machine on which the client is running you could still manipulate the color map, etc. directly, but that would undo any benefit of going to a device independent client/server based system. Your friendly Sun rep. should have copies of the paper ... Scott Nye. nye@tis.llnl.gov From don@brillig.umd.edu Wed Jun 1 20:00:20 1988 Date: Wed, 1 Jun 88 20:00:20 EDT To: NeWS-makers@brillig.umd.edu Subject: Free public domain NeWS software From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There is a bunch of public domain NeWS software available for anonymous ftp directory from tumtum. (Including gnuplot and surfmod!) Open an ftp connection to tumtum.cs.umd.edu, login as anonymous, with any password. Don't forget to set binary mode when transfering compressed files. For those of you without internet access, there is the news-archive server, supported by Sun. Send a message to "news-archive@sun.com" or "{ihnp4,ucbvax,decvax,pyramid}!sun!news-archive" saying "help" (in the subject or body), and you should receive instructions. If it does not respond in a reasonable ammount of time, try including the line "path " in your message. -Don From don@brillig.umd.edu Sat Jun 4 23:43:14 1988 Date: Sat, 4 Jun 88 23:43:14 EDT To: NeWS-makers@brillig.umd.edu Subject: Novice NeWS user needs assistance From: walters%community-chest.mitre.org@gateway.mitre.org Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have several questions concerning NeWS. We are using the pNeWS release from Parallax on a Sun 3/160. Documentation: The documentation we received seems fairly sparse; it consists of a manual of Parallax extensions to NeWS, as well as a NeWS manual. I have also purchased two Adobe books on Postscript, the Reference manual and the cookbook. I have made some effort to find the answers to my questions in the manuals before attempting this posting. What other documentation is available (I also looked on the new-archive server documentation index)? Palettes: How does NeWS (specifically pNeWS) handle color? Can the default palette be changed? If so, how? Saving Postscript Canvas as Rasterfile: The demos that are provided show methods of loading rasterfiles and painting on a canvas. Is the reverse operation supported, i.e., are postscript/NeWS primitives provided that save a canvas as a rasterfile? Any suggestions, pointers, etc. would be greatly appreciated. Thanks in advance. -- chris walters (walters@mitre.arpa) (703) 883-615 standard disclaimer... From don@brillig.umd.edu Sat Jun 4 23:43:24 1988 Date: Sat, 4 Jun 88 23:43:24 EDT To: NeWS-makers@brillig.umd.edu Subject: foo From: megatest!djones@decwrl.dec.com (Dave Jones) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi there. I'm a long-time programmer, but a beginner at graphics programming. What I would need to do is to draw some simple shapes -- boxes, circles, triangles, etc., filled and not filled -- in sunview (Pixwin). The only routines I find are rather low level, and not too well documented. Does anyone know of a library package that has routines such as DrawBox(), DrawFilledTriangle(), etc.? Or a text-book that is more detailed than the Sun manuals would help. (The documentation for pr_polygon_2() does not even say what the parameters dx, dy, sx, and sy are for.) Please respond directly, if you will. Thanks, Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.EDU From don@brillig.umd.edu Sat Jun 4 23:43:32 1988 Date: Sat, 4 Jun 88 23:43:32 EDT To: NeWS-makers@brillig.umd.edu Subject: Changing Color table. From: David Walker Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I want to be able to display grabbed images within NeWS that use their own colormap. Pictures displayed in NeWS seem to be approximated to the NeWS colormap which results in large scale image degradation. Is it possible to display a picture within the NeWS environment using the particular colormap of the picture??? I actually want to view several pictures, each with their own colormap. I will probably reserve a section of the colormap which will hold the colors for the menus, so that they don't change color when a new picture is diplayed. Thanks for hour help davidw. From don@brillig.umd.edu Tue Jun 7 00:15:13 1988 Date: Tue, 7 Jun 88 00:15:13 EDT To: NeWS-makers@brillig.umd.edu Subject: New files in news-archive From: parhelion!newsman@sun.com (manager-news-archive) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We've added a few new files to the NeWS archive server. In the Applications directory, the following two files have been added: neatwin.ps A subclass of LiteWindow with window managment pie menus, for NeWS 1.1. Note that this is intended for use only with pie menus. tooltool.shar An interactive LiteItem code builder. Allows you to create each type of Liteitem. You can then dump the code that builds the example. In the Demos directory, the following program has been added: func.shar The function graphing example in the Spring 1988 Sun Technology Journal. The address for the server is news-archive@sun.COM or sun!news-archive, whichever you prefer. For more information about the server, mail a request with the word "help" (without the quotes) on the subject line. If you'd like to make a contribution to the archives, or if you have a problem using the server, please send mail to manager-news-archive@sun.COM. From don@brillig.umd.edu Thu Jun 9 23:18:07 1988 Date: Thu, 9 Jun 88 23:18:07 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Novice NeWS user needs assistance From: frame!c3po!glc@Sun.COM (Greg Cockroft) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have several questions concerning NeWS. We are using the pNeWS release from Parallax on a Sun 3/160. Palettes: How does NeWS (specifically pNeWS) handle color? Can the default palette be changed? If so, how? You can't change the colortables. You ask for a color with PostScript, and the particular NeWS implementation gives you the best that it can do. pNeWS uses the same color values as Sun NeWS, but in a different order. This is to make programming of graphics over video transparent to the programmer. Mapping tables are created for the 32 hardware available Graphics Over Video colors. These tables convert a full color RGB triple into a correct color index for the hardware. Different tables are used for converting Normal Graphics Canvases. If you really need to change the colormap on the 1280, you can use the "kitchen sink command" *parallax*. This is an added PostScript operator in pNeWS which allows you to send write/read directly to the board. You will need a manual on the 1280 to get the hex codes for changing the color table. Saving Postscript Canvas as Rasterfile: The demos that are provided show methods of loading rasterfiles and painting on a canvas. Is the reverse operation supported, i.e., are postscript/NeWS primitives provided that save a canvas as a rasterfile? Not until pNeWS 1.1 is released from Parallax. It was demoed in February, so I'm sure it will be along soon. But if you are really desperate you can use the "kitchen sink command" to do anything, including reading back bits from the board. -greg. From don@brillig.umd.edu Thu Jun 9 23:18:27 1988 Date: Thu, 9 Jun 88 23:18:27 EDT To: NeWS-makers@brillig.umd.edu Subject: What is NDE all about? From: sunquest!whm@arizona.edu (Bill Mitchell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anyone know what NDE, the NeWS Development Environment, is all about? Sun says that specs should be out this summer, but aside from that, the best we've gotten from them is mumbling about an object-oriented system that borrows from Smalltalk-80 and the Andrew Toolkit. I've got some specific questions: What's the model of usage for NDE? Is it client-side callable routines that talk with routines on the server side? Does it include some sort of a langauge that is translated into PostScript and that then runs on the server? Does it have any relation to the Lite* stuff in NeWS 1.1? Any and all facts are welcome. Bill Mitchell sunquest!whm@arizona.edu {allegra,cmcl2,ihnp4,noao}!arizona!sunquest!whm From don@brillig.umd.edu Fri Jun 10 02:33:20 1988 Date: Fri, 10 Jun 88 02:33:20 EDT To: NeWS-makers@brillig.umd.edu Subject: Freezing canvases From: mcvax!unido!ecrcvax!andy@uunet.uu.net (Andrew Dwelly) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is there any way of "freezing" a canvas so that output does not appear on the screen until the canvas is "unfrozen" ?. This is rather like the /Mapped field except that a frozen canvas does not vanish from the screen. Why should I want such a facility ?. Well, it is often better to freeze a window before outputing a complex picture/diagram and then unfreeze it, so that the picture appears all at once. Watching a diagram form piece by piece on the screen seems to draw attention to the performance (or lack of it) of the NeWS server. Andrew Dwelly E.C.R.C. UUCP: mcvax!unido!ecrcvax!andy ArabellaStrasse 17 .....pyramid!ecrcvax!andy D-8000 Muenchen 81, West Germany Bump, Crash\n Listen; who swears ?\n Christopher Robin has fallen down stairs. From don@brillig.umd.edu Fri Jun 10 19:28:01 1988 Date: Fri, 10 Jun 88 19:28:01 EDT To: NeWS-makers@brillig.umd.edu Subject: Does InterViews exist for NeWS? From: cadnetix.COM!gad@uunet.uu.net (Gordon Durand) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anyone know if InterViews (the C++ graphical classes developed for X) has been ported to NeWS or SunView? Are such ports even reasonable or is InterViews intimately tied to X11? Please reply via e-mail. I'll summarize to the net if there is any interest. Thanks. Gordon Durand Internet: gad@cadnetix.com Cadnetix Corp. UUCP: ..!{uunet,boulder}!cadnetix!gad 5775 Flatiron Pkwy. Boulder, CO 80301 From don@brillig.umd.edu Sat Jun 11 19:43:53 1988 Date: Sat, 11 Jun 88 19:43:53 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Freezing canvases From: parallax!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Is there any way of "freezing" a canvas so that output does not appear on the >screen until the canvas is "unfrozen" ?. This is rather like the /Mapped field >except that a frozen canvas does not vanish from the screen. >Why should I want such a facility ?. Well, it is often better to freeze a >window before outputing a complex picture/diagram and then unfreeze it, so that >the picture appears all at once. Watching a diagram form piece by piece on the >screen seems to draw attention to the performance (or lack of it) of the NeWS >server. There is only one way I know of to achieve this affect in NeWS. Create an unmapped canvas the same size as your ClientCanvas. Always draw into this canvas. When you want to update the display, imagecanvas from the unmapped canvas to your ClientCanvas. Make sure that the scale is correctly set when you imagecanvas. If should be WidthOfClientCanvas HeightOfClientCanvas scale. -greg. From don@brillig.umd.edu Wed Jun 15 12:53:32 1988 Date: Wed, 15 Jun 88 12:53:32 EDT To: NeWS-makers@brillig.umd.edu Subject: A NeWS Class Browser From: bvs@sun.com (Bruce V. Schwartz) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) This file contains a NeWS server class browser. It is a good way to roam through the classes loaded into the server. Although it has many deficiencies, (searching, following references), it is generally quite useful. The browser has 5 panes. It is similar in appearance to the Smalltalk browser. The first pane on the top of the window contains the list of classes in the server. The next 3 contain the list of methods, class variables, and instance variables associated with the selected class in the first pane. The bottom pane is used to display information about the current selection. Make selections by clicking on any text in the top panes with the left button. This code was mostly written in August 1987 but was revised to work with NeWS 1.1 in May 1988. Feel free to use it as you will. Suggestions (or improvements!) welcomed. Bruce V. Schwartz Sun Microsystems bvs@sun.com NOTE: Normally, the following would be divided into 2 files, but I've appended them here to make it more fail safe. You can deppend them if you like. In that case, however, the files must be located as: ~/NeWS/browse/pw.ps and ~/NeWS/browse/browse.ps if you want to run them without modification. The file pw.ps contains the classes used by browse.ps. I suggest using the browser to examine those classes!! %--------cut here----------pw.ps------------------- %% $Header: pw.ps,v 1.3 88/06/14 17:17:52 bvs Locked $ % This file contains the classes used by the class browser. % The classes included are: % Picture -- an Item similar in concept to the NeWS1.1 textcanvas % PicWindow -- a LiteWindow that holds Pictures % PicScroll -- a SimpleScrollbar with a few modifications (auto scrolling) % % This code was mostly written in August 1987 but was revised to work with % NeWS 1.1 in May 1988. Feel free to use it as you will. % % Bruce V. Schwartz % Sun Microsystems % bvs@sun.com % systemdict begin systemdict /Item known not { (NeWS/liteitem.ps) run } if systemdict /SimpleScrollbar known not { (NeWS/liteitem.ps) run } if end %% This file contains classes: PicWindow Picture PicScroll /PicWindow LiteWindow dictbegin /PicArray [] def /BorderRight 1 def /BorderLeft 1 def /BorderBottom 1 def dictend classbegin /PaintIcon { 1 fillcanvas .8 setgray IconWidth 2 div 1 sub IconHeight 4 div 5 sub 5 Sunlogo } def /PaintClient { %% (paint client %\n) [ PicArray ] dbgprintf %% PicArray { ( %\n) [ 3 2 roll ] dbgprintf } forall PicArray paintitems } def /setpicarray { /PicArray exch def } def /destroy { %% (destroying arrays\n) [] dbgprintf PicArray { /destroy exch send } forall %% (destroying window\n) [] dbgprintf /destroy super send %% (destroyed window\n) [] dbgprintf } def classend def /PicScrollbar SimpleScrollbar dictbegin /Owner null def /MouseInItem? false def /ScrollMonitor null def /ScrollProcess null def /ScrollDelay 1 60 div 20 div def % 1/10 second /LastX null def /LastY null def dictend classbegin /new { /new super send begin /ScrollMonitor createmonitor def currentdict end } def /setowner { /Owner exch def } def /ClientDown { % - => - CurrentEvent begin XLocation YLocation end /LastY exch def /LastX exch def SetScrollMotion /MouseInItem? true def HiliteItem DoScroll ScrollProcess null ne { ScrollMonitor { ScrollProcess killprocess } monitor } if /ScrollProcess { InteractiveScroll } fork def } def /InteractiveScroll { { ScrollDelay sleep ScrollMonitor { EventInItem? { DoScroll } if } monitor } loop } def /ClientUp { % - => - ScrollMonitor { ScrollProcess killprocess } monitor /ScrollProcess null def /MouseInItem? false def UnhiliteItem ItemValue ItemInitialValue ne { /Notify Owner send } if } def /ClientDrag { % - => - CurrentEvent begin XLocation YLocation end /LastY exch def /LastX exch def CheckItem } def /PaintBar { } def /EraseBox { } def /PaintButtons { BarViewPercent 1 gt { /PaintButtons super send } if } def /PaintBox { % - => - (paint box) %(PaintBox %\n) [ BarViewPercent ] dbgprintf %(pause...) [] dbgprintf 1 60 div sleep (!!\n) [] dbgprintf gsave 10 dict begin /x 1 def /w ItemWidth 2 sub def BarViewPercent 1 le { .5 setgray x ButtonSize w ItemHeight ButtonSize dup add sub rectpath fill } { 1 1 BarViewPercent div sub 1 ItemValue sub mul ItemHeight ButtonSize dup add sub mul ButtonSize add /y exch def 1 BarViewPercent div ItemHeight ButtonSize dup add sub mul /h exch def % % do the normal bar % ItemFillColor setcolor x ButtonSize w y ButtonSize sub rectpath fill x y h add w ItemHeight ButtonSize sub y sub h sub rectpath fill % % do the big scroll box % /ybut ItemValue ValueToY def .5 setgray x y w ybut y sub rectpath fill x ybut ButtonSize add w h ButtonSize sub ybut sub y add rectpath fill % % do the little scroll box % ItemValue BoxPath BoxFillColor setcolor gsave fill grestore ItemBorderColor setcolor eofill } ifelse end /ItemPaintedValue ItemValue def grestore /Notify Owner send } def /EventInItem? { % - => bool ScrollMotion { /ScrollAbsolute { false } /ScrollPageForward % top { LastX dup 0 ge exch ButtonSize le LastY ItemValue ValueToY ButtonSize add ge LastY ItemHeight ButtonSize sub le and and and } /ScrollPageBackward % bottom { LastX dup 0 ge exch ButtonSize le LastY ButtonSize ge LastY ItemValue ValueToY le and and and } /ScrollLineForward % top { LastX 0 ge LastX ButtonSize le LastY ItemHeight ButtonSize sub ge LastY ItemHeight le and and and } /ScrollLineBackward % bottom { LastX 0 ge LastX ButtonSize le LastY 0 ge LastY ButtonSize le and and and } } case BarViewPercent 1 le { pop false } if } def /CheckItem { ScrollMotion { /ScrollAbsolute {DoScroll} /ScrollPageForward % top { /MouseInItem? EventInItem? def } /ScrollPageBackward % bottom { /MouseInItem? EventInItem? def } /ScrollLineForward % top { EventInItem? dup { MouseInItem? not { HiliteItem } if } { MouseInItem? { UnhiliteItem } if } ifelse /MouseInItem? exch def } /ScrollLineBackward % bottom { EventInItem? dup { MouseInItem? not { HiliteItem } if } { MouseInItem? { UnhiliteItem } if } ifelse /MouseInItem? exch def } } case } def /HiliteItem { ScrollMotion { /ScrollAbsolute { } /ScrollPageForward { } /ScrollPageBackward { } /ScrollLineForward % top { 0 ItemHeight ButtonSize ButtonSize neg rectpath 5 setrasteropcode fill } /ScrollLineBackward % bottom { 0 0 ButtonSize ButtonSize rectpath 5 setrasteropcode fill } } case } def /UnhiliteItem { gsave ScrollMotion { /ScrollAbsolute {} /ScrollPageForward {} /ScrollPageBackward {} /ScrollLineForward % top { 0 ItemHeight ButtonSize sub ButtonSize ButtonSize rectpath clip PaintButtons } /ScrollLineBackward % bottom { 0 0 ButtonSize ButtonSize rectpath clip PaintButtons } } case grestore } def classend def /Picture Item dictbegin /BufferCanvas null def /BufferWidth 0 def /BufferHeight 0 def /HScrollbar null def /VScrollbar null def /HScrollbar? true def /VScrollbar? true def /HScrollWidth 0 def /VScrollWidth 0 def /ScrollWidth 16 def /ZoomFactor 1 def /NotifyUserDown { pop pop } def % x y => - /NotifyUserUp { pop pop } def % x y => - /NotifyUserDrag { pop pop } def % x y => - /NotifyUserEnter { pop pop } def % x y => - /NotifyUserExit { pop pop } def % x y => - dictend classbegin /new { % parentcanvas width height => instance % (new begin\n) [] dbgprintf /new super send begin /BufferHeight ItemHeight def /BufferWidth ItemWidth def CreateScrollbars CreateBuffer currentdict end % (new end\n) [] dbgprintf } def /destroy { HScrollbar null ne { null /setowner HScrollbar send } if VScrollbar null ne { null /setowner VScrollbar send } if %% BufferCanvas /Mapped false put %% /BufferCanvas null def } def /setzoom { % zoomfactor => - /ZoomFactor exch def } def /reshape { % x y w h => - /reshape super send ReshapeScrollbars } def /reshapebuffer { % w h => - /BufferHeight exch def /BufferWidth exch def ReshapeBuffer ReshapeScrollbars } def /getcanvas { BufferCanvas } def /updatecanvas { PaintBuffer } def /makestartinterests { /makestartinterests HScrollbar send /makestartinterests VScrollbar send [ exch aload length 2 add -1 roll aload pop ] % join 2 arrays /makestartinterests super send [ exch aload length 2 add -1 roll aload pop ] % join 2 arrays } def /PaintItem { %% (PaintItem begin\n) [] dbgprintf %% ItemCanvas setcanvas .9 fillcanvas PaintBuffer /paint VScrollbar send /paint HScrollbar send %% (PaintItem end\n) [] dbgprintf } def /Notify { % (picture got notified\n) [] dbgprintf NotifyUser PaintBuffer } def /PaintBuffer { % (PaintBuffer begin \n) [ ] dbgprintf gsave ItemCanvas setcanvas % % compute clipping region % 0 HScrollWidth ItemWidth VScrollWidth sub ItemHeight HScrollWidth sub rectpath % (clip to % % % %\n) [ pathbbox ] dbgprintf clip % % compute translation % BufferWidth ZoomFactor mul ItemWidth sub VScrollWidth add neg dup 0 lt { 1 /getvalue HScrollbar send sub mul } { pop 0 } ifelse BufferHeight ZoomFactor mul ItemHeight sub HScrollWidth add neg dup 0 lt { 1 /getvalue VScrollbar send sub mul } { } ifelse HScrollWidth add % 2 copy (translate by % %\n) [ 4 2 roll ] dbgprintf translate BufferWidth BufferHeight % 2 copy (scale by % %\n) [ 4 2 roll ] dbgprintf scale ZoomFactor dup scale pause BufferCanvas imagecanvas pause grestore % (PaintBuffer end\n) [ ] dbgprintf } def /CreateBuffer { % - => - /BufferCanvas framebuffer newcanvas def BufferCanvas /Retained true put BufferCanvas /Opaque true put ReshapeBuffer } def /ReshapeBuffer { % - => - gsave framebuffer setcanvas 0 0 BufferWidth BufferHeight rectpath BufferCanvas reshapecanvas grestore } def /CreateScrollbars { % - => - % (begin CreateScrollbars\n) [] dbgprintf /HScrollWidth HScrollbar? { ScrollWidth } { 0 } ifelse def /VScrollWidth VScrollbar? { ScrollWidth } { 0 } ifelse def ItemWidth VScrollWidth le { /VScrollWidth ScrollWidth 2 div def } if ItemHeight HScrollWidth le { /HScrollWidth ScrollWidth 2 div def } if /HScrollbar [1 0 .01 .1 BufferWidth ItemWidth VScrollWidth sub div ] 1 {} ItemCanvas /new PicScrollbar send dup /BarVertical? false put def /VScrollbar [1 0 .01 .1 BufferHeight ItemHeight HScrollWidth sub div ] 1 {} ItemCanvas /new PicScrollbar send def self /setowner HScrollbar send self /setowner VScrollbar send % (end CreateScrollbars\n) [] dbgprintf } def /ReshapeScrollbars { /HScrollWidth HScrollbar? { ScrollWidth } { 0 } ifelse def /VScrollWidth VScrollbar? { ScrollWidth } { 0 } ifelse def 10 dict begin /h ItemHeight def /w ItemWidth def /s ScrollWidth def [1 0 .01 .1 BufferWidth ItemWidth VScrollWidth sub div ] /setrange HScrollbar send [1 0 .01 .1 BufferHeight ItemHeight HScrollWidth sub div ] /setrange VScrollbar send HScrollbar? { 0 0 w VScrollWidth sub s } { 0 0 0 0 } ifelse % 4 copy (hscroll % % % %\n) [ 6 2 roll ] dbgprintf /reshape HScrollbar send VScrollbar? { w s sub HScrollWidth s h HScrollWidth sub } { 0 0 0 0 } ifelse % 4 copy (vscroll % % % %\n) [ 6 2 roll ] dbgprintf /reshape VScrollbar send end } def /ClientDown { % (Picture ClientDown\n) [] dbgprintf % compute translation % BufferWidth ZoomFactor mul ItemWidth sub VScrollWidth add neg dup 0 lt { 1 /getvalue HScrollbar send sub mul } { pop 0 } ifelse BufferHeight ZoomFactor mul ItemHeight sub HScrollWidth add neg dup 0 lt { 1 /getvalue VScrollbar send sub mul } { } ifelse HScrollWidth add % translatex translatey CurrentEvent /YLocation get sub neg exch CurrentEvent /XLocation get sub neg exch % (n: %\n) [ NotifyUserDown ] dbgprintf { NotifyUserDown } fork } def /ClientUp { % (Picture ClientUp\n) [] dbgprintf CurrentEvent begin XLocation YLocation end NotifyUserUp } def /ClientDrag { % (client drag\n) [] dbgprintf CurrentEvent begin XLocation YLocation end NotifyUserDrag } def /ClientEnter { %% (client enter\n) [] dbgprintf CurrentEvent begin XLocation YLocation end NotifyUserEnter } def /ClientExit { %% (client exit\n) [] dbgprintf CurrentEvent begin XLocation YLocation end NotifyUserExit } def classend def %--------cut here----------browse.ps------------------- %! %% $Header: browse.ps,v 1.2 88/06/14 17:17:45 bvs Locked $ % % This file contains a NeWS server class browser. % % The browser is built on the classes defined in pw.ps. The class % browser has 5 panes. It is similar in appearance to the Smalltalk % browser. The first pane on the top of the window contains the list of % classes in the server. The next 3 contain the list of methods, class % variables, and instance variables associated with the selected class in % the first pane. The bottom pane is used to display information about % the current selection. % % This code was mostly written in August 1987 but was revised to work with % NeWS 1.1 in May 1988. Feel free to use it as you will. % % Bruce V. Schwartz % Sun Microsystems % bvs@sun.com % % you will have to alter the following line unless you keep this program % in ~/NeWS/browse. userdict /PicWindow known not { (NeWS/browse/pw.ps) run } if userdict begin /Font15 /Times-Roman findfont 15 scalefont def /StartWait { userdict begin /SaveCursor [ currentcanvas getcanvascursor ] def /hourg /hourg_m fboverlay setstandardcursor end } def /EndWait { userdict begin SaveCursor aload pop setcanvascursor end } def /DoubleBubbleSort % keyarray valuearray => - (sorts in place) { %% 2 copy (double % %\n) [ 4 2 roll ] dbgprintf %% StartWait 20 dict begin /values exch def /keys exch def /bound keys length 1 sub def /check 0 def { /t -1 def 0 1 bound 1 sub { /i exch def /j i 1 add def /keysi keys i get def /keysj keys j get def keysi keysj gt { keys i keysj put keys j keysi put /valuesi values i get cvlit def /valuesj values j get cvlit def values i valuesj put values j valuesi put /t j def } if } for t -1 eq { exit } { /bound t def } ifelse pause } loop end %% EndWait } def /PicArray [ ] def /win framebuffer /new PicWindow send def { /FrameLabel (Class Browser -- make selections with left button) def } /doit win send 100 100 800 517 /reshape win send /map win send /ClassKeys [] def /InstKeys [] def /MethodKeys [] def /VarKeys [] def /ClassPic win /ClientCanvas get 300 1000 /new Picture send def % classes /MethodPic win /ClientCanvas get 300 1000 /new Picture send def % methods /VarPic win /ClientCanvas get 300 1000 /new Picture send def % class var /InstPic win /ClientCanvas get 300 1000 /new Picture send def % ints var /TextPic win /ClientCanvas get 800 600 /new Picture send def % text /PicArray [ ClassPic InstPic MethodPic VarPic TextPic ] def PicArray /setpicarray win send ClassPic /HScrollbar? false put InstPic /HScrollbar? false put MethodPic /HScrollbar? false put VarPic /HScrollbar? false put TextPic /HScrollbar? false put 000 200 200 300 /reshape ClassPic send 200 200 200 300 /reshape MethodPic send 400 200 200 300 /reshape VarPic send 600 200 200 300 /reshape InstPic send 0 0 800 200 /reshape TextPic send 0 /setvalue ClassPic /VScrollbar get send 0 /setvalue InstPic /VScrollbar get send 0 /setvalue MethodPic /VScrollbar get send 0 /setvalue VarPic /VScrollbar get send 0 /setvalue TextPic /VScrollbar get send /ClassColor 1 .8 .8 rgbcolor def /InstColor 1 .8 1 rgbcolor def /MethodColor .8 1 .8 rgbcolor def /VarColor .8 .8 1 rgbcolor def /TextColor .8 .8 .8 rgbcolor def /getcanvas ClassPic send setcanvas ClassColor fillcanvas 0 0 0 rgbcolor strokecanvas /getcanvas InstPic send setcanvas InstColor fillcanvas 0 0 0 rgbcolor strokecanvas 0 280 moveto (Class Insts) show /getcanvas MethodPic send setcanvas MethodColor fillcanvas 0 0 0 rgbcolor strokecanvas 0 280 moveto (Class Methods) show /getcanvas VarPic send setcanvas VarColor fillcanvas 0 0 0 rgbcolor strokecanvas 0 280 moveto (Class Vars) show /getcanvas TextPic send setcanvas TextColor fillcanvas 0 0 0 rgbcolor strokecanvas 0 180 moveto (Text) show PicArray forkitems pop /ShowArray { % array color pic 10 dict begin /pic exch def /color exch def /a exch def Font15 setfont %% 300 a length 18 mul 15 add /reshapebuffer pic send /getcanvas pic send setcanvas color fillcanvas 0 0 0 rgbcolor setcolor /k pic /BufferHeight get def a { /k k 18 sub def 5 k moveto show } forall /updatecanvas pic send end } def %[] ClassColor ClassPic ShowArray %[] MethodColor MethodPic ShowArray %[] VarColor VarPic ShowArray %[] InstColor InstPic ShowArray %[] TextColor TextPic ShowArray /DoClasses { /getcanvas ClassPic send setcanvas 10 dict begin /ClassKeys [] def /ClassVals [] def [ systemdict userdict ] { { /val exch cvlit def /key exch cvlit def val type /dicttype eq { val /ClassName known { /ClassKeys ClassKeys 999 key 256 string cvs arrayinsert def /ClassVals ClassVals 999 val arrayinsert def } if } if pause } forall } forall ClassKeys ClassVals end /ClassVals exch def /ClassKeys exch def ClassKeys ClassVals DoubleBubbleSort ClassKeys ClassColor ClassPic ShowArray } def /DoMethods { % classdict => - 10 dict begin /classdict exch def /MethodKeys [] def /MethodVals [] def classdict { /val exch def /key exch def /val load type /arraytype eq /val load xcheck and { /MethodKeys MethodKeys 999 key 256 string cvs arrayinsert def /MethodVals MethodVals 999 /val load cvlit arrayinsert def } if pause } forall MethodKeys MethodVals end userdict begin /MethodVals exch def /MethodKeys exch def MethodKeys MethodVals DoubleBubbleSort MethodKeys MethodColor MethodPic ShowArray end } def /DoVars { % classdict => - 10 dict begin /classdict exch def /VarKeys [] def /VarVals [] def classdict { /val exch def /key exch def /val load type /arraytype eq /val load xcheck and not { /VarKeys VarKeys 999 key 256 string cvs arrayinsert def /VarVals VarVals 999 /val load cvlit arrayinsert def } if pause } forall VarKeys VarVals end userdict begin /VarVals exch def /VarKeys exch def VarKeys VarVals DoubleBubbleSort VarKeys VarColor VarPic ShowArray end } def /DoInsts { % classdict => - %(DoInsts begin***\n) [] dbgprintf 10 dict begin /classdict exch def /InstKeys [] def /InstVals [] def classdict /InstanceVarDict get dup null eq { pop [] } if { /val exch def /key exch def /InstKeys InstKeys 999 key 256 string cvs arrayinsert def /InstVals InstVals 999 /val load arrayinsert def pause } forall InstKeys InstVals end userdict begin /InstVals exch def /InstKeys exch def InstKeys InstVals DoubleBubbleSort InstKeys InstColor InstPic ShowArray end %(DoInsts end***\n) [] dbgprintf } def /LastClassPick null def /ClassPick % x y => - { userdict begin Font15 setfont LastClassPick null ne { null SetMethodPick null SetVarPick null SetInstPick gsave %(unhilite %\n) [ LastClassPick ] dbgprintf /getcanvas ClassPic send setcanvas 0 1000 LastClassPick 1 add 18 mul sub 3 sub 300 18 rectpath ClassColor setcolor fill 0 0 0 rgbcolor setcolor 5 1000 LastClassPick 1 add 18 mul sub moveto ClassKeys LastClassPick get show grestore } if 10 dict begin /y exch def /x exch def %% put scroll bars back to top 0 /setvalue InstPic /VScrollbar get send 0 /setvalue MethodPic /VScrollbar get send 0 /setvalue VarPic /VScrollbar get send 0 /setvalue TextPic /VScrollbar get send /k 1000 y sub 18 div floor def %(pick is % \n ) [ k ] dbgprintf k ClassKeys length 1 sub le { %(pick is % \n ) [ ClassKeys k get ] dbgprintf /getcanvas ClassPic send setcanvas %(hilite %\n) [ k ] dbgprintf 0 1000 k 1 add 18 mul sub 3 sub 300 18 rectpath 0 0 0 rgbcolor setcolor fill ClassColor setcolor 0 5 1000 k 1 add 18 mul sub moveto ClassKeys k get show /updatecanvas ClassPic send [] MethodColor MethodPic ShowArray [] VarColor VarPic ShowArray [] InstColor InstPic ShowArray [] TextColor TextPic ShowArray [ (CLASS ") ClassKeys k get 256 string cvs (") append append ClassVals k get /ParentDictArray known { ClassVals k get /ParentDictArray get % ParentDictArray { /ClassName get 256 string cvs ( ) exch append } forall } if ] TextColor TextPic ShowArray ClassVals k get DoMethods ClassVals k get DoVars ClassVals k get DoInsts k } { /updatecanvas ClassPic send null } ifelse end /LastClassPick exch def end } def ClassPic /NotifyUserDown { userdict /ClassPick get exec } put /SetInstPick {pop} def /LastInstPick null def /SetInstPick % newpick => - { userdict begin Font15 setfont LastInstPick null ne { gsave /getcanvas InstPic send setcanvas 0 1000 LastInstPick 1 add 18 mul sub 3 sub 300 18 rectpath InstColor setcolor fill 0 0 0 rgbcolor setcolor 5 1000 LastInstPick 1 add 18 mul sub moveto InstKeys LastInstPick get show grestore } if /LastInstPick exch def % pick up newpick %% (new InstPick is % \n ) [ LastInstPick ] dbgprintf LastInstPick null ne { /getcanvas InstPic send setcanvas 0 1000 LastInstPick 1 add 18 mul sub 3 sub 300 18 rectpath 0 0 0 rgbcolor setcolor fill InstColor setcolor 0 5 1000 LastInstPick 1 add 18 mul sub moveto InstKeys LastInstPick get show } if /updatecanvas InstPic send LastInstPick null ne { [] TextColor TextPic ShowArray [ (INSTANCE VARIABLE) ( ") InstKeys LastInstPick get 256 string cvs (") append append append InstVals LastInstPick get type { /arraytype { () InstVals LastInstPick get ExpandArray } /dicttype { () InstVals LastInstPick get ExpandDict } /Default {() InstVals LastInstPick get 256 string cvs append} } case ] TextColor TextPic ShowArray } if end } def /InstPick { null SetMethodPick null SetVarPick userdict begin 10 dict begin /y exch def /x exch def /k 1000 y sub 18 div floor def %% (pick is % \n ) [ k ] dbgprintf k dup end InstKeys length 1 sub le { SetInstPick } { pop } ifelse end } def InstPic /NotifyUserDown { userdict /InstPick get exec } put /ArrayDepth 0 def /ExpandArray { % string array => strings /ArrayDepth ArrayDepth 1 add def exch ({) append exch () ArrayDepth { ( ) append } repeat exch { dup type /arraytype eq { ExpandArray } { cvlit 256 string cvs append ( ) append dup stringwidth pop 700 gt { () ArrayDepth { ( ) append } repeat } if } ifelse } forall /ArrayDepth ArrayDepth 1 sub def () ArrayDepth { ( ) append } repeat (} ) append } def /ExpandDict { % dict => strings { 256 string cvs ( ) exch append exch 256 string cvs ( ) exch append { dup stringwidth pop 250 lt { ( ) append } { exit } ifelse } loop exch append } forall } def /LastMethodPick null def /SetMethodPick % newpick => - { userdict begin Font15 setfont LastMethodPick null ne { gsave /getcanvas MethodPic send setcanvas 0 1000 LastMethodPick 1 add 18 mul sub 3 sub 300 18 rectpath MethodColor setcolor fill 0 0 0 rgbcolor setcolor 5 1000 LastMethodPick 1 add 18 mul sub moveto MethodKeys LastMethodPick get show grestore } if /LastMethodPick exch def % pick up newpick %% (new MethodPick is % \n ) [ LastMethodPick ] dbgprintf LastMethodPick null ne { /getcanvas MethodPic send setcanvas 0 1000 LastMethodPick 1 add 18 mul sub 3 sub 300 18 rectpath 0 0 0 rgbcolor setcolor fill MethodColor setcolor 0 5 1000 LastMethodPick 1 add 18 mul sub moveto MethodKeys LastMethodPick get show } if /updatecanvas MethodPic send LastMethodPick null ne { [] TextColor TextPic ShowArray [ (METHOD ") MethodKeys LastMethodPick get 256 string cvs (") append append () MethodVals LastMethodPick get ExpandArray ] TextColor TextPic ShowArray } if end } def /MethodPick { null SetVarPick null SetInstPick userdict begin 10 dict begin /y exch def /x exch def /k 1000 y sub 18 div floor def %% (pick is % \n ) [ k ] dbgprintf k dup end MethodKeys length 1 sub le { SetMethodPick } { pop } ifelse end } def MethodPic /NotifyUserDown { userdict /MethodPick get exec } put /LastVarPick null def /SetVarPick % newpick => - { userdict begin Font15 setfont LastVarPick null ne { gsave /getcanvas VarPic send setcanvas 0 1000 LastVarPick 1 add 18 mul sub 3 sub 300 18 rectpath VarColor setcolor fill 0 0 0 rgbcolor setcolor 5 1000 LastVarPick 1 add 18 mul sub moveto VarKeys LastVarPick get show grestore } if /LastVarPick exch def % pick up newpick %% (new VarPick is % \n ) [ LastVarPick ] dbgprintf LastVarPick null ne { /getcanvas VarPic send setcanvas %(hilite %\n) [ LastVarPick ] dbgprintf 0 1000 LastVarPick 1 add 18 mul sub 3 sub 300 18 rectpath 0 0 0 rgbcolor setcolor fill VarColor setcolor 0 5 1000 LastVarPick 1 add 18 mul sub moveto VarKeys LastVarPick get show } if /updatecanvas VarPic send LastVarPick null ne { [] TextColor TextPic ShowArray [ (CLASS VARIABLE) ( ") VarKeys LastVarPick get 256 string cvs (") append append append VarVals LastVarPick get type %dup (type was %\n) [ 3 2 roll ] dbgprintf { /arraytype { () VarVals LastVarPick get ExpandArray } /dicttype { () VarVals LastVarPick get ExpandDict } /Default { () VarVals LastVarPick get 256 string cvs append } } case ] TextColor TextPic ShowArray } if end } def /VarPick { null SetMethodPick null SetInstPick userdict begin 10 dict begin /y exch def /x exch def /k 1000 y sub 18 div floor def %% (pick is % \n ) [ k ] dbgprintf k dup end VarKeys length 1 sub le { SetVarPick } { pop } ifelse end } def VarPic /NotifyUserDown { userdict /VarPick get exec } put DoClasses end From don@brillig.umd.edu Wed Jun 15 21:22:13 1988 Date: Wed, 15 Jun 88 21:22:13 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS BuGS From: David Kurlander Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Here are a few bugs that I've encountered within the last few days. I'd be interested in hearing whether they are known bugs and whether there are plans to fix them in an upcoming release. 1) If there are small numbers in the matrix argument to concat, a typecheck error results. Example: [1 1e-5 1e-5 1 0 0] concat (Our local NeWS GuRU looked at the source, and traced this problem down to a missing break in a case statement in the C routine which implements concat.) 2) The translation component of the matrix argument to makefont seems to be ignored. This following code fragment will produce different results under NeWS than on the LaserWriter: 0 setgray 10 10 moveto /Times-Roman findfont 30 scalefont setfont (Hello World) show /Times-Roman findfont [30.0 0.0 0.0 30.0 100.0 100.0] makefont setfont (Hi Mom) show showpage I expect that this last problem has been widely encountered. Is it documented by Sun? David Kurlander Columbia University djk@columbia.edu From don@brillig.umd.edu Thu Jun 16 19:05:36 1988 Date: Thu, 16 Jun 88 19:05:36 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS/X merge performance question From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Has anybody discussed how this merge will effect the performance of the server? There are certainly situations now where the server could be a little faster :-), and I'm wondering how the integration will affect this. Thanks in advance. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Fri Jun 17 23:27:17 1988 Date: Fri, 17 Jun 88 23:27:17 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS psview and adobe filters From: mcvax!enea!kth!draken!larsa@uunet.uu.net (Lars Andersson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We have got NeWS 1.1 running on a SUN 3/60 under SUN os 3.4. I expected to be able to preview, using psview, the output from transcript filters (pscat, psdit etc) intended for a laser- writer without any change. This turned out to be too optimistic, however. After some trouble I was able to identify the changes to the prolog file needed to be able to view the output from ptroff (which uses pscat). Actually, I would like to go on and preview the output from psdit (including modifications for psfig!) and so on. So, does anyone know of a way to make psview behave more like a laserwriter? Maybe this is a question that doesn't have an answer, but any information would be appreciated. Lars Andersson larsa@nada.kth.se From don@brillig.umd.edu Fri Jun 17 23:27:40 1988 Date: Fri, 17 Jun 88 23:27:40 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: A NeWS Class Browser From: imagine!pawl17.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <56572@sun.uucp> bvs@sun.UUCP (Bruce Schwartz) writes: >This file contains a NeWS server class browser. It is a good way to >roam through the classes loaded into the server. Although it has >many deficiencies, (searching, following references), it is generally >quite useful. Looks interesting, but... The copy that got here has the following as the last few lines: > /makestartinterests { > /makestartinterests HScrollbar send > /makestartinterests VScrollbar send > [ exch aload length 2 add -1 roll aload pop ] % join 2 arrays > /makestartinterests super send > [ exch aload lenQUIT This would seem to indicate that someone, somewhere got mad and zapped the file. Is this stuff available somewhere for anonymous ftp? Please do _not_ send me a copy as I have no disk space - and for things like this need to ftp it each time i need it (sort of a _big_ slow network file system that requires manual intervention to get every file). jeff putnam jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu "People would rather believe a simple lie than the complex truth." From don@brillig.umd.edu Sun Jun 19 07:54:38 1988 Date: Sun, 19 Jun 88 07:54:38 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS on a Sun 2/120 From: ken@gatech.edu (Ken Seefried iii) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I will be recieving a Sun 2/120 workstation in a few weeks. I am wondering if anyone is running NeWS on the Sun 2 series machines and what their impressions are. BTW, the 2/120 has 4MB RAM and 130MB disk... ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs, ken@gatech.edu inhp4, masscomp, rlgvax, sb1, uf-cgrl, ccastks@gitvm1.bitnet unmvax, ut-ngp, ut-sally}!gatech!ken soon to be open: ...!gatech!spooge!ken (finally ;'}) From don@brillig.umd.edu Sat Jun 25 04:44:52 1988 Date: Sat, 25 Jun 88 04:44:52 EDT To: NeWS-makers@brillig.umd.edu Subject: Press release- IBM CG3270 From: sundc!joel@Sun.COM (Joel McClung - Federal TS Mgr Sun Washington DC) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm sure EVERYONE has been waiting with baited breath for this; I know *I* have! :-) --joel ------------------------------ SUN INTRODUCES COLOR GRAPHIC 3270 TERMINAL EMULATOR; First Application Product Based on NeWS MOUNTAIN VIEW, CA -- June 20, 1988 -- Sun Microsystems, Inc., strengthened its offering of IBM connectivity products with the introduction of its color graphic 3270 terminal emulator, SunLink CG3270. SunLink CG3270 emulates an IBM 3179G display terminal and enables Sun workstation users to access IBM host mainframe applications, including those which use color and host graphics, such as those generated by IBM's GDDM (graphical data display manager). Sunlink CG3270 provides users with unprecedented power in host interactive communications, with features such as display support for host color graphics, dynamic scaling of displayed images, multiple terminal sessions per workstation, laser printer image compatibility, and powerful local display manipulation. SunLink CG3270 demonstrates the display- and network-oriented benefits and advanced imaging technology of NeWS (Network extensible Window System.) SunLink CG3270 enables users to take full advantage of Sun's distributed processing model and Open Systems Network connectivity products. SunLink CG3270 includes a WYSIWYG keyboard mapping utility and menu-driven file transfer that make it easy to use. This is consistent with Sun's drive to reduce the complexities faced by end users in a multivendor computing environment. SunLink CG3270 is part of the SunLink family of data communication products that allow Sun workstations to communicate with other vendors' systems and products. SunLink CG3270 can be used with each of the three SunLink 3270 communication gateway products Sun offers, providing network managers with a variety of ways to attach Sun networks to IBM mainframes, including SNA, BSC or direct channel connections. SunLink CG3270 uses NeWS version 1.1, which Sun is currently shipping. In addition, SunLink CG3270 will be fully compatible with the X11/NeWS merged window system which Sun will ship later this year. With X11/NeWS, users will be able to simultaneously display on their workstation screens both X11-based and NeWS-based application windows, such as a SunLink CG3270 terminal session. "We believe our SunLink CG3270 offering will be the premier 3270 terminal emulation product on the market," said Larry Garlick, Vice President of Sun's Distributed Systems Group. "Sun provides innovative ways to integrate Sun workstations and IBM systems. Products like SunLink CG3270 and the SunLink Channel Adapter allow our customers to preserve their investments in existing systems; users are able to retain access to host-based applications, while at the same time make use of the powerful local processing, graphics and networking capabilities of workstations -- all from one desktop." Applications areas for SunLink CG3270 include the financial services market, where color on a display screen connected to an IBM mainframe helps securities traders identify specific types of information on the screen more readily. In automotive manufacturing and aerospace markets, large numbers of drawings and charts are stored on IBM mainframes. SunLink CG3270 will allow users to display these images on Sun workstations, capture them locally, and route them to laser printers if desired. Sun's Open Systems Network product strategy -- composed of the Open Network Computing (ONC) environment, X11/NeWS network-based window system, SunLink data communication products, and Catalyst third-party networking products -- combines a variety of industry standard networking technologies to create a transparent, networked computing environment. The Open Systems Network product strategy is the basis of Sun's "The Network Is The Computer" concept, in which users have access to all network resources from their desktop. As the latest implementation of this product strategy, SunLink CG3270 draws upon several Open Systems Network technologies, demonstrating many of the benefits of the distributed computing model. SunLink CG3270 enhances the SAA compatibility of the Sun product line, which today provides users with support for 3270 data streams, LU Type 6.2, PU Type 2.1, Document Interchange Architecture, X.25, and now, GDDM. SunLink CG3270 is priced at $950 (U.S. list) per terminal session with discounts offered for multiple terminal session licenses. SunLink CG3270 will be available in the third quarter of 1988. From don@brillig.umd.edu Sat Jun 25 05:36:42 1988 Date: Sat, 25 Jun 88 05:36:42 EDT To: NeWS-makers@brillig.umd.edu Subject: Client/Server communications From: mday@cgl.ucsf.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm having some problems communicating between the NeWS server and client. Perhaps a more enlightened NeWS programmer can point out the error in my ways. The first problems I am having, is coming up with an acceptable method of sending a larger number of lineto's from a client, in response to an event posted by the server. I have tried several approaches, with no success. Plan A) Normally in a C program, I would pass the data array by address. Of course this won't work under NeWS because the client and server don't share address space. Plan B) Use the cid utilities to synchronize communication between the client and the server. In response to a repaint event at the server, invoke a procedure that sets up the correct graphics context. Then for each vector to be drawn, perform lineto_ps (id, x, y) where lineto_ps is defined to be: cdef lineto_ps (int id, float x, float y) id { x y lineto } sendcidevent The problem with this approach is it is painfully slow. The NeWS Application Scenario admits that the cid utilities have too much overhead to be used when sending lots of vectors. Unfortunately, the manual doesn't spell out a more efficient alternative. Plan C) Only use the cid utilities to set up the correct graphics context. After the context is set up, invoke a PostScript routine on the server that performs a lineto without using sendcidevent. Since, cid utilities are only used to begin and terminate each event, this shouldn't exhibit the poor performance of Plan B. Unfortunately, my implementation of this doesn't seem to work. It seems that there is an implicit save and restore of the graphics context bracketing each sendcidevent, so that the lineto procedure isn't being sent to the correct canvas, or perhaps is being ignored completely. The second problem I am having is closely related to the above. I would like to send a variable number of character strings to the NeWS server in response to a user generated event. I haven't found any way of invoking a cdef routine with a variable number of arguments, so a reasonable thing to do is put all of the strings into an array on the stack. As an example my PostScript code for a repaint event is: /PaintClient { DAMAGE_TAG tagprint uniquecid dup typedprint [exch cidinterest] forkeventmgr waitprocess pop show_strings } def cdef repaired (int id) id { exit } sendcidevent the show_strings procedure simply prints the passed strings into a window. The server side code looks like: if (get_damage(&id)) { while (fgets(buff, sizeof(buff), fptr)) psio_fprintf(PostScript, "%s\n", buff); repaired(id); } This approach fails, because after the waitprocess exits, there isn't anything on the stack. I assumed that by using psio_fprintf, all of the characters I sent would end on the stack of the server. This is obviously not happening. Does using waitprocess preclude the use of the psio routines? Does anybody have any pointers? Should I abandon the use of the cid utilities? The NeWS manuals suggest that synchronization between client and server is a good thing, but either I am not using these utilities correctly, or they are more trouble than they are worth. Thanks in advance, Mark ---------- Mark Day UUCP: ..ucbvax!ucsfcgl!mday ARPA: mday@cgl.ucsf.edu BITNET: mday@ucsfcgl.BITNET From don@brillig.umd.edu Sat Jun 25 05:37:07 1988 Date: Sat, 25 Jun 88 05:37:07 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a Sun 2/120 From: steinmetz!csb1!aronson@itsgw.rpi.edu (marc aronson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We have tried to run NeWS on a sun 2/50 (thats 2, not 3!) with something between 6 and 8 meg of memory. It is very slow. Marc Aronson aronson@ge-crd.arpa -- steinmetz!sungod!aronson From don@brillig.umd.edu Sat Jun 25 05:38:32 1988 Date: Sat, 25 Jun 88 05:38:32 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh From: zodiac!deimos!booter@ames.arc.nasa.gov (Elaine Richards) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1990@sics.se> hans@sics.se (Hans Eriksson) writes: > >Does anyone know (or have heard of) an implementation of NeWS for >Macintosh? > >Hans >-- The Grasshopper Group in San Francisco has a NeWS implementation for the mac. It is retailing for 225$ (I think - it is not t o pricey). They have a booth at USENIX right now and it demos pretty nicely. I will tell one of them to contact you for mailing information. Er From don@brillig.umd.edu Tue Jun 28 17:47:25 1988 Date: Tue, 28 Jun 88 17:47:25 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Client/Server communications From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Does anybody have any pointers? Should I abandon the use of the cid utilities? >The NeWS manuals suggest that synchronization between client and server is >a good thing, but either I am not using these utilities correctly, or they >are more trouble than they are worth. I am assuming that you have a simple application. It is hard to give good advice without more details. Blow off the cid utilities. In response to damage have your PaintClient send something back to the C code. (D) print. In most cases sending simple ascii messages from the PostScript to the C code is plenty fast, and much easier to debug. Have your C code block with a psio_getc(PostScript). Check for an ioerror, and then switch off the character you receive. ... case 'D': myps_begindamage(); for(i = 0; i < points ; i++) { myps_sendpoints(points[i].x, points[i].y); } myps_doline(points); myps_enddamage(); break; ...... cdef myps_begindamage() gsave ... set state mywindow /ClientCanvas get setcanvas cdef myps_enddamage() grestore cdef myps_sendpoints(float x, float y) x y % shove 2 points on stack cdef myps_doline(int points) points % loop to draw lines Good Luck. -greg. From don@brillig.umd.edu Tue Jun 28 17:49:23 1988 Date: Tue, 28 Jun 88 17:49:23 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh From: guyton%condor@rand-unix.ARPA Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Also contact Wedge ... Wedge Computer, Inc. 2 Winter Street Waltham, MA 02154 (617)891-1313 No info (yet) on how well it works, -- Jim From don@brillig.umd.edu Tue Jun 28 17:50:58 1988 Date: Tue, 28 Jun 88 17:50:58 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh From: frame!yukon!pjb@Sun.COM (Paul Bailey) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I am also interested in NeWS for the Mac. Could you have them contact me as well, or just post their address and number? Thanks, --paul From don@brillig.umd.edu Thu Jun 30 01:31:25 1988 Date: Thu, 30 Jun 88 01:31:25 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh From: gorodish!guy@sun.com (Guy Harris) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > >Does anyone know (or have heard of) an implementation of NeWS for > >Macintosh? > The Grasshopper Group in San Francisco has a NeWS implementation for > the mac. For the Mac II, anyway; it runs under A/UX, not under the Mac OS. From don@brillig.umd.edu Thu Jun 30 01:31:36 1988 Date: Thu, 30 Jun 88 01:31:36 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: A NeWS Class Browser From: jfjr@MITRE-BEDFORD.ARPA (Jerome Freedman) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I am writing a NeWS application on a Sun 3. I need a way to automatically start a UNIX program and have the output go to the new specific window I'm creating using psterm for a vt100 emulation. I have tried all derivations of the psterm arguments and have yet to find a way to do so. Each attempt results in the output being directed to /dev/null. Jerry Freedman, Jr "Does Unix have jfjr@mitre-bedford.arpa a Buddha nature?" (617)271-4563 From don@brillig.umd.edu Thu Jun 30 01:32:19 1988 Date: Thu, 30 Jun 88 01:32:19 EDT To: NeWS-makers@brillig.umd.edu Subject: is news loosing the battle? From: nancy!eecae!upba!dsndata!wayne@umix.cc.umich.edu (Wayne Schlitt) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have been following both the news and x news groups for a fair while now and lately i have noticed that there is about ten times the traffic in the x news group. are there that many more people developing under x than news, or is the volume just skewed by all the universities on the net? our company has a specialized cad package that we will eventually port to run under either news, x, or what ever becomes the standard. it will be about a year before we are ready to start, so for now i am just watching both groups, trying to pick up all the info i can get. -- Wayne Schlitt | Design Data Corporation hplabs!hpfcla ----------\ | 1033 "O" St. Suite 324 ncar!handel!hpfcla ------>---> !dsndata!wayne | Lincoln Ne, 68508 ihnp4!upba -------------/ | (402) 476-8278 From don@brillig.umd.edu Thu Jun 30 20:46:18 1988 Date: Thu, 30 Jun 88 20:46:18 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: psterm & commands From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > I am writing a NeWS application on a Sun 3. I need a way to >automatically start a UNIX program and have the output go to >the new specific window I'm creating using psterm for a vt100 >emulation. I have tried all derivations of the psterm arguments >and have yet to find a way to do so. Each attempt results in >the output being directed to /dev/null. What have you tried? I just did. c3po% psterm -t vt100 cat /etc/termcap & and c3po% echo "(psterm -t vt100 cat /etc/termcap) forkunix" | psh The output of cat appeared in a vt100 psterm in both cases. -greg. From don@brillig.umd.edu Thu Jun 30 20:47:09 1988 Date: Thu, 30 Jun 88 20:47:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh From: hpda!hpcuhb!hpsmtc1!dlw@ucbvax.Berkeley.EDU (David Williams) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) in:comp.windows.news / pjb@yukon.UUCP (Paul Bailey) / asks: >I am also interested in NeWS for the Mac. Could you have them contact >me as well, or just post their address and number? >Thanks, >--paul ---------- MacNews fro the Grasshopper Group o Runs under A/UX 1.0 with A/UX supported monitors. A minimum of 4 megs of RAM and 5 Megs of disk is recommeded. o MacNews release 1.1.01 is $225(U.S.) direct from the Grasshopper Group. o Complete client source is included. o NeWS servers from Sun, Silicon Graphics, WhiteChapel Workstations and Acorn Computers work with MacNews. o To order call +1 408 266 4738 between 8am & 5pm PST or contact them via the net at grasshopper@toad.com --HOPE this helps..... -David "I have no affiliation with GG or MacNews other than having a brochure on it" From don@brillig.umd.edu Thu Jun 30 20:48:22 1988 Date: Thu, 30 Jun 88 20:48:22 EDT To: NeWS-makers@brillig.umd.edu Subject: Traffic on the X list From: maximo!mo@uunet.UU.NET (Mike O'Dell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Maybe it's because of the bugs. (grin) From don@brillig.umd.edu Thu Jun 30 20:50:56 1988 Date: Thu, 30 Jun 88 20:50:56 EDT To: NeWS-makers@brillig.umd.edu Subject: Looking for simple drawing application From: mcvax!tnosel!westc!msteen@uunet.uu.net (Martien van Steenbergen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does someone have a simple drawing package available under NeWS which allows me to draw (mouse) simple objects and to compose more complex objects of simple objects. The application must be able to store the drawings in rather primitive PostScript. That is, I do not need (and want) an extensive prolog which normally accompanies a PostScript print file. For example, if I draw a simple square the generated PostScript code should be something like: 0 0 moveto 10 0 rlineto 0 10 rlineto -10 0 rlineto closepath I want to use the generated PostScript in other NeWS applications. And of course, it should be printable on any PostScript printer so it should not contain NeWS specific operators. Martien F. van Steenbergen Support Engineer West Consulting BV email: martien@westc tel: (+31) 15 123 190 From don@brillig.umd.edu Fri Jul 1 02:48:55 1988 Date: Fri, 1 Jul 88 02:48:55 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: "Dave Mankins" Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Maybe it's because of the bugs. (grin) More likely it's because of the price. From don@brillig.umd.edu Fri Jul 1 21:10:39 1988 Date: Fri, 1 Jul 88 21:10:39 EDT To: NeWS-makers@brillig.umd.edu Subject: multiple-server clients From: ut-emx!lad-shrike!milano!macondo!simon@sally.utexas.edu (Simon John Gibbs) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have been writing NeWS applications where clients need to connect to more than one NeWS server. The problem is that the cps interface seems to be written under the assumption that a client is only dealing with one server (the one running on the host in the NEWSSERVER environment variable). Why build a server based window system and then build in restrictions that make it difficult for clients to connect? What I ended up doing is modifying cps and libcps so that the client now does: cid = ps_open_PostScript(host) ps_close_PostScript(cid) ps_flush_PostScript(cid) where host is a string and cid a small integer (ps_open_PostScript could easily be extended to include a port if one had multiple servers per machine). The cps files are the same, but if there's something like cdef ps_fun(x, y, z) The call from the C client looks like: ps_fun(cid, x, y, z) Now my problem is I have a non-standard cps and libcps. What I was wondering is whether there's a better way to do this, or, if not, if anyone knows whats happening with cps etc. in the next release of NeWS (the NeWS/X11 merge?) ?? Regards - Simon Gibbs (simon@mcc.com) From don@brillig.umd.edu Fri Jul 1 21:10:52 1988 Date: Fri, 1 Jul 88 21:10:52 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >>Maybe it's because of the bugs. (grin) >More likely it's because of the price. And the number of systems on which it runs. (ugh even VMS) From don@brillig.umd.edu Fri Jul 1 21:11:53 1988 Date: Fri, 1 Jul 88 21:11:53 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: diamond.bbn.com!mlandau@bbn.com (Matt Landau) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In comp.windows.news, dm@DIAMOND.BBN.COM ("Dave Mankins") writes: >>Maybe it's because of the bugs. (grin) >More likely it's because of the price. Even more likely, it's because of the politics that prevent other vendors from supplying NeWS ports for their machines. The $100 fee for NeWS binaries doesn't seem like a big impediment to anyone who wants to run it on a Sun. Of course, you don't get sources, but then again you don't tend to NEED sources to get NeWS working, unlike certain other window systems we could name :-) -- Matt Landau Riding shotgun down the avalanche mlandau@bbn.com From don@brillig.umd.edu Fri Jul 1 22:31:14 1988 Date: Fri, 1 Jul 88 22:31:14 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: bzs@bu-cs.bu.edu (Barry Shein) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >In comp.windows.news, dm@DIAMOND.BBN.COM ("Dave Mankins") writes: >>>Maybe it's because of the bugs. (grin) >>More likely it's because of the price. > >Even more likely, it's because of the politics that prevent other >vendors from supplying NeWS ports for their machines. > >The $100 fee for NeWS binaries doesn't seem like a big impediment >to anyone who wants to run it on a Sun. Of course, you don't get >sources, but then again you don't tend to NEED sources to get >NeWS working, unlike certain other window systems we could name :-) >-- > Matt Landau Riding shotgun down the avalanche To some extent it's a bootstrap problem (at least as viewed from here, where we don't have any NeWS yet.) Ok, it's $100/copy (RTU is cheaper but manuals are nice which seems to be a lot of what that $100 is for.) We have 100 or so workstations, that's $10K, well, we don't need it for nearly that many at this point, how many do we need it for? Hmm, well, I guess developers around here, people who want to have an opinion as it comes onto the scene, like myself, to advise the others here. Well, lessee, a dozen copies might do it, $1200, that's probably how many people might be using X around here right now from time to time, maybe a few less would do it. Not a whole lot of money really, but hardly free. But it *is* beta software, and I think it's supposed to show up magically bundled anyhow "real soon now" (remember that the "real soon now" was originally something like last April and has been slipping, seemed like we might as well wait, the beta stuff sounded pretty buggy, and people running 1.0 said wait for 1.1, and I don't remember any real announcement of that, I did see some mention on the net so I sort of knew it must be ready, but "real soon now...") And besides, we FTP'd over X and got it running and that was all rather painless, how many window systems do I want to play with at once? Ach, play with X now, wait for NeWS, it's coming it's coming. And it's not like there are applications out there crying for NeWS (eg. things like Frame), there's no noise I've heard from our users (as a matter of fact I have no idea off-hand what is available with NeWS other than the environment and a terminal emulator, am I missing something? How would I know? I haven't seen any literature really and I haven't noticed lots of sources being posted here to things I just *must* have, or reference to the same, that's part of the bootstrap problem I guess, if everyone's waiting for some critical threshold of applications to appear then they're [we're] not writing them.) My 2c: if they had thrown the beta Sun stuff (binary is probably fine) somewhere to anonymous FTP with some on-line supporting docs (or even just sent the salesthings around with some hardcopies of core docs to hand out to people they thought should be playing with it at this stage, or even charged a few bucks) more people would probably be playing with it. Right now it sort of sits in the well of this energy threshold, wondering if tomorrow's mailbox will just sort of have a tape of it sitting there, and I'm trying to figure out the Widgets library and putting up CLX and trying to get it to do something, maybe with PCL, and porting the X software to things like Encores and... -Barry Shein, Boston University From don@brillig.umd.edu Sat Jul 2 04:42:42 1988 Date: Sat, 2 Jul 88 04:42:42 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: tomlin@hc.dspo.gov (Bob Tomlinson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) in article <23581@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) says: > ... > ... Lots of stuff about NeWS cost on 10-100 workstations. > ... > Right now it sort of sits in the well of this energy threshold, > wondering if tomorrow's mailbox will just sort of have a tape of it > sitting there, and I'm trying to figure out the Widgets library and > putting up CLX and trying to get it to do something, maybe with PCL, > and porting the X software to things like Encores and... Meanwhile the NeWS client side is trivially portable to Encores (as well as MIPS, Alliant, etc.) and is actually being used in large distributed applications that would *kill* a network if the applications were using X. Free ain't always everything. I wonder how much of a difference there is in actual cost when you consider you get ~$60 of manuals (not to mention the tape) for your $100 NeWS license fee. Nutshell sells their X manuals documenting X's hundreds of calls and thousands of arguments for $60. Pretty similar prices. NeWS right to use licenses are $25 (that's $2,500 for your 100 workstations). Isn't that about the price of 1 compiler for a VMS 11/780 for 1 year? My haven't times changed. -- bob -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems From don@brillig.umd.edu Sat Jul 2 05:41:15 1988 Date: Sat, 2 Jul 88 05:41:15 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Display PostScript From: liam@cs.qmc.ac.uk (William Roberts) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Subject: Re: Display PostScript Summary: not very impressive Contact Brenda Hansen at Adobe and you will get sent the Adobe press releases and publicity material. This is a summary I wrote for myself: --------------------------------------------------------------- Display PostScript WTR Digest of Handout Display PostScript is just PostScript-as-graphics-language for use with window systems. The window system provides a lump of memory (and or display driver code) and PostScript is rendered into each such "window" under application control. It is implied that for DECWindows, the Display PostScript interpreter will be part of the X Server and accessed as an extension to the X protocol. The Display PostScript interpreter does not provide logically separate PostScript environments. PostScript code can be shared between "windows" by a shared memory scheme, hence save/restore is no longer adequate and garbage collection is introduced. Each window is a separate context, and the interpreter can switch between these contexts. It is not clear whether or not "multi-tasking" means more than this: if so, it probably means that the interpreter executes PostScript asynchronously on behalf of the application, and interleaves the execution of code in different contexts. These extensions to PostScript are probably only available through the application procedural interface (makecontext, setcontext etc), so they don't involve new primitives available directly in raw PostScript. This allows the claim that "new applications for the Display PostScript system will be compatible with existing PostScript printers". The blurb says "multiple graphics state stacks within a single context": this sounds useful, but is hard to reconcile with "no changes needed to print on the printer". It would be easy to code using such a feature and it is not a primitive facility of PostScript printers. Almost all of the other information merely recites the benefits of ordinary PostScript. There is no concept of "input" in Display PostScript whatsoever, and the cheap stab at NeWS is not particularily becoming.... -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250 From don@brillig.umd.edu Wed Jul 6 00:01:08 1988 Date: Wed, 6 Jul 88 00:01:08 EDT To: NeWS-makers@brillig.umd.edu Subject: stdio to a NeWS window? From: oml@lanl.gov (Olaf Lubeck) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is it possible to stdio from a C Client program to a NeWS window? Is this what psio does? How does one open a stream to a NeWS window? reply to: oml@lanl.gov From don@brillig.umd.edu Wed Jul 6 00:02:48 1988 Date: Wed, 6 Jul 88 00:02:48 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: ssc-vax!benoni@beaver.cs.washington.edu (Charles L Ditzel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) in article , wayne@dsndata.uucp (Wayne Schlitt) says: > I have been following both the news and x news groups for a fair while > now and lately i have noticed that there is about ten times the traffic > in the x news group. are there that many more people developing under > x than news, or is the volume just skewed by all the universities on > the net? A couple of thoughts : 1) X has a fairly significant lead on NeWS at the moment. You have to take into consideration that NeWS is only just starting to come out for systems such as the Macintosh and has yet to come out for PCs. However, Silicon Graphics has just released a window management system that includes NeWS. It is a NeWS/X window manager called 4sight (or something like that). Other computer vendors are also working on ports...Sun itself will shortly be coming out with its supported NeWS/X port...SCO is reportedly going to have NeWS/X for their Xenix systems... 2) The next questions are : what is the staying power of X given NeWS' availability on similar platforms? Will the future simply be NeWS/X window managers or just one or the other? I don't think too many people are arguing that X11 is technically better ... rather more people tend to argue the reverse (surprisingly even some of the X folks concede the point) ... > our company has a specialized cad package that we will eventually port > to run under either news, x, or what ever becomes the standard. it Actually the next year should be alot of fun to watch... there will be alot products out for X...NeWS action should be picking up in intensity also ... as it is supposedly included with Release 4 of Unix...new vendors should emerge. NeWS products should also be forthcoming...(recently Sun announced it's first NeWS product - SNA 327? emulation) The recent schisms in the Unix world will make all this even more interesting... One more note : I tend to think that those companies that offer both systems are in a much better position than those companies only offering X... ------------------ Naturally these are MY own opinions and not those of my employers. From don@brillig.umd.edu Wed Jul 6 00:03:27 1988 Date: Wed, 6 Jul 88 00:03:27 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: multiple-server clients From: cs.utexas.edu!milano!titan!janssen@rutgers.edu (Bill Janssen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Xlib handles multiple servers with the notion of a `default server'. All C calls on Xlib are directed toward that server. The call to connect to a server returns a handle to that server, and makes it the default: display = XOpenDisplay (server_name); The default display can be changed: XSetDisplay (display); This works pretty well if the granularity of your interaction with the server is modestly large, as it tends to be with X. If you need an interface that tends to send every command to every server, you may want instead to implement a `grouped default server', which is really a list of servers. Every command would be repeated on each server in the list. This could be implemented in the library so that all calls look alike, and the functions are somewhat polymorphic, specializing on the server-type, normal or grouped. Warmest regards, Bill From don@brillig.umd.edu Wed Jul 6 00:04:14 1988 Date: Wed, 6 Jul 88 00:04:14 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: ssc-vax!benoni@beaver.cs.washington.edu (Charles L Ditzel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) in article <11199@jade.BBN.COM>, mlandau@bbn.com (Matt Landau) says: ... > Even more likely, it's because of the politics that prevent other > vendors from supplying NeWS ports for their machines. > > The $100 fee for NeWS binaries doesn't seem like a big impediment > to anyone who wants to run it on a Sun. Of course, you don't get > sources, but then again you don't tend to NEED sources to get > NeWS working, unlike certain other window systems we could name :-) I tend to agree...certain other workstation vendors are probably not interested in following behind Sun...interestingly by not having a NeWS port they are stuck with X...and they wind up still following Sun who has will have X/NeWS... having shown NeWS to some folks that have been using X on an RT they are off looking at Suns...(because of NeWS) ---------------- Naturally my opinions are my own. From don@brillig.umd.edu Wed Jul 6 00:04:27 1988 Date: Wed, 6 Jul 88 00:04:27 EDT To: NeWS-makers@brillig.umd.edu Subject: Thick Lines in NeWS. From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Has any brave soul dared to look at the thickline code in detail.(stroke.ps) If you run the following example, you will find some funny blobs on the 4th & 8th rectangle. psh executive 1.0 fillcanvas 0 setgray /width 0 def 0 110 800 { 20 100 100 rectpath stroke /width width 1 add def width setlinewidth } for NeWS 1.1 on BW 3/60 -greg. From don@brillig.umd.edu Thu Jul 7 19:50:13 1988 Date: Thu, 7 Jul 88 19:50:13 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: stdio to a NeWS window? From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Is it possible to stdio from a C Client program to a NeWS window? >Is this what psio does? How does one open a stream to a NeWS window? >reply to: The psio* routines create a stream connection to a NeWS lightweight process. Different calls and data structures are used to make the C client interface portable. Something sent with psio_putc() will be read as stdin by the NeWS lightweight process. The catch is that NeWS lightweight process will be expecting PostScript to execute on the stdin file. This means you can't just do a gets() on the C stdin and expect to relay it to a NeWS window without some trickery. I hope this answers your question. -greg. From don@brillig.umd.edu Thu Jul 7 19:50:28 1988 Date: Thu, 7 Jul 88 19:50:28 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: kimba!hvr@sun.com (Heather Rose) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article wayne@dsndata.uucp (Wayne Schlitt) writes: >I have been following both the news and x news groups for a fair while >now and lately i have noticed that there is about ten times the traffic >in the x news group. are there that many more people developing under >x than news, or is the volume just skewed by all the universities on >the net? >From what I hear from customers, NeWS is confusing at first. Just like C was confusing at first, just like UNIX was confusing at first. It takes a while to get used to programming in a stack based language (Postscript). It takes time to understand classes. But the benefits it provides are worth it to me. Besides, I like HP calculators ;-) >our company has a specialized cad package that we will eventually port >to run under either news, x, or what ever becomes the standard. it >will be about a year before we are ready to start, so for now i am >just watching both groups, trying to pick up all the info i can get. Try them out. Only you know what is best for your application. See what NeWS can do versus what X11 can do. You will most likely run into limitations with both systems, so choose the one that is most cost effective. If you're serious about investigating these systems, take some educational classes. Apollo offers one on X, Sun on NeWS. It's all well and good to read about what others are doing, but you really won't know until you try to get some WORK[tm] done with either system. And, writing a CAD package seems to be alot of WORK[tm] to me. Another big issue to me would seem to be 3-D support if you need it. How do the windowing systems deal with that? or do you have your own, how does the windowing system interface with your routines? What about other medium like video? Input from different types of devices like drawing pads, scanners? How is that handled? If you want the scoop on when products will be out etc for Sun, your local Sun salesrep is your best bet. --Heather Rose From don@brillig.umd.edu Thu Jul 7 19:51:07 1988 Date: Thu, 7 Jul 88 19:51:07 EDT To: NeWS-makers@brillig.umd.edu Subject: InterViews and NeWS From: cadnetix.COM!gad@uunet.uu.net (Gordon Durand) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) About a month ago I posted an article asking if anyone had ported Stanford's InterViews classes to Sun's NeWS. I got several responses from folks interested in such a port, but no indication that such a port had been done (sigh). Anyway, I'm going to go ahead and port InterViews to NeWS. The timing and completion of this port are subject to my inexperience with NeWS and my "official" duties here at Cadnetix. I suspect that the port will be something of a "spare time" project, but I'll try to get it done as soon as possible. I'll post again when the port is completed. Gordon Durand Domain: gad@cadnetix.com Cadnetix Corp. UUCP: ..!{uunet,boulder}!cadnetix!gad 5775 Flatiron Pkwy. Boulder, CO 80301 From don@brillig.umd.edu Thu Jul 7 19:51:21 1988 Date: Thu, 7 Jul 88 19:51:21 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: multiple-server clients From: Robert Scheifler Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: Wed, 6 Jul 88 00:03:27 EDT From: cs.utexas.edu!milano!titan!janssen@rutgers.edu (Bill Janssen) Xlib handles multiple servers with the notion of a `default server'. All C calls on Xlib are directed toward that server. Somebody is speaking ancient tongues here. That was true of X10, but is not true of X11. From don@brillig.umd.edu Thu Jul 7 19:51:38 1988 Date: Thu, 7 Jul 88 19:51:38 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: aplcen!wb3ffv!theceg!lkb@mimsy.umd.edu (Lawrence Keith Blische) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >From article <8807011518.AA07601@metropolis.super.org>, by lerici@super.ORG (Peter W. Brewer): > > >>>Maybe it's because of the bugs. (grin) > >>More likely it's because of the price. > > And the number of systems on which it runs. (ugh even VMS) Just what systems/hardware are supported? ---------------------------------------------------------------------- Larry Blische ...!cp1!sarin\ The Computer Engineering Group, Inc. !wb3ffv!theceg!lkb +1 301 282 5876 (9-5 ET) ...!aplcen/ From don@brillig.umd.edu Thu Jul 7 19:51:57 1988 Date: Thu, 7 Jul 88 19:51:57 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: "Dave Mankins" Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > [talk about how the $100 fee for News binaries is a tiny impediment.] A couple of years ago (post News, although at the time it was still called Sundew) I worked for a company that builds a large-scale parallel processor which does not run SUN binaries, and at the time didn't even run UNIX. For the price of a few hours spent running FTP, and a couple of days spent debugging my Berkeley socket emulation library, we had X up and running on this machine. We were able to show our management that X on this machine was a reasonably good thing, and they agreed, and a little while later it was a part of our product line (it helps that we liked to distribute sources with our products). (It was this easy because our machine is a computer, not a workstation, so I didn't have to port the display portion, which is more hardware-dependent.) What would it take to talk my boss-beings into springing for the $40K source license, signing a semi-restrictive agreement with what was, more or less, a competitor, just to do an EVALUATION? Especially when that $40K could immediately be applied to buying workstations to make our programmers more productive? I'm not flaming SUN, I think that if you do good work, you're entitled to ask money for it, if you so choose. However, I think that in order for something to become a standard, you have to be pretty loose with the sources, so people can port it to their machine without spending more time talking to the company's lawyers than they spend doing the port. I hate talking to lawyers. Even believing that Sundew was a superior paradigm, X was preferable, because we could spend the News source license fee putting Sun 3/50s on 10 of the department's desks immediately instead of a year later. It would be a LONG time before the value-added of News over X came any where close to the value-added of those 10 workstation-years. News ain't ever likely to run on that machine, because: o they've got a ``pretty good'' window system now, one that interoperates with all our other workstation and CPU vendors --- we can even put PCs on the net running X o since they've got X, they no longer pay much attention to yet another window system from SUN, so they don't know what they're missing o the above two reasons have to be overcome to justify the expense of a source license (which they need to port the software to their multiprocessors and their vaxen) I'm sure that they're not the only hardware vendor in a similar fix. The News BINARY license is comparable to the expense of getting the X SOURCE tape, if you're on the internet, X is FREE. The value-added of News over X isn't immediately obvious, so why spend all that money on a gamble (at the time Sundew first came out, it was Suns THIRD incompatible window system. Who could predict that there wouldn't be a fourth)? The first they're likely to see of News will be after the X/News combined server comes out, so they can run their existing software on it. X is like a weed, it can germinate and spread to your machine without much attention on your part. With News you have to spend $40,000 in garden tools and fertilizer before you even get the seeds. From don@brillig.umd.edu Thu Jul 7 19:52:37 1988 Date: Thu, 7 Jul 88 19:52:37 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: hpda!hp-sde!hpfcdc!hpfclp!diamant@ucbvax.Berkeley.EDU (John Diamant) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > 2) The next questions are : what is the staying power of > X given NeWS' availability on similar platforms? Will the > future simply be NeWS/X window managers or just one or the > other? I don't think too many people are arguing that X11 > is technically better ... rather more people tend to argue > the reverse (surprisingly even some of the X folks concede > the point) ... Whoa, there. Interesting that you chose to post this in a NeWS only group. In an X group, I'm sure you'd get quite a bit of disagreement on this. Before I begin, let me say that I'm in the X camp myself (I'm an experienced X programmer, have seen NeWS and believe I understand the basic model, but am not a NeWS programmer, so feel free to correct any technical errors regarding NeWS -- which I'm sure you would even without an invitation :-) Both NeWS and X have technical advantages, but I don't believe one is fundamentally superior to the other. However, X has from the beginning, been a completely open system, whereas NeWS has been an expensive, licensed piece of software until the introduction of the AT&T NeWS distribution. Now that NeWS will be more freely available, NeWS and X can compete on equal footing. Until now, it was a simple choice: do you want a proprietary system which one vendor is trying to foist on the world (NeWS) or a multi-vendor, open system, which has been freely available from the very start (X). NeWS advantages over X: high power imaging model (2D) using absolute dimensions, rather than pixels non-rectangular windows Postscript available Toolkits can be interpreted in the server, and thus substituted out from under the application mimimal traffic between client and server disadvantages of NeWS relative to X: requires relatively powerful NeWS server -- a NeWS terminal will be more expensive than an X terminal programming process context switching and partitioning between client and server is a PAIN for the progammer. programming in Postscript is a pain (of course, Sun provides a C translator so this isn't that big a problem). Now, let's examine the NeWS advantages for a moment and see how important they are. Regarding the imaging model, it is only 2D, and X is getting the 3D graphics extensions defined as a standard extensions, so any vendor with good hardware for graphics will probably support it. The issue of absolute dimensions and font scaling is a real one, though, of course, there are workarounds in a pixel based system (adjusting depending on the screen size). Non-rectangular windows is "gee whiz," but frankly, I don't care about that at all. Other than having round clocks, I just don't see this as a big deal. Postscript will be available on X as well, thanks to Display Postscript and some public Postscript previewers. (please note my distinction of the imaging model and just having Postscript -- this item addresses the display of Postscript and the output language only) The ability to have interpretive toolkits which can be swapped is useful, but there are other ways to accomplish this in X as well (using dynamic loading, for instance). Probably the most significant difference between X and NeWS is the traffic between client and server. First of all, Scheifler wrote a paper about why the traffic breakdown wouldn't be as good as the claims (because the communication for even simple operations like menus would be higher than expected). Second of all, it doesn't really matter! I'm a network administrator and I have some experience on this subject. Lan bandwidth is rarely the bottleneck in communications between two machines. We run diskless (including remote swap), remote X, etc. and the volume of traffic is just never that high (typically under 5% of lan utilization). Also, most X servers run with Unix Domain sockets when running locally, so lan overhead isn't a big issue. The only issue that remains is the performance in terms of throughput on the lan. We are already at the point where lan performance is within the same ballpark as disk transfer rates, so it isn't that big a deal, and we're getting faster lan technology too. The only time this will really matter is for non-local lans, like SLIP remote links or over low-speed remote channels. In that case, I concede that NeWS has an advantage, but that is probably only a small percent of the use of either NeWS or X, and running at 9600 baud over SLIP for X will still be acceptable, I believe. Basically, the assumptions that X used were that a high-speed byte stream was available between client and server and that the client was a more powerful machine than the display server. NeWS uses a different set of assumptions (or at least it shines in a different environment). NeWS is best when the link speed is low and the client and server are roughly the same power. That means if you have a Sun workstations at home, then you are probably best off running NeWS remotely, but if you have a PC or a custom window terminal at your desk, you're better off running X. > One more note : I tend to think that those companies that > offer both systems are in a much better position than those > companies only offering X... This is probably true, at least until things settle out. Disclaimer: These opinions are my own and do not necessarily reflect those of Hewlett-Packard. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant From don@brillig.umd.edu Thu Jul 7 19:55:16 1988 Date: Thu, 7 Jul 88 19:55:16 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: ichthyosaur.cis.ohio-state.edu!elwell@tut.cis.ohio-state.edu (Clayton M. Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) diamant@hpfclp.SDE.HP.COM (John Diamant) writes: Before I begin, let me say that I'm in the X camp myself (I'm an experienced X programmer, have seen NeWS and believe I understand the basic model, but am not a NeWS programmer, so feel free to correct any technical errors regarding NeWS -- which I'm sure you would even without an invitation :-) Well, I'm in the NeWS camp. I've used X a lot, but for programming I've been using NeWS (I gave up on X after the third try...). I understand X pretty well, although I'm sure you (or, in fact my coworkers) will correct me if I get confused :-). Both NeWS and X have technical advantages, but I don't believe one is fundamentally superior to the other. Well, part of the difference between them, and part of why it's hard to compare them, is that they are based on very different ideas of "what a window system should be," and so some of the issues are more religious than technical. One, for example, is the whole issue of PostScript. I actually don't find PostScript any more obtuse to program in than C, and with the class system that Sun provides as part of NeWS, doing user-interface type stuff is in fact a lot easier. Of course, I also find my HP calculator perfectly easy to use :-). Now, let's examine the NeWS advantages for a moment and see how important they are. Regarding the imaging model, it is only 2D, and X is getting the 3D graphics extensions defined as a standard extensions, [...] I think this a straw man argument. Most workstation displays I've seen are 2D... Yeah, you can add 3D rendering primitives to X, but I can add 3D rendering operators to NeWS, without (a) having to touch my binaries or (b) making assumptions about the display itself. If I'm a vendor, I can even hack my version of the server to do it in hardware. Non-rectangular windows is "gee whiz," but frankly, I don't care about that at all. Well, it's not just windows. Anything can be non-rectangular. Like buttons and controls. I agree that rectangular ones are good enough for most simple interfaces, but it's nice to have the generality there when you need it. Postscript will be available on X as well, thanks to Display Postscript and some public Postscript previewers. And Display PostScript is evidently very nice and fast. However, previewing PostScript documents is a small portion of what I do with my workstation. PostScript itself isn't so much the issue as having a well-defined way to extend the capabilities of the display server, on the fly if necessary. The simplest way to do this is to pick a simple language with good graphics primitives. Add popular to the requirement, and PostScript seems the logical choice to me. I'd rather that than Interpress or HPGL :-). The ability to have interpretive toolkits which can be swapped is useful, but there are other ways to accomplish this in X as well (using dynamic loading, for instance). Of course, dynamic loading is done differently on every flavor of UNIX, so the client support routines have to be kept up to date. With NeWS, all you have to do is be able to talk to your display, which is kind of a given. Probably the most significant difference between X and NeWS is the traffic between client and server. First of all, Scheifler wrote a paper about why the traffic breakdown wouldn't be as good as the claims (because the communication for even simple operations like menus would be higher than expected). Well, in most of the programs I've seen, most menu choices either *don't send anything back to the client at all*, or send a byte as part of the input stream. Seems pretty low overhead to me. But that's probably not a good example. Second of all, it doesn't really matter! I like that--the most significant difference doesn't really matter! The only time this will really matter is for non-local lans, like SLIP remote links or over low-speed remote channels. Which, of course, nobody ever really uses... Take the ARPAnet, for example... :-). Basically, the assumptions that X used were that a high-speed byte stream was available between client and server and that the client was a more powerful machine than the display server. NeWS uses a different set of assumptions (or at least it shines in a different environment). I'd say that NeWS is based on the display server knowing about the details of the display hardware, so that the client didn't have to worry about it, and that abstraction is a good thing. X is one of the least abstract systems I've ever used. I like Bill Joy's description--"rasterop on wheels". I like PostScript on a window system for the same reason I like it on a printer or a typesetter. Most of the time, I don't want to have to worry about how to chisel bits onto the screen. I realize that things like Xtk and so on help, but still, it's a virtual display at a lower level than I care to deal with. Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Thu Jul 7 19:58:03 1988 Date: Thu, 7 Jul 88 19:58:03 EDT To: NeWS-makers@brillig.umd.edu Subject: Pull right menu modification From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The Sun SunWindow menus have a special feature not found in the NeWS 1.1 litemenu facility. In SunWindows, if you pick a menu item that has an associated sub-menu, but you do not move the cursor to pop-up that sub-menu, then the first item on the sub-menu is chosen. I find this feature to be handy, so I have constructed a modified menu class for NeWS that has this property. -------------------------------------------------- % Define a new menu subclass that % automatically de-references menus as actions. /autopullmenu DefaultMenu [] classbegin %override /domenu { % - => - (execute action of menu) % get the menu action for self MenuValue getmenuaction dup type /dicttype eq { % if action is a menu, recurse and do its 0th action % fake to look like child is active /ChildMenu exch store ChildMenu /ParentMenu self put ChildMenu /MenuValue 0 put /domenu ChildMenu send % clean up self and lower level menus (should not be any) /popdown self send } { % else do the action cvx exec } ifelse } def classend def % autopullmenu /DefaultMenu autopullmenu store From don@brillig.umd.edu Thu Jul 7 19:58:13 1988 Date: Thu, 7 Jul 88 19:58:13 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: bzs@bu-cs.bu.edu (Barry Shein) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi, my name is Barry Shein and I am an alc...no, that's not right... I am not and never have been a card carrying member of...ummm, one more time... I'm trying to be very open-minded on the X/NeWS issue. This means I've probably pissed off both camps sufficiently and they are each quite sure I lean the other way, as religions are wont to do (see for example the writings of Cardinal Newman, "one cannot be both a believer and questioner"), relgions are usually more open to identifying heretics than observants... First, I have vastly more experience with X than NeWS tho I don't think I misunderstand NeWS, I think I get the point. I am very sensitive to the "imaging model" issue. One of the first things anyone attempting to write a toolbox in X runs into (at least any honest person) is the whole issue of pixel sizes and relative metrics, particularly with fonts, big problem with X, claims of "portability" seem to slip away when they can't even abstract the bit density of the screen away from the programmer (reminiscent of the old IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 bytes/track on a 3330 you fool!!!") For example, I was just writing an X11 widget which is a general purpose "meter", something with marked points and hands etc. If you resize the meter there's no problem redrawing the hash marks or hands to conform nicely, but what to do about the fonts?? (eg. markings around the edge), not much except guess that some other font size *might* now be appropriate, sort of, using some threshold calculation (and hope that size is available in this server etc.) Generalized text can be even worse and the whole model (X) lends itself to such absurdities as distributing one bitmap font set on the tape (ludicrous! these are 84 dpi fonts and I'm on a 91 dpi screen, that's enough to make kerning etc just look wrong (and forget things like Hi-res monitors) and was my motivation for writing "gfto" which at least lets you regen fonts for your screen dpi, tho that only addresses part of the problem.) On the other hand, there it is (X), and it basically works quite well AS ADVERTISED and fits a model of subroutine access nicely enough (although object data management in C is less than wholesome, I'm not sure that mere Postscript can quite address that although an object oriented approach helps, at any rate, that's not *obviously* a fault of X but might be a sin of omission.) But NeWS seems to solve the imaging problem trivially (while creating others, like who the heck *wants* to program in postscript other than Don Hopkins :-) Why couldn't the whole remote interpreter thing (in re X) be more or less resolved by judicious use of the "rsh" command? Aren't window handles global? So why not something like: sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); system(buf); Sure, that's a little slow because you have to authenticate on each command but opening a socket to a remote shell or using something like rexec/rexd/rpc directly could solve that (you get the idea.) Forking has some overhead, is it important? I dunno, Unix sez no, not in general and this case would tend to weigh in its favor (if the thing was so short-lived that fork/exec is a major factor then you may as well have computed that on the client, that's another problem, *someone* has to make all these decisions.) It does mean you'd have to compile (with its disadvantage of either needing to make the decision beforehand or incurring the delay of compiling some rcp'd code, with the advantage of course that it would now be compiled/optimized, again assuming we bothered because it was too expensive to do on the client so cost is a relative thing and run-time speed is important ultimately.) Shared libraries of course help the disk space and loading time issue etc. Don't talk to me about dynamically loaded C object decks, I've had too much blood run out of my eyes porting those beasts and until someone puts that into OS's universally I say forget it except in special cases, and whoever puts it into the system should be obliged to write the routine needed for every OS that's requested, forever. It doesn't even port between minor OS releases in most cases. Similarly one could easily imagine opening a socket to a lisp which has CLX (Common Lisp X) pre-loaded and passing lisp structs much as above (I know, all together, "lisp is a memory pig", is postscript lightweight on memory? is this still a critical issue to most people? actually lisp doesn't have to be that much of a memory pig, that's an old wives tale borne mostly of non-paged 64KB/256KW machines.) My prediction? (hmm, maybe shoulda included comp.society.futures) That something else will come along in the next coupla years making both X and NeWS obsolete, if I knew what it was I'd go ahead and implement it, make a coupla billion and leave the rest of y'all in the dust :-) Don't confuse good ideas with mediocre implementations (there, good, I pissed off everyone *again*.) -Barry Shein, Boston University From don@brillig.umd.edu Thu Jul 7 19:58:30 1988 Date: Thu, 7 Jul 88 19:58:30 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: unisyn!matheny@boulder.colorado.edu (John Matheny) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) As an application developer, these are some of the attributes that I considered when evaluating the X Window System and NeWS: Portability. I want to minimize the amount of effort it takes to port applications from one platform to another. Therefore, I want to use a window system that exists on all of platforms in which I am interested. The X Window System seems to have an upper hand in this at the moment. However, I believe that this may change when X.11/NeWS is in UNIX V.4 and when vendors stop telling and start listening to their customers who understand the issues. Device independence. I want the window system to insulate my applications from having to know about the basic characteristics of the display device: output resolution, bit-mapped displays versus printers, keyboard mapping, pointing devices, color availability, etc. This lets me spend more time concentrating on the functionality of my application rather than its environment. The PostScript imaging model in NeWS supports this very well; the X Window System does not. Performance in a network environment. I want my application's user interface to perform well in a wide variety of configurations: same machine, machines separated by a high-speed LAN, machines separated by a phone line. Therefore, I want the flexibility of putting all or part of my application's user interface, both input- and output- related components, close to the user where it can be the most responsive. If I use NeWS I have that flexibility. With the X Window System I am stuck with everything residing on the client. I believe that dynamic server programmability, whether it is a window system server, a compute server, or a database management server, is a key to performance. Development environment. I want the window system to include tools and/or techniques that facilitate software development. I have found that all of the functions and their arguments in the X Window System and toolkits to be at least as compilicated of a "language" to learn than the equivalent in PostScript/NeWS. I was able to become proficient in PostScript/NeWS in a very short amount of time and found a number of features that make it very attractive: it has an interpreter that I can type to and get immediate feedback; it lets me do "late binding" of variables and even functions, making my software both more simple and more general; both the input model and the output model are wonderfully flexible; and the object-oriented programming features of NeWS keep my software organized, well-structured, and extensible. I haven't had any difficulty in switching between C-based application programming and NeWS-based user interface programming. In summary, NeWS meets my window system requirements much better than the X Window System. NeWS offers a programmable server for dynamic extensibility and superior performance in a network environment, features a very powerful stencil/paint graphics model that is device- and resolution-independent, and facilitates development with an interactive, object-oriented environment. All of these are features that I want when building state-of-the-art application user interfaces. -- John Matheny Internet: matheny@Unisyn.COM UUCP: uunet!unisyn!matheny Unisyn, Inc., 3300 Mitchell Lane, Boulder, CO 80301 +1 303 443 7878 From don@brillig.umd.edu Thu Jul 7 19:59:12 1988 Date: Thu, 7 Jul 88 19:59:12 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: aftac.tis.llnl.gov!carlson@tis.llnl.gov (John Carlson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <23656@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >I am very sensitive to the "imaging model" issue. One of the first >things anyone attempting to write a toolbox in X runs into (at least >any honest person) is the whole issue of pixel sizes and relative >metrics, particularly with fonts, big problem with X, claims of >"portability" seem to slip away when they can't even abstract the bit >density of the screen away from the programmer (reminiscent of the old >IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 >bytes/track on a 3330 you fool!!!") Ideally I could scroll my display around a large root window. Call it a virtual windowing system (swap and page rectangles?). Also, I may want to zoom in on a particular window, if it is a graphics display, or if the text is too small to read. >Why couldn't the whole remote interpreter thing (in re X) be >more or less resolved by judicious use of the "rsh" command? >Aren't window handles global? So why not something like: > > sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); > system(buf); > >Sure, that's a little slow because you have to authenticate on each >command but opening a socket to a remote shell or using something like >rexec/rexd/rpc directly could solve that (you get the idea.) Using rsh in a window system is like using rcp in a file system. We should be able to share windows between servers (hosts). What I type in a window on my display/screen will appear in the same window on your display/screen without the application knowing! I would like to move a window from my display/screen to your display/screen with my window manager assuming permissions are OK. [ I think HP did something like this with X11 ] >Similarly one could easily imagine opening a socket to a lisp which >has CLX (Common Lisp X) pre-loaded and passing lisp structs much as >above (I know, all together, "lisp is a memory pig", is postscript >lightweight on memory? is this still a critical issue to most people? >actually lisp doesn't have to be that much of a memory pig, that's an >old wives tale borne mostly of non-paged 64KB/256KW machines.) I would prefer some kind of interpreter. Take your choice between X10, X11, Lisp, PostScript, NeWS, ANSI C, Smalltalk, or next year's language. Also, I should be able to mount local window hierarchies and EXISTING remote window hierarchies on my root window wherever I like. [ Some of this can be done under NeWS and X11 ] >My prediction? (hmm, maybe shoulda included comp.society.futures) > >That something else will come along in the next coupla years making >both X and NeWS obsolete, if I knew what it was I'd go ahead and >implement it, make a coupla billion and leave the rest of y'all in the >dust :-) Drop a few million my way. I won't mind. "These aren't my ideas, they are old ideas rehashed." John Carlson From don@brillig.umd.edu Thu Jul 7 19:59:12 1988 Date: Thu, 7 Jul 88 19:59:12 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: allosaur.cis.ohio-state.edu!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <10250002@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Non-rectangular windows is "gee whiz," but frankly, I don't care about that >at all. Other than having round clocks, I just don't see this as a big deal. Isn't there some famous quote from a few years ago of Tom Watson saying that all the world would only need about eight computers? The amazing thing is, even with that tradition of foresight, his company is still selling computers. There may be a future for window systems that don't support arbitrarily-shaped objects, after all. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob rom don@brillig.umd.edu Thu Jul 7 20:00:02 1988 Date: Thu, 7 Jul 88 20:00:02 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: multiple-server clients From: hpda!hp-sde!hpfcdc!hpfcmr!chan@ucbvax.Berkeley.EDU (Chan Benson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Xlib handles multiple servers with the notion of a `default server'. > All C calls on Xlib are directed toward that server. The call to > connect to a server returns a handle to that server, and makes it the > default: > > display = XOpenDisplay (server_name); > > The default display can be changed: > > XSetDisplay (display); Note that this describes the way things are done in X10. In X11, Xlib calls almost universally take a display argument that indicates which server to direct the request to. -- Chan From don@brillig.umd.edu Thu Jul 7 20:01:11 1988 Date: Thu, 7 Jul 88 20:01:11 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is NeWS loosing the battle? From: sgi!daisy!klee@ucbvax.Berkeley.EDU (Ken Lee) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There seem to be at least 2 very different sets of workstation users out there. Each has very different needs. Academic users tend to write small, interesting programs. For them, NeWS is superior because it is more elegant and theoretically powerful. Note that Sun only had to add a small number of features to graft X onto the NeWS server for the X/NeWS merge. Adding NeWS to an X server would have been a major overhaul. See the paper in the last USENIX proceedings for details. Industrial users, like myself, prefer X. It is much more complete (e.g., lots of toolkits and window managers), more robust, and, most importantly, is (or soon will be) available for almost every engineering workstation. All the manufacturers are supporting X to some degree. We do lose some functionality, but X is more than powerful enough for most current applications programs. The competition between the 2 systems is, of course, good. Future window systems will include the best features from both (if the lawyers don't interfere). The X/NeWS merge is still too kludgey for most people, but it may mature into a very nice system. Stay tuned. Ken -- uucp: {atari, nsc, pyramid, imagen, uunet}!daisy!klee arpanet: atari!daisy!klee@ames.arc.nasa.gov STOP CONTRA AID - BOYCOTT COCAINE From don@brillig.umd.edu Thu Jul 7 20:03:06 1988 Date: Thu, 7 Jul 88 20:03:06 EDT To: NeWS-makers@brillig.umd.edu Subject: Stepping the NeWS debugger From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In reviewing the documentation for the NeWS 1.1 debugger, it appears that there is no provision for single step execution of procedures. Using 'dbgbreakenter' I can break at entry to a procedure, but there seems no way to step thru the execution of that procedure. Am I missing something obvious? Can someone tell me how to do this? From don@brillig.umd.edu Thu Jul 7 20:03:06 1988 Date: Thu, 7 Jul 88 20:03:06 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: munnari!otc!metro!basser!natmlab!ronb@uunet.uu.net (Ron Baxter) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <23581@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >And it's not like there are applications out there crying for NeWS >(eg. things like Frame), there's no noise I've heard from our users >(as a matter of fact I have no idea off-hand what is available with >NeWS other than the environment and a terminal emulator, am I missing >something? How would I know? I haven't seen any literature really and Well that really is an invitation to mention that we have a version of the AT&T S Data Analysis System running under NeWS. It has the name of Ace and the first version is out there but, of course, we are working on the second which will be a whole lot better. So what, you could say, since S is readily available under SunView -- S-Plus comes to mind. Well, since NeWS is built on PostScript it has been quite easy to make Ace generate very impressive color graphics on the screen, and equally impressive grey-scale graphics on the LaserWriter -- instead of the simple Tek-like line drawings that most S users get. So you are right, maybe it will need a bit more time before the number of applications will become noticeable, but I expect these applications will have excellent graphics capabilities because PostScript makes it possible. -- Ron Baxter, CSIRO Div Maths & Stats, PO Box 218, Lindfield, NSW, Australia. PHONE: +61 2 467 6059 ACSNET: ronb@natmlab.oz ARPA: ronb%natmlab.oz@seismo.css.gov UUCP: ....{seismo,hplabs,mcvax,ukc,nttlab}!munnari!natmlab.oz!ronb From don@brillig.umd.edu Sat Jul 9 00:07:21 1988 Date: Sat, 9 Jul 88 00:07:21 EDT To: NeWS-makers@brillig.umd.edu Subject: X vs NeWS - was --> is news loosing the battle? From: voder!wlbr!mh@ucbvax.Berkeley.EDU (Mike Hoegeman) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <10250002@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Until now, it was a simple choice: do you want a proprietary system which one >vendor is trying to foist on the world (NeWS) or a multi-vendor, open system, >which has been freely available from the very start (X). > Hmm... I don't know if i would call it foist. I think sun is bending over backwards to accomodate the X fans of the world w/ the merged NeWS/X11 server. I think sun's attitude seems to more "may the best one win". sun's policy on NeWS is pretty much like NFS , if you want a reference source kit you hand over your XXXX amount of dollars and you get it. >NeWS advantages over X: >high power imaging model (2D) using absolute dimensions, rather than pixels >non-rectangular windows >Postscript available Not just available . postscript it is completely and pretty much seamlessly an integral part of the server. the current plans for postscript under X just seem like some weird abortion in comparison. >Toolkits can be interpreted in the server, and thus substituted out from under > the application >mimimal traffic between client and server > >disadvantages of NeWS relative to X: >requires relatively powerful NeWS server -- a NeWS terminal will be more > expensive than an X terminal I don't know if this is so true either. X is no doubt more thrify in resources than NeWS but once you start using those monster X libraries (and you have to to get anywhere with it) I'm not so sure the total resource usage will be in X's favor. NeWS runs quit nicely on Macs and amigas and 386's. I don't really think anybody is going to bother running X or NeWS on anything smaller than those type of machines. > >programming process context switching and partitioning between client and > server is a PAIN for the progammer. Yeah, It's a pain sometimes. but I think It's well worth it just to get the postscript paradigm >programming in Postscript is a pain (of course, Sun provides a C translator > so this isn't that big a problem). I would'nt say that necessarily. In fact I know alot of people who really like postscript. I really did'nt like it much at first but now i think it's great! You really have to USE it for awhile to realize how powerful it is. This is , I think, is one of the major advantages of news over X. the imaging model is just so much more powerful and flexible. Plus it's INTERPRETED!! It's great to go in and whip up a prototype window or user interface gadget by just cranking up a postscript shell and having at it! While on the subject of PostScript , there's the implementation of objects and classes to consider too. This is a real boon when creating user interface gadgets. >The ability to have interpretive toolkits which can be swapped is useful, but >there are other ways to accomplish this in X as well (using dynamic loading, >for instance). >Probably the most significant difference between X and NeWS is the traffic >between client and server. First of all, Scheifler wrote a paper about why It's nice but I don't think anybody really goes for NeWS because of this. I don't. > >> One more note : I tend to think that those companies that >> offer both systems are in a much better position than those >> companies only offering X... How true.. -mike From don@brillig.umd.edu Sat Jul 9 00:09:22 1988 Date: Sat, 9 Jul 88 00:09:22 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: steinmetz!vdsvax!barnett@itsgw.rpi.edu (Bruce G. Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <10250002@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Non-rectangular windows is "gee whiz," but frankly, I don't care about that >at all. Other than having round clocks, I just don't see this as a big deal. Perhaps you should think of objects instead of windows. I can see it useful to have icons change shape and size according to function. The fat trashcan on the Mac is an example. There is an lpqtool from sunspots ( see Chuck Musciano's tooltool) that can be opened to examine the queue. Perhaps the icon's image could change to a LaserWriter with the lid open when the queue was jammed. However, this would be ugly with a rectangular area for an icon. I would like the L-shape of this icon to have an L-shape clipping area on the root menu. In fact, with my constant battle of real estate, I would like a more flexible organization of icons. Icons arranged like a tree, a Rolodex, or a jigsaw might be useful at times. The new garden demo has an icon the shape of a flower! I would like to display a complex system with an assortment of connectors, dials, pipes, ducts, boxes, etc. (DataViews does this). Pipes that change color, texture or size can provide better feedback than simple lines with labels. This seems to be a natural use of NeWS. (This could be done with X, I am sure. But the effort would be much higher - I would guess.) If you look at HyperText systems, or packages like FileVision on the Mac, combining non-rectangular images can be much more useful. I don't think the potential of a NeWS environment has been demonstrated yet. We have been given a taste, but the Real System hasn't been demonstrated yet. I have had a couple of ideas that seem possible with NeWS, and difficult with any other window system. Perhaps some enterprising developer would like to implement these ideas: 1). Our LaserWriters frequently print screendumps. This is a real drag. I would like to take any window and print it. Because of the PostScript model, this should be easy to do, and improve printer thruput and quality. 2). I often work on several projects at once. With all of the interruptions I get, I would like to take the current window environment, and shrink the entire window to a smaller size and free up my screen for a new environment. When I want to switch back to the original environment, I would click on the miniature screen, which would change place with the current screen. This is something like the Picture in a Picture (PIP) feature of the new TV's. 3). Instead of text scrolling off the top of the window, I would like to have a "Star Wars"-like display where the text gets smaller the farther away it is from the immediate area of interest. Looking at a log file, with the older errors shrinking in size, as an example. The text would scroll off when it finally became illegible, with a user-defined lower limit. We have already seen the pie menus for NeWS. This is one example of something more radical in user interfaces. I believe this is just the tip of the iceberg. -- Bruce G. Barnett uunet!steinmetz!barnett From don@brillig.umd.edu Sat Jul 9 00:11:37 1988 Date: Sat, 9 Jul 88 00:11:37 EDT To: NeWS-makers@brillig.umd.edu Subject: Postscript programming From: maximo!mo@uunet.UU.NET (Mike O'Dell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Well folks, keep your shirt on. Van Jacobson is about to do it again. He has developed something called "PreScript" which is a compiler for a language which bears a striking resemblence to another language we all use, but simply compiles to Postscript. He claims it reduces pages of postscript to a few lines which look amazingly like C. Anyway, he is working to put this stuff in distributable shape, and will then flush it to the world. Please don't pester him about this. It will only slow it down. -Mike O'Dell From don@brillig.umd.edu Sat Jul 9 00:12:26 1988 Date: Sat, 9 Jul 88 00:12:26 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: X vs NeWS - was --> is news loosing the battle? From: mit-vax!jim@bloom-beacon.mit.edu (Jim Fulton) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > NeWS runs quit nicely on Macs and amigas and 386's. I don't > really think anybody is going to bother running X or NeWS on anything smaller > than those type of machines. It depends on whether or not you count the new window system terminals as smaller machines. Also, people are already using machines with 80286's to run window system servers (and have been for over 2 years). It might not be blindingly fast, but for organizations that have a heavy investment in PCs, it is a good solution. Jim Fulton MIT Laboratory for Computer Science From don@brillig.umd.edu Sat Jul 9 00:13:05 1988 Date: Sat, 9 Jul 88 00:13:05 EDT To: NeWS-makers@brillig.umd.edu Subject: Real network windowing (was: losing battle) From: aftac.tis.llnl.gov!carlson@tis.llnl.gov (John Carlson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4777@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >2). I often work on several projects at once. With all of the > interruptions I get, I would like to take the current window > environment, and shrink the entire window to a smaller size and > free up my screen for a new environment. When I want to switch > back to the original environment, I would click on the miniature > screen, which would change place with the current screen. This is > something like the Picture in a Picture (PIP) feature of the new TV's. Amen! In addition, these environments should be a network resource, so I can open up the same environment on another workstation. John Carlson From don@brillig.umd.edu Sat Jul 9 00:15:13 1988 Date: Sat, 9 Jul 88 00:15:13 EDT To: NeWS-makers@brillig.umd.edu Subject: ``X kills networks'' and X vs. NeWS performance in general From: sunquest!whm@arizona.edu (Bill Mitchell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <14318@hc.DSPO.GOV>, tomlin@hc.DSPO.GOV (Bob Tomlinson) writes: > > ... > Meanwhile the NeWS client side is trivially portable to Encores > (as well as MIPS, Alliant, etc.) and is actually being used in large > distributed applications that would *kill* a network if the applications > were using X. ... Bob, how well is your statement re X killing a network based on fact? If you folks have done some performance studies, I'm sure that everyone would like to hear about the results. If you're just speculating, what are the suppositions that led to your conclusion? (i.e., what was the server/ client mix, how much client/server interaction was required for X and NeWS respectively, and what was the network bandwidth?) We've been unable to find anyone who's done performance comparisons of X and NeWS. Let me throw out a couple of simple problems for X and NeWS fans to try on their favorite system: a) Create a C array of endpoint coordinates for 100,000 lines and then draw them. x and y values for endpoint coordinates should be selected using a uniform random distribution and scaled to produce lines with a mean length of five inches. Display the lines in a 10x10 inch window. Variations: After all the lines after been drawn, erase them in reverse order. Erase each line after it is drawn. Draw rectangles using the endpoints as cornerpoints. Generate the endpoints on the server, if you can. b) Using 10-point characters put up an 80x60 character window and scroll through 1000 80-character lines. The 61st line will cause the 1st line to disapear and all other lines to move up one line, just like a scrolling CRT. Use /usr/dict/words as the source of text. Note that each line should be 80 non-blank characters, for example: 10th1st2nd3rd4th5th6th7th8th9thaAaronABAAbabaabackabaloneabandonabaseabashabatea Variations: After displaying the last line, scroll back through the lines to the first line. Use any non-repetitive text from any source that you want to. ------------- Bill Mitchell sunquest!whm@arizona.edu uunet!sunquest!whm {allegra,cmcl2,noao}!arizona!sunquest!whm From don@brillig.umd.edu Sat Jul 9 00:16:42 1988 Date: Sat, 9 Jul 88 00:16:42 EDT To: NeWS-makers@brillig.umd.edu Subject: Adding gravity to LiteWindow From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) % Define subclass of LiteWindow that allows for the specification % of gravity for window icons. % To use it, load it in your user.ps file % and call one of four methods: /leftgravity, /rightgravity, /topgravity, % or /bottomgravity. % E.g.: % (gravitywin.ps) run % /topgravity GravityWindow send /GravityWindow LiteWindow dictbegin % new instance variables /gravityloc null def % what loc do I own? dictend classbegin % Class definitions for gravity % Gravity is set by calling one of the procedures % leftgravity,rightgravity,topgravity,bottomgravity % changing gravity in midstream will produce strange results. /gravityvec null def % array of locs to record in-use positions /gravitylen null def % size of gravityvec /gravityincr null def % size of gravity locs in loc dimension /gravitysign null def % direction of increment (down (-1) or across (+1)) /gravityoffset null def % (constant) size of gravity locs in % non-incrementing dimension /gravitybase null def % starting value for gravity locations /currentgravity /topgravity def % default gravity direction % constants gsave framebuffer setcanvas clippath pathbbox % 0 0 w h 4 -2 roll pop pop % w h grestore /frameheight exch def /framewidth exch def % gravity methods % fill an array with a value /fillarray { % array length value => array exch 0 exch 1 exch 1 sub % a v 0 1 L-1 { % loop body % a v i 3 copy % a v i a v i exch % a v i a i v put % a v i pop % a v } for pop pop } def /leftgravity { % - => - (establish parameters for leftgravity) % For left gravity, we will increment down the y dimension % and our offset will be 0 (=> left side) /leftgravity frameheight 0 IconHeight -1 % since we use lower left, base must start one incr down frameheight IconHeight sub setgravity } def /topgravity { % - => - (establish parameters for topgravity) % For top gravity, we will increment across the x dimension % and our offset will be (frameheight - Iconheight) /topgravity framewidth frameheight IconHeight sub IconWidth 1 0 setgravity } def /rightgravity { % - => - (establish parameters for rightgravity) % For right gravity, we will increment down the y dimension % and our offset will be (framewidth-IconWidth) /rightgravity frameheight framewidth IconWidth sub IconHeight -1 frameheight IconHeight sub setgravity } def /bottomgravity { % - => - (establish parameters for bottomgravity) % For bottom gravity, we will increment across the x dimension % and our offset will be 0. /bottomgravity framewidth 0 IconWidth 1 0 setgravity } def /setgravity { % Gravitykind Framedim Offset Incr Sign Base => - % (set various gravity parameters) /gravitybase exch store /gravitysign exch store /gravityincr exch store /gravityoffset exch store % Kind Fd % calculate # of chunks along this dimension gravityincr idiv % Kind n dup /gravitylen exch store % Kind n % make a locs array of right size array /gravityvec exch store % Kind gravityvec gravitylen 0 % Kind a n 0 fillarray % Kind /currentgravity exch store % - } def % find the index of an unassigned loc in the current loc array /findloc { % - => i (index of free loc) 0 gravityvec { 0 eq {exit} {1 add} ifelse} forall % i % if all are taken, start reusing bottom loc gravitylen 1 sub min dup % i i gravityvec exch 2 copy % i a i a i % loc value is really reference count, so increment it get 1 add put % i } def % Release a loc /freeloc { % - => - (decrement ref count of ith loc) gravityvec gravityloc 2 copy % a i a i get 1 sub 0 max put % prevent ref count lt zero /gravityloc null store } def % Set the initial IconX IconY for the current window /gravitate { % - => - findloc dup /gravityloc exch store % loc gravityincr gravitysign mul mul gravitybase add % loc*sign*incr+base gravityoffset % loc*sign*incr+base offset currentgravity { /leftgravity /rightgravity {/IconX exch store /IconY exch store} /topgravity /bottomgravity {/IconY exch store /IconX exch store} } case % Make sure the Icon canvas knows about this /Iconic? Iconic? /Iconic? true store IconX IconY /move super send store % Restore sate of Iconic? flag. } def /initgravity { % - => - gravityvec null eq { currentgravity { /leftgravity {leftgravity} /rightgravity {rightgravity} /topgravity {topgravity} /bottomgravity {bottomgravity} } case } if } def % override /destroy { % - => - gravityloc null ne {freeloc} if % release our gravity loc /gravityloc null store /destroy super send } def /new { /new super send begin % set initial gravity vector if not already set /initgravity self send % set gravity for this object /gravitate self send currentdict end } def classend def % gravitywin /DefaultWindow GravityWindow store From don@brillig.umd.edu Sat Jul 9 00:17:31 1988 Date: Sat, 9 Jul 88 00:17:31 EDT To: NeWS-makers@brillig.umd.edu Subject: Color Bug on Sun From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! % This is apparently a bug in PostScript running on a Sun 3/260 under NeWS 1.1. % The program should produce a series of 5 boxes, however something % goes wrong with the sethsbcolor for the last box, and PostScript dies % so the box never shows up. Apparently it is the length of the number % which causes the problem, since 0.0666 and 0.1666 are ok % but 0.06667 and 0.16667 kill. % % Tom Schneider % National Cancer Institute % Laboratory of Mathematical Biology % Frederick, Maryland % toms@ncifcrf.gov % 1988 July 8 90 90 scale /box { newpath 0 0 moveto 0 1 lineto 1 1 lineto 1 0 lineto closepath fill } def 0.33 0.5 1.0 sethsbcolor box 2 1 translate 30 rotate 0.0 0.5 1.0 sethsbcolor box 2 1 translate 30 rotate 0.03 0.5 1.0 sethsbcolor box 2 1 translate 30 rotate 0.0666 1 1 sethsbcolor % it's not the 0.666 ... box 2 1 translate 30 rotate 0.06667 1 1 sethsbcolor % it's the 7!!! box From don@brillig.umd.edu Sat Jul 9 00:18:40 1988 Date: Sat, 9 Jul 88 00:18:40 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: is news loosing the battle? From: mike@arizona.edu (Mike Coffin) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >From article , by wayne@dsndata.uucp (Wayne Schlitt): > I have been following both the news and x news groups for a fair while > now and lately i have noticed that there is about ten times the traffic > in the x news group. are there that many more people developing under > x than news, or is the volume just skewed by all the universities on > the net? Another explanation occurs to me. Most of the traffic on the X news group is (a) frustrated people trying to get around questionable design decisions, (b) frustrated people trying to figure out documentation, (c) frustrated people trying to report and/or work around bugs, and (d) frustrated people trying to decide if they have found a bug. Perhaps NeWS is bug-free, well documented, and easy to understand. :-) -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252 From don@brillig.umd.edu Wed Jul 13 01:26:43 1988 Date: Wed, 13 Jul 88 01:26:43 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: pdn!reggie@uunet.uu.net (George W. Leach) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8807061628.AA22039@quartz.BBN.COM>, dm@DIAMOND.BBN.COM ("Dave Mankins") writes: > X is like a weed, it can germinate and spread to your machine > without much attention on your part. With News you have to spend > $40,000 in garden tools and fertilizer before you even get the > seeds. Yes, but a weed can also grow out of control. Withness all the toolkits out there. There needs to be some consensus on A toolkit in order to make applications more portable. -- George W. Leach Paradyne Corporation ..!uunet!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 NOTE: codas<--->pdn will be gone soon Largo, FL 34649-2826 From don@brillig.umd.edu Wed Jul 13 01:26:53 1988 Date: Wed, 13 Jul 88 01:26:53 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: Ron Baxter Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <23581@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >And it's not like there are applications out there crying for NeWS >(eg. things like Frame), there's no noise I've heard from our users >(as a matter of fact I have no idea off-hand what is available with >NeWS other than the environment and a terminal emulator, am I missing >something? How would I know? I haven't seen any literature really and Well that really is an invitation to mention that we have a version of the AT&T S Data Analysis System running under NeWS. It has the name of Ace and the first version is out there but, of course, we are working on the second which will be a whole lot better. So what, you could say, since S is readily available under SunView -- S-Plus comes to mind. Well, since NeWS is built on PostScript it has been quite easy to make Ace generate very impressive color graphics on the screen, and equally impressive grey-scale graphics on the LaserWriter -- instead of the simple Tek-like line drawings that most S users get. So you are right, maybe it will need a bit more time before the number of applications will become noticeable, but I expect these applications will have excellent graphics capabilities because PostScript makes it possible. -- Ron Baxter, CSIRO Div Maths & Stats, PO Box 218, Lindfield, NSW, Australia. PHONE: +61 2 467 6059 ACSNET: ronb@natmlab.oz ARPA: ronb%natmlab.oz@seismo.css.gov UUCP: ....{seismo,hplabs,mcvax,ukc,nttlab}!munnari!natmlab.oz!ronb From don@brillig.umd.edu Wed Jul 13 01:27:09 1988 Date: Wed, 13 Jul 88 01:27:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Buggy Bounded Window From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have been trying to create a window subclass that disallows the window being dragged off the physical screen. This is intended to mimic the behavior of windows under Sunwindows. Below if my code to do this, but it doesn't quite work. The first time I drag any given window, it works fine and the window never leaves the screen. If I subsequently try to drag that window again, the drag behaves very strangely. If anyone can look as this and tell me what is wrong, I would appreciate the help. If you want to see what happens, ;load the following file in your user.ps, create a window, and drag it around a couple of times. The code is adopted from the original /dragcanvas from util.ps. % ------------------ ------------------------------- /BoundedWindow LiteWindow [] classbegin % Modify dragcanvas so that canvas will never leave the % framebuffer screen. % % (x,y+h)----------(x+w,y+h) (x',y'+h)----------(x'+w,y'+h) % | (x0,y0) | ------> | (x0',y0') | % | | | | % (x,y)------------(x+w,y) (x',y')------------(x'+w,y) % % Assume that the canvas is initially at (x,y) with respect to the framebuffer. % Assume that the mouse is at (x0,y0) with respect to the current canvas, % which means that it is at (x0+x,y0+y) w.r.t. framebuffer. % % Assume that we drag the mouse to (x0',y0') with respect to the original % canvas coordinates. This should move the canvas to location (x',y') % where % 1. x' = x+(x0'-x0) % 2. y' = y+(y0'-y0) % % The following code is supposed to enforce the constraint that % the canvas always stays on the framebuffer; i.e., it never leaves the visible % part of the screen. This is intended to mimic the action of windows % under sunwindows. % % DragFrame operates by using the current absolute cursor/mouse % position to determine the location of the window. % We will enforce our constraint by calculating the minimum and % maximum values for the cursor x and y coordinates, w.r.t original % canvas location that will ensure that the window never leaves the screen. % % Let fbW be the width of the framebuffer and % let fbH be the height of the framebuffer. % Let w be the width of the canvas and h be its height. % Let x0max be the x0' such that the right edge of the canvas % would be dragged to the right edge of the framebuffer. % Let x0min be the x0' such that the left edge of the canvas % would be dragged to the left edge of the framebuffer. % Similarly for y0max and y0min. % % Notice that maximum distance that the canvas can move left % is the value of the x coordinate of the original location. % When moving right, notice that the maximum value for the x coordinate % of the dragged frame can be is fbW - w. % Similar observations hold for the y coordinate. % % From this we can establish the following equations, remembering % that x0 and y0 are relative to the original canvas coordinates: % % 1. x0 - x = x0' = xmin % 2. y0 - y = y0' = ymin % 3. (fbW - w) - (x0max - x0) = x (remember that x0max = x0') % 4. (fbH - h) - (y0max - y0) = y (remember that y0max = y0') % % 1. x+w+dx = fbW & dx = x0max - x0 % 2. x = - dx & dx = x0min - x0 (which is negative usually) % 3. y+h+dy = fbH & dy = y0max - y0 % 4. y = - dy & dy = y0min - y0 (which is negative usually) % % From these equations, we can solve for x0min ,x0max,y0min, and y0max. % 1. x0max = (fbW - w) + (x0 - x) % 2. x0min = x0 -x % 3. y0max = (fbH - h) + (y0 - y) % 4. y0min = y0 - y % % We calculate and save these values and use them to bound % the cursor coordinates. % % In the following code, the original x and y coordinates % are kept as follows: % xinit = x % yinit = y % If you want this behavior to occur for all canvases, then % /dragcanvas can be defined into the system dictionary % instead of into this window class. % systemdict begin /dragcanvas { % dragframe? (currentcanvas) => - 30 dict begin % Keep around the framebuffer width gsave framebuffer setcanvas clippath pathbbox % 0 0 w h /fbH exch def /fbW exch def pop pop grestore gsave [1 0 0 1 0 0] setmatrix % initmatrix /Canvas currentcanvas def /dragframe? exch def % Use rules to calculate values of x0min, etc. /calcminmax { % - => - /x0max fbW width sub xo add xinit sub def /x0min xo xinit sub def /y0max fbH height sub yo add yinit sub def /y0min yo yinit sub def } def /absmovecanvas { % x y => - where x,y are relative to current canvas gsave Canvas setcanvas [1 0 0 1 0 0] setmatrix % make sure that the deltaY and deltaX given to movecanvas % never get so large that the canvas will move off the % framebuffer screen y0min max y0max min yo sub exch x0min max x0max min xo sub exch movecanvas calcminmax % since canvas moved grestore } def currentcursorlocation /yo exch def /xo exch def clippath pathbbox /height exch def /width exch def % Negate in the following because of the way getcanvaslocation works. % We want xinit and yinit to be relative to the framebuffer % and getcanvaslocation returns a delta. framebuffer getcanvaslocation /yinit exch neg def /xinit exch neg def % calculate the min and max x and y values for the cursor location % using our equations from above. calcminmax currentcanvas parentcanvas createoverlay setcanvas 0 0 dragframe? {{ % this routine will be repeatedly called by getanimated % to move the canvas % the stack on entry will be x y of current cursor location % relative to currentcanvas. % force to stay on screen y0min max y0max min exch x0min max x0max min exch moveto xo neg yo neg rmoveto 0 height rlineto width 0 rlineto 0 height neg rlineto closepath }} {{ % this routine will be repeatedly called by getanimated % to move the canvas % the stack on entry will be x y of current cursor location % relative to currentcanvas. absmovecanvas newpath }} ifelse getanimated waitprocess aload pop dragframe? {absmovecanvas} {pop pop} ifelse grestore end } def % end % systemdict classend def % BoundedWindow /DefaultWindow BoundedWindow store From don@brillig.umd.edu Wed Jul 13 01:27:48 1988 Date: Wed, 13 Jul 88 01:27:48 EDT To: NeWS-makers@brillig.umd.edu Subject: Fun with windows: make your workstation look more like a Mac... From: ichthyosaur.cis.ohio-state.edu!elwell@tut.cis.ohio-state.edu (Clayton M. Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) This article contains a context diff for the file 'mac.ps' in NeWS 1.1 that makes the mac-style window class more mac-like. Also, since the class MacWindow is equivalent in function and interface to ScrollWindow, you can patch 'nterm' to use it, even without the source (I hate editing binaries, but it worked). Also, if you've installed the fixed window size stuff from Jorgen Knudsen, it will use it, which is handy. You'll need to remove the signature at the end. Enjoy, Clayton -----------------------------------CUT HERE----------------------------- *** mac.ps Sun Jul 10 21:19:30 1988 --- mac.ps.orig Tue Apr 5 15:03:44 1988 *************** *** 9,16 **** systemdict begin % ============================= MacWindow ============================= ! /MacWindow ! systemdict /EnhancedWindow known not { LiteWindow } { EnhancedWindow } ifelse dictbegin /HScrollbar null def /VScrollbar null def --- 9,15 ---- systemdict begin % ============================= MacWindow ============================= ! /MacWindow LiteWindow dictbegin /HScrollbar null def /VScrollbar null def *************** *** 21,30 **** dictend classbegin /BorderLeft 1 def ! /BorderBottom 16 def ! /BorderRight 16 def ! /BorderTop 19 def ! /FrameFont /Helvetica-Bold findfont 12 scalefont def /ClientMinWidth { gsave FrameFont setfont --- 20,29 ---- dictend classbegin /BorderLeft 1 def ! /BorderBottom 18 def ! /BorderRight 18 def ! /BorderTop 20 def ! /FrameFont /Helvetica-Bold findfont 14 scalefont def /ClientMinWidth { gsave FrameFont setfont *************** *** 61,67 **** /StripeMargin 2 def /StripeHeight 12 def /StripeBase 15 def ! /CloseControlX 12 def /destroy { % - => - (Create frame control canvases/items) /HScrollbar null def /VScrollbar null def --- 60,66 ---- /StripeMargin 2 def /StripeHeight 12 def /StripeBase 15 def ! /CloseControlX 16 def /destroy { % - => - (Create frame control canvases/items) /HScrollbar null def /VScrollbar null def *************** *** 90,101 **** rectpath fill grestore } def - /PaintFrameLabel { - FrameWidth 2 div - FrameHeight BorderTop sub - BorderTop currentfont fontascent sub 2 div - currentfont fontdescent max 2 add add moveto FrameLabel cshow - } def /PaintFocus { % - => - (Paint frame canvas) gsave FrameCanvas setcanvas --- 89,94 ---- *************** *** 133,148 **** shapescrollbars } def - /stretchboximage 14 14 1 { } { < - 0000 0000 3F80 2080 20F8 2088 2088 2088 - 3F88 0808 0808 0808 0FF8 0000 - > } buildimage def /PaintFrameControls { % - => - (Paint frame control areas) gsave ! CloseControl setcanvas 2 4 moveto 2 14 lineto 13 14 lineto 13 4 lineto ! 2 4 lineto stroke ! StretchControl setcanvas 1 1 translate 14 14 scale ! false stretchboximage imagemaskcanvas paintscrollbars grestore } def --- 126,135 ---- shapescrollbars } def /PaintFrameControls { % - => - (Paint frame control areas) gsave ! CloseControl setcanvas 0 1 moveto /box showicon ! StretchControl setcanvas 0 0 moveto /stretchSE showicon paintscrollbars grestore } def *************** *** 192,203 **** % ============================= ScrollItem ============================= /MacScrollbar ScrollbarItem [] classbegin ! /ButtonSize 14 def ! /BoxSize 14 def % height of box ! /ArrowSize 14 def % height of btn arrow ! /ScrollDownArrow 14 14 1 { } { < ! 0000 0000 1FC0 1040 1040 1040 F078 4010 ! 2020 1040 0880 0500 0200 0000 > } buildimage def /ItemFillColor .75 .75 .75 rgbcolor def --- 179,189 ---- % ============================= ScrollItem ============================= /MacScrollbar ScrollbarItem [] classbegin ! /BoxSize {ButtonSize} def % height of box ! /ArrowSize 16 def % height of btn arrow ! /ScrollDownArrow 16 16 1 { } { < ! 07F8 0FF8 0818 0818 0818 0818 781F F81F ! 8002 4004 2008 1010 0820 0440 0280 0100 > } buildimage def /ItemFillColor .75 .75 .75 rgbcolor def *************** *** 219,236 **** ItemFrame 0 0 ItemWidth ButtonSize rectframe ButtonFillColor setcolor gsave fill grestore ItemBorderColor setcolor eofill ! ItemBorderColor 14 14 ! ItemWidth ArrowSize sub 2 div ItemFrame ! BarVertical? { 1 sub } { 2 sub } ifelse % hack hack ! PaintArrow ItemFrame 0 ItemHeight ButtonSize sub ItemWidth ButtonSize rectframe ButtonFillColor setcolor gsave fill grestore ItemBorderColor setcolor eofill ! ItemBorderColor 14 -14 ! ItemWidth ArrowSize sub 2 div ItemHeight 1 add ! ItemFrame sub PaintArrow } def /PaintBox { % - => - (paint box) ItemValue BoxPath --- 205,219 ---- ItemFrame 0 0 ItemWidth ButtonSize rectframe ButtonFillColor setcolor gsave fill grestore ItemBorderColor setcolor eofill ! ItemBorderColor 16 16 ! ItemWidth ArrowSize sub 2 div ItemFrame PaintArrow ItemFrame 0 ItemHeight ButtonSize sub ItemWidth ButtonSize rectframe ButtonFillColor setcolor gsave fill grestore ItemBorderColor setcolor eofill ! ItemBorderColor 16 -16 ! ItemWidth ArrowSize sub 2 div ItemHeight ItemFrame sub PaintArrow } def /PaintBox { % - => - (paint box) ItemValue BoxPath --------------------------------CUT HERE--------------------------------- Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Wed Jul 13 01:39:19 1988 Date: Wed, 13 Jul 88 01:39:19 EDT To: NeWS-makers@brillig.umd.edu Subject: "reading the contents of a drawing surface" From: pyramid!prls!philabs!parrot!per@decwrl.dec.com (Paul E. Rutter) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In the June 88 issue of "Unix Review" magazine, there is an article by Samuel Leffler on NeWS. On page 69, there is a discussion of reading back the contents of an image once it's been rendered: this is not in postscript because it was designed for printers, it is needed for interactive displays, the usual solution is shadow data structures, which are tedious. Then he states that: "For this reason, the most recent release of NeWS (Version 1.1) provides PostScript extensions for reading the contents of a drawing surface" Can someone explain what these extensions are? We have a 1.1 manual here, but we have not received our full 1.1 documentation yet. It does not seem to be mentioned in the 1.1 manual itself. From don@brillig.umd.edu Wed Jul 13 02:01:41 1988 Date: Wed, 13 Jul 88 02:01:41 EDT To: NeWS-makers@brillig.umd.edu Subject: bind function in NeWS From: amara!khai@uunet.uu.net (Sao Khai Mong) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Could somebody please explain to me what the bind function in NeWS does? It seems to do absolutely nothing. Please provide an example where it does something at all. -- --------------------+------------------------------------------------------- ...uunet!amara!khai | Applied Dynamics International, 3800 Stone School Road khai@amara.uucp | Ann Arbor, Michigan 48105, U.S.A (313) 973-1300 --------------------+------------------------------------------------------- From don@brillig.umd.edu Wed Jul 13 02:01:52 1988 Date: Wed, 13 Jul 88 02:01:52 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: ``X kills networks'' and X vs. NeWS performance in general From: eagle!icdoc!qmc-cs!liam@ucbvax.Berkeley.EDU (William Roberts) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <111@sunquest.UUCP> whm@sunquest.UUCP (Bill Mitchell) writes: > a) Create a C array of endpoint coordinates for 100,000 lines and then > draw them. x and y values for endpoint coordinates should be > selected using a uniform random distribution and scaled to > produce lines with a mean length of five inches. Display the > lines in a 10x10 inch window. > > Variations: > After all the lines after been drawn, erase them in reverse order. > > Erase each line after it is drawn. > > Draw rectangles using the endpoints as cornerpoints. > > Generate the endpoints on the server, if you can. OK, I'll try it if I can find the time - the only snags are: NeWS can't selectively erase lines X can't generate random numbers in the server Suggested experimental parameters: Local vs remote clients backing store/no backing store Thick lines/fast lines Would it matter if I used the standard UNIX random number generator with user-supplied seed value (so you can reproduce the same sets of endpoints) and ignored the normalisation? -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250 From don@brillig.umd.edu Wed Jul 13 02:02:00 1988 Date: Wed, 13 Jul 88 02:02:00 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS on HP9000 From: lll-crg.llnl.gov!hesh@lll-winken.llnl.gov (Chris Steinbroner) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) could somebody substantiate a rumour i heard that claimed Columbia ported NeWS to hp9000's? thanks... -- Chris E. Steinbroner -- hesh@lll-crg.llnl.gov -- {ames,hoptoad,pyramid,sun}!lll-crg!hesh From don@brillig.umd.edu Wed Jul 13 02:03:14 1988 Date: Wed, 13 Jul 88 02:03:14 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS 1.1 or wait for X/NeWS from sun. From: rochester!ur-tut!ur-valhalla!saturn.ee.rochester.edu!brown@cu-arpa.cs.cornell.edu (Eric Brown) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Organization: UR Dept. of Electrical Engg, Rochester NY 14627 Currently we are using NeWS 1.0 and are having a bit of difficulty with the manual and programming with it in general. We are trying to develop a graphics intensive program in NeWS. We are wondering if we should continue developing in 1.0 or upgrade to 1.1 before X/NeWS becomes available. Are the manuals, examples and the psterm for 1.1 significantly better than the same that came with 1.0? Thanks in advance. Eric Brown Adam Sherer brown@galaxy.ee.rochester.edu sherer@galaxy.ee.rochester.edu From don@brillig.umd.edu Wed Jul 13 02:03:18 1988 Date: Wed, 13 Jul 88 02:03:18 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: bind function in NeWS From: hydar@ernie.Berkeley.EDU (Dan Hydar) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article khai@amara.uucp (Sao Khai Mong) writes: >Could somebody please explain to me what the bind function in >NeWS does? It seems to do absolutely nothing. Please provide >an example where it does something at all. The thing you should remember is that NeWS has this thing called "autobind" which is on by default -- when this is on all executable names inside a procedure that resolve to an operator are replaced by that operator. The reason that bind doesn't seem to do anything is probably because the "bind"-ing has already taken place before the "bind" operator is executed. Example 1: true setautobind % turn on autobind (default) { add } 0 get type == % get element from array % and print it's type Will print: operatortype Because the name has been replaced. Example 2: false setautobind % turn off autobind /not-bound { add } def % unbound procedure /is-bound { add } bind def % bound procedure /not-bound load 0 get type == % get element from arrays % and print types /is-bound load 0 get type == This will print: nametype operatortype Since in "not-bound" the name is still in the procedure whereas in "bound" it has been replaced. |Dan| "It's all very simple. Or else it's all very complex. Or else it's neither. Or both." From don@brillig.umd.edu Thu Jul 14 14:25:58 1988 Date: Thu, 14 Jul 88 14:25:58 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: ``X kills networks'' and X vs. NeWS performance in general From: sunquest!whm@arizona.edu (Bill Mitchell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <111@sunquest.UUCP>, I proposed a couple of problems for studying the relative performance of X and NeWS. In a couple of the proposed variations of the first problem, I spoke of "erasing" lines that had been drawn. That makes things sound a little more complicated than what I mind, namely, erase the lines by just drawing lines in the background color; don't worry about preserving the continuity of the intersecting lines. Bill Mitchell sunquest!whm@arizona.edu uunet!sunquest!whm {allegra,cmcl2,noao}!arizona!sunquest!whm From don@brillig.umd.edu Thu Jul 14 14:26:37 1988 Date: Thu, 14 Jul 88 14:26:37 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: "reading the contents of a drawing surface" From: hoptoad!gnu@ucbvax.Berkeley.EDU (John Gilmore) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) per@parrot.Philips.Com (Paul E. Rutter) wrote: > In the June 88 issue of "Unix Review" magazine, there is an article by > Samuel Leffler on NeWS. On page 69, there is a discussion of reading back > the contents of an image once it's been rendered: this is not in postscript > because it was designed for printers, it is needed for interactive displays Actually, this capability in printers would be very useful. It took a lot of wierd programming to get anything approaching reasonable speed when printing the "Face Saver" labels at Usenixes. The problem is that you want to print the same image about 30 times on the same page, to produce 30 identical labels. You can just re-image the picture and text 30 times, but this is really slow; it would be a lot nicer to image it once and then bit-copy it 29 times. The stuff I saw last year at Usenix would do it the slow way if there was only one person in the print queue. If there were two people, it would print one person in two columns and the other in one column, do a "copypage", clear out the middle column and put the other person in it, then do a "showpage". If there were three people in the queue, it would give each of them a column and do two "copypage"s and a "showpage". Beginning to get the [kludge!] picture? The three primitives in NeWS that Sam might have been talking about are copyarea, writecanvas, and writescreen. Copyarea copies the region outlined by the current path, to a position (deltax, deltay) from its current position. Writecanvas writes the current canvas to a file. Writescreen writes the current canvas to a file, including bits from canvases that lie on top of the current canvas (e.g. a screendump). There's also a readcanvas which reads in a rasterfile, and an imagecanvas which images the bits from one canvas onto another. -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com "And if there's danger don't you try to overlook it, Because you knew the job was dangerous when you took it" From don@brillig.umd.edu Thu Jul 14 14:27:04 1988 Date: Thu, 14 Jul 88 14:27:04 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on HP9000 From: Chris Maio Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Yes, NeWS runs on HP 9000/300 workstations with the "topcat" color display card. A little more work would be needed to get it running on the monochrome or "catseye" color cards, but I don't have any of those to play with. Chris From don@brillig.umd.edu Thu Jul 14 14:27:55 1988 Date: Thu, 14 Jul 88 14:27:55 EDT To: NeWS-makers@brillig.umd.edu Subject: more demos available? From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) On page 28 of what is labeled as "NeWS Programming 10/14/87", there are pictures of 3 applications titled: Maze, Puzzle, and Snake. Are these applications available, and is so, how do I obtain them? Thanks in advance. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Thu Jul 14 14:27:05 1988 Date: Thu, 14 Jul 88 14:27:05 EDT To: NeWS-makers@brillig.umd.edu Subject: Yin/Yang root image---with a twist From: spe@spice.cs.cmu.edu (Sean Engelson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) % This program changes the root image to a Yin/Yang symbol on a purplish % background. It also, if you want, will set the symbol to spin % around its centre. Quite pretty. % Created by Sean P. Engelson % Spinning thought of by John Kolojejchick systemdict begin % Draw a yin/yang (just some arcs and fills) /yinyang { % angle x y => __ translate 40 40 scale 10 10 translate rotate -10 -10 translate 1 setgray newpath 10 10 10 0 180 arcn 5 10 5 180 0 arc 15 10 5 180 0 arcn fill 0 setgray newpath 10 10 10 0 180 arc % big arc black side 5 10 5 180 0 arc % black bulge 15 10 5 180 0 arcn % white bulge fill gsave 4 10 moveto newpath 5 10 1 0 360 arc 1 setgray fill grestore newpath 10 10 10 0 360 arc stroke newpath 14 10 moveto newpath 15 10 1 0 360 arc 0 setgray fill } def % angle to draw it at /YinYangAng 0 def % Draw it on the root /RootYinYang { gsave framebuffer setcanvas 0 0 1200 1200 rectpath .5 .5 1 setrgbcolor fill YinYangAng 160 60 yinyang grestore } def /PaintRoot /RootYinYang load store PaintRoot end % Set the yin/yang to spin by queuing events. /TimeYinYang { { /d 2 dict dup begin /RotateYinYang { /YinYangAng YinYangAng 5 add store % change the 5 to adjust % the speed gsave framebuffer setcanvas YinYangAng 160 60 yinyang grestore SendNewYinYangEvent } def end def /e1 createevent def e1 /Name d put e1 expressinterest /SendNewYinYangEvent { e1 createevent copy dup begin /Name /RotateYinYang def /TimeStamp currenttime .05 add def end sendevent } def SendNewYinYangEvent { awaitevent } loop } fork } def % If you don't want it to spin, comment this next line: TimeYinYang From don@brillig.umd.edu Thu Jul 14 14:27:31 1988 Date: Thu, 14 Jul 88 14:27:31 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: ulysses!cjc@ucbvax.Berkeley.EDU (Chris Calabrese[rs]) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8807090612.AA05871@dmssyd.dms.oz>, ronb@natmlab.dms.OZ.AU.UUCP writes: > > In article <23581@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > > > >And it's not like there are applications out there crying for NeWS > >(eg. things like Frame), there's no noise I've heard from our users > >(as a matter of fact I have no idea off-hand what is available with > >NeWS other than the environment and a terminal emulator, am I missing > >something? How would I know? I haven't seen any literature really and > > Well that really is an invitation to mention that we have a > version of the AT&T S Data Analysis System running under > NeWS. It has the name of Ace and the first version is out > there but, of course, we are working on the second which will > be a whole lot better. > > So what, you could say, since S is readily available under > SunView -- S-Plus comes to mind. Well, since NeWS is built on > PostScript it has been quite easy to make Ace generate > very impressive color graphics on the screen, and equally > impressive grey-scale graphics on the LaserWriter -- instead > of the simple Tek-like line drawings that most S users get. > > So you are right, maybe it will need a bit more time before > the number of applications will become noticeable, but I > expect these applications will have excellent graphics > capabilities because PostScript makes it possible. What, you don't have a color PostScript printer yet??? O.K. the one we have here is about $20,000, so you're off the hook. Anyway, I whole heartedly agree. The project I'm working on now is using NeWS for just these types of reasons. Quick development time. Can print anything that can be displayed on the screen. Low network bandwidth (for those who say that such things as menu synchronization eat this up, I say hog wash! Just write the _whole_ application in PostScript, and you won't have to worry about communication costs. Actually, our software is about 90% in PostScript, so it is possible, without losing performance (speed of drawing and doing large datbase searches are much bigger problems on our project than speed of interpreting the PostScript code. Don't have to take a course in computer graphics to understand it. PostScript looks messy, but it's really _clean_ and easy to understand. Plus, the imaging model is more intuitive for those of us who have studdied art, and not fundamentals of math oriented bit blitting 403 in graduate school. -- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc From don@brillig.umd.edu Thu Jul 14 14:29:20 1988 Date: Thu, 14 Jul 88 14:29:20 EDT To: NeWS-makers@brillig.umd.edu Subject: implementation of inheritance within PostScript From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Did Sun extend PostScript to incorporate inheritance, or do the NeWS operators used to implement inheritance only need PostScript's predefined dictionary semantics? Thanks in advance. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Thu Jul 14 23:03:39 1988 Date: Thu, 14 Jul 88 23:03:39 EDT To: NeWS-makers@brillig.umd.edu Subject: bind function in NeWS From: Paul Hudson Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) That's to be "compatible" with 23.0 Postscript (grin). It didn't do anything there either. Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "It's no use looking, there's nothing Cambridge, witty here" CB4 4FQ From don@brillig.umd.edu Thu Jul 14 23:03:49 1988 Date: Thu, 14 Jul 88 23:03:49 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: implementation of inheritance within PostScript From: ichthyosaur.cis.ohio-state.edu!elwell@tut.cis.ohio-state.edu (Clayton M. Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) marshall@software.ORG (Eric Marshall) writes: Did Sun extend PostScript to incorporate inheritance, or do the NeWS operators used to implement inheritance only need PostScript's predefined dictionary semantics? It's pretty slick--they use just plain ole PostScript. Basically, objects are dictionaries, and the dictionary stack is used to handle inheritance. Methods are invoked with an explicit 'send' call, as in: framebuffer /new DefaultWindow send which calls the 'new' method of the object (class) DefaultWindow. By the time the method gets control, the operand stack is cleaned up, so the value of 'framebuffer' is available as an argument to the method. There are some performance hacks that take advantage of the fact that procedures in PostScript are really arrays deep in their hearts, and thus can be taken apart and put back together differently, but it's all strictly by the book (the red one, in this case). If you want to do object-based stuff on your printer, it'll run... Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Thu Jul 14 23:04:37 1988 Date: Thu, 14 Jul 88 23:04:37 EDT To: NeWS-makers@brillig.umd.edu Subject: Bounded Canvases From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Below is a modified 'dragcanvas' from 'util.ps'. It forces dragged canvases to remain completely within their parent canvases. In particular, it will force dragged windows to remain completely visible on the screen. To use it, put something like (newdragcanvas.ps) run into your user.ps file, where newdragcanvas.ps contains the following code. -------------------------------------------------- % Modify dragcanvas so that canvas will never leave the % parent canvas screen. % % ---------------------------------------------------------------------- % | | % | (x,y+h)----------(x+w,y+h) (x',y'+h)----------(x'+w,y'+h) | % | | (x0,y0) | ------> | (x0',y0') | | % | | | | | | % | (x,y)------------(x+w,y) (x',y')------------(x'+w,y) | % | | % (0,0)----------------------------------------------------------------- % % Assume that the canvas is initially at (x,y) with respect to the % parent canvas. % Assume that the cursor is at (x0,y0) with respect to the parent canvas, % which means that it is at (x0-x,y0-y) w.r.t. canvas. % % Assume that we drag the cursor to (x0',y0') with respect to the parent % canvas. This implies that the canvas should be dragged to the new % coordinates (x',y'). % % Notice that this implies that % 1. dx = (x'-x) = (x0'-x0) % 2. dy = (y'-y) = (y0'-y0) % Solving for x' and y' gives % 3. x' = x + dx = x + (x0' - x0) % 4. y' = y + dy = y + (y0' - y0) % % The following code is supposed to enforce the constraint that % the canvas always stays on the parent canvas; % i.e., it never leaves the visible % part of the screen. This is intended to mimic the action of windows % under sunwindows. % % DragFrame operates by using the current cursor position (w.r.t parent % canvas) to determine the location of the window. % Note that cursor is relative to parent rather than the canvas because % getanimated gives such absolute coordinates during the drag. % We also note that the canvas is moved using 'movecanvas'. % In this situation, the movement delta vector is such that % it must be given the new coordinates of the canvas % w.r.t the parent canvas, so it must be given (x',y') % as its arguments. % We choose to enforce our constraint by calculating the minimum and % maximum values for (x',y') % that will ensure that the window never leaves the screen. % % Let PCW be the width of the parent canvas and % let PCH be the height of the parent canvas. % Let w be the width of the canvas and h be its height. % Let xmax be the x' such that the right edge of the canvas % would be dragged to the right edge of the parent canvas. % Let xmin be the x' such that the left edge of the canvas % would be dragged to the left edge of the parent canvas. % Similarly for ymax and ymin. % % When moving left, the minimum x' value is, of course, 0. % When moving right, notice that the maximum value for x' is PCW - W % Similar observations hold for the y coordinate. % % From these observations, we obtain the equations: % 5. xmin = 0 % 6. ymin = 0 % 7. xmax = (PCW - w) % 8. ymax = (PCH - h) % % We calculate and save these values and use them to bound % the 'movecanvas' coordinates. % % In the following code, the original x and y coordinates % are kept as follows: % xinit = x % yinit = y % % systemdict begin /dragcanvas { % dragframe? (currentcanvas) => - 30 dict begin gsave [1 0 0 1 0 0] setmatrix % initmatrix /Canvas currentcanvas def /dragframe? exch def /ParentCanvas Canvas parentcanvas def % Get and save width and height of Canvas Canvas setcanvas clippath pathbbox /height exch def /width exch def % Calculate xmin and ymin /xmin 0 def /ymin 0 def gsave % Calculate xmax and ymax ParentCanvas setcanvas clippath pathbbox % 0 0 PCW PCH height sub /ymax exch def width sub /xmax exch def % Get coordinates of Canvas w.r.t its Parent Canvas. Canvas ParentCanvas setcanvas getcanvaslocation /yinit exch def /xinit exch def grestore % remember the initial location of the cursor w.r.t parent canvas currentcursorlocation % realtive to canvas yinit add /yo exch def xinit add /xo exch def % relative to parent and save % When not dragging frame, give this routine to getanimated /absmovecanvas { % x y => - where x,y cursor relative to parent canvas % that is, they are more-or-less absolute coordinates gsave Canvas setcanvas [1 0 0 1 0 0] setmatrix % Convert the incoming parent-relative cursor coordinates % to (x',y') using equations 3 and 4. yo sub yinit add exch xo sub xinit add exch % Apply bounds to these coordinates ymin max ymax min exch xmin max xmax min exch movecanvas grestore } def ParentCanvas createoverlay setcanvas 0 0 dragframe? {{ % this routine will be repeatedly called by getanimated % to move the canvas % the stack on entry will be x y of current cursor location % relative to parentcanvas. % Convert the incoming parent-relative cursor coordinates % to (x',y') using equations 3 and 4. yo sub yinit add exch xo sub xinit add exch % Apply bounds to these coordinates ymin max ymax min exch xmin max xmax min exch % Now, draw a bounding box from these coordinates moveto 0 height rlineto width 0 rlineto 0 height neg rlineto closepath }} {{ % this routine will be repeatedly called by getanimated % to move the canvas % the stack on entry will be x y of current cursor location % relative to currentcanvas. absmovecanvas newpath }} ifelse getanimated waitprocess aload pop dragframe? {absmovecanvas} {pop pop} ifelse grestore end } def end % systemdict From don@brillig.umd.edu Thu Jul 14 23:04:54 1988 Date: Thu, 14 Jul 88 23:04:54 EDT To: NeWS-makers@brillig.umd.edu Subject: Icon Gravity resource From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Previously I posted a version of LiteWindow that allowed for Icon gravity. Following is a modified version that moves the gravity assignment code into a separate globally accessible dictionary called Icongravity The hope is that this dictionary would be accessed as decribed below to assign the initial coordinates for all programs that create icons. Thus, icon gravity would operate universally. At the end of this file is a modified version of GravityWindows that uses the icon gravity resource. -------------------------------------------------- % Define a resource that allows for the specification % of gravity for icons. % To use it, load it in your user.ps file % and initialize it with % one of four arguments: /leftgravity, /rightgravity, /topgravity, % or /bottomgravity, and the height and width of icons. % E.g.: % (gravity.ps) run % assume code is in this file % IconGravity begin /topgravity 64 64 initgravity end % Changing gravity in midstream is possible, but will produce strange results. % The gravity stuff is intended to be used by all icon creators. % To do this, we build a dictionary that has all the gravity state % and place it in the system dict with the name /IconGravity. % IconGravity contains all the operators as well: /topgravity ... % % All icon builders should do the following: % 1. On icon create: % IconGravity begin setgravity end % This will leave the icon identifier and the (x,y) for your icon % on the stack. % 2. On icon destroy: % IconGravity begin iconid unsetgravity end % This will free up the icon space for your icon. % systemdict begin /IconGravity 100 dict def end IconGravity begin % constants gsave framebuffer setcanvas clippath pathbbox % 0 0 w h 4 -2 roll pop pop % w h grestore /frameheight exch def /framewidth exch def /iconheight null def /iconwidth null def /DefaultGravity /rightgravity def /DefaultIconWidth 64 def /DefaultIconHeight 64 def % Gravity State Variables /gravityvec null def % array of locs to record in-use positions /gravitylen null def % size of gravityvec /gravityincr null def % size of gravity locs in loc dimension /gravitysign null def % direction of increment (down (-1) or across (+1)) /gravityoffset null def % (constant) size of gravity locs in % non-incrementing dimension /gravitybase null def % starting value for gravity locations /currentgravity null def % default gravity direction /gravitymonitor createmonitor def % to control access to gravity % internal gravity procedures % fill an array with a value /fillarray { % array length value => array exch 0 exch 1 exch 1 sub % a v 0 1 L-1 { % loop body % a v i 3 copy % a v i a v i exch % a v i a i v put % a v i pop % a v } for pop pop } def /leftgravity { % - => - (establish parameters for leftgravity) % For left gravity, we will increment down the y dimension % and our offset will be 0 (=> left side) /leftgravity frameheight 0 iconheight -1 % since we use lower left, base must start one incr down frameheight iconheight sub startgravity } def /topgravity { % - => - (establish parameters for topgravity) % For top gravity, we will increment across the x dimension % and our offset will be (frameheight - iconheight) /topgravity framewidth frameheight iconheight sub iconwidth 1 0 startgravity } def /rightgravity { % - => - (establish parameters for rightgravity) % For right gravity, we will increment down the y dimension % and our offset will be (framewidth-iconwidth) /rightgravity frameheight framewidth iconwidth sub iconheight -1 frameheight iconheight sub startgravity } def /bottomgravity { % - => - (establish parameters for bottomgravity) % For bottom gravity, we will increment across the x dimension % and our offset will be 0. /bottomgravity framewidth 0 iconwidth 1 0 startgravity } def /startgravity { % Gravitykind Framedim Offset Incr Sign Base => - % (set various gravity parameters) /gravitybase exch store /gravitysign exch store /gravityincr exch store /gravityoffset exch store % Kind Fd % calculate # of chunks along this dimension gravityincr idiv % Kind n dup /gravitylen exch store % Kind n % make a locs array of right size array /gravityvec exch store % Kind gravityvec gravitylen 0 % Kind a n 0 fillarray % Kind /currentgravity exch store % - } def % find the index of an unassigned loc in the current loc array /findloc { % - => i (index of free loc) 0 gravityvec { 0 eq {exit} {1 add} ifelse} forall % i % if all are taken, start reusing bottom loc gravitylen 1 sub min dup % i i gravityvec exch 2 copy % i a i a i % loc value is really reference count, so increment it get 1 add put % i } def % exported gravity procedures % Return iconid and IconX IconY /setgravity { % - => id x y gravitymonitor { % make sure gravity is initialized currentgravity null eq {DefaultGravity DefaultIconWidth DefaultIconHeight initgravity} if findloc dup % id(=loc) loc gravityincr gravitysign mul mul gravitybase add % id loc*sign*incr+base gravityoffset % id loc*sign*incr+base offset currentgravity { /leftgravity /rightgravity { exch } % Want y coordinate on top } case } monitor } def /unsetgravity { % iconid => - gravitymonitor { % make sure gravity is initialized currentgravity null eq {DefaultGravity DefaultIconWidth DefaultIconHeight initgravity} if % Decrement reference count for this location gravityvec exch 2 copy % a i a i get 1 sub 0 max put % prevent ref count lt zero } monitor } def /initgravity { % direction iconwidth iconheight => - % stash iconwidth and height /iconheight exch store /iconwidth exch store { % branch on direction argument /leftgravity {leftgravity} /rightgravity {rightgravity} /topgravity {topgravity} /bottomgravity {bottomgravity} /Default {DefaultGravity load exec} } case } def end % IconGravity %-------------------------------------------------- % Build a subclass of window that initializes its icon location % using IconGravity. /GravityWindow LiteWindow dictbegin % new instance variables /gravityid null def % id for my icon dictend classbegin % override /destroy { % - => - gravityid IconGravity begin unsetgravity end % release our location /gravityid null store /destroy super send } def /new { /new super send begin % set gravity for this window IconGravity begin setgravity end % Store the results /IconY exch store /IconX exch store /gravityid exch store % Make sure the Icon canvas knows about this /Iconic? Iconic? /Iconic? true store IconX IconY /move super send store % Restore sate of Iconic? flag. currentdict end } def classend def % GravityWindow /DefaultWindow GravityWindow store From don@brillig.umd.edu Thu Jul 14 23:04:36 1988 Date: Thu, 14 Jul 88 23:04:36 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: implementation of inheritance within PostScript From: gregm@Sun.COM (Greg McLaughlin) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Did Sun extend PostScript to incorporate inheritance, >or do the NeWS operators used to implement inheritance only need >PostScript's predefined dictionary semantics? > >Thanks in advance. > > >Eric Marshall >Software Productivity Consortium >1880 North Campus Commons Drive >Reston, VA 22091 >(703) 391-1838 The NeWS implemetation of inheritance only needs PostScript's predefined dictionary sematics. At last check (about 1 year ago), if you run the NeWS classing code through a LaserWriter it works fine. You can look at all the code that is used in /usr/NeWS/lib/NeWS/class.ps. Recently for 1.1 we implemented 'send' in C for performance, but class.ps still contains the original implementaion of send. Greg McLaughlin Sun Microsystems Inc. From don@brillig.umd.edu Sun Jul 17 05:55:17 1988 Date: Sun, 17 Jul 88 05:55:17 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: X vs NeWS - was --> is news loosing the battle? From: root@sbcs.sunysb.edu (root) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <10250003@hpfclp.SDE.HP.COM>, diamant@hpfclp.SDE.HP.COM (John Diamant) writes: > to get some of the vendors to look at NeWS was to provide it on the AT&T > tape in the X11/NeWS merge (due to the large source licensing fee). Until it > was clear that X11 was here to stay, Sun kept trying to make NeWS the standard > and kill X. Only when it was clear that it wasn't going to work, did they join I've been to a couple rah-rah seminars for NeWS; its creators have shown considerable restraint towards bashing X. More so than I would have if I created a great product like NeWS. As for the "large source license fee", one hat I wear besides the one at Stony Brook is that of a small company. My partners and I were able to afford a NeWS license - I can't see why anyone else would have a problem. Especially HP :-). I've not spoken to anyone on the NeWS project that had the attitude that they're out to build NeWS to foist it on the world, kill X11, etc. It seems that they have their view of what a network window system should look like and they've been pursuing it. > the bandwagon. > > > I think sun's attitude seems to more "may the best > > one win". sun's policy on NeWS is pretty much like NFS , if you want > > a reference source kit you hand over your XXXX amount of dollars and > > you get it. > > Yes, that is true now. However, it is virtually impossible to implement either > NFS or NeWS without the reference source. > Untrue about NFS. We implemented an NFS client for the Amiga from the protocol spec. No problem at all. We will shortly introduce an NFS server product that was built, once again, from the publicly available specs. NeWS would be a tougher nut to crack, but I think it is doable. I've done my share of Sun bashing, but one area you really can't touch them on is they do make their technology available, and for pretty reasonable fees. > > I believe I have seen X product announcements for X on an IBM PC (8088). I'm > pretty sure I've seen recommended configurations as low as 286 at least. I'm > thinking in terms of dedicated X or NeWS terminals. The problem with NeWS > terminals is that someone might try to run large portions of their program > in the terminal, and it won't be able to handle it. It could probably handle > reasonable client/server mixes, but there is nothing to prevent a NeWS program > from attempting to run almost entirely in the server, which I'm sure would > fail miserably on a NeWS terminal. NeWS running on the Amiga isn't terribly fast compared to even NeWS on a 3/50. The important point to remember here is that a small machine running X or NeWS is delivering price performance rather than graphics performance. As to whether one needs less machine to run X, here is a suprising result: The alpha binary for one X11 server on the Amiga is actually 40Kbytes larger than our current NeWS binary. The performance seems to be similar. Both ports require similar machine resources to run, eg ~2-3 mBytes ram, ~10 mBytes fonts, etc. Both ports are roughly at the same stage of maturity. Draw your own conclusions - the one I like is that it is just too early to say that either X or NeWS inherently require less machine than the other. > John Diamant > Software Development Environments > Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com > Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant Let me just say that despite my obvious bias towards NeWS, I most certainly not anti X. All of this X vs NeWS vs etc nervous energy ought to be directed towards standardizing user interfaces so that we can get on with getting reasonable computers into mass markets. In the end, does the customer really care whether it is PostScript, X RPC, etc on the wire? Of course not. Rick Spanbauer SUNY/Stony Brook From don@brillig.umd.edu Sun Jul 17 05:56:00 1988 Date: Sun, 17 Jul 88 05:56:00 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Traffic on the X list From: att!chinet!mcdchg!clyde!watmath!utgpu!jarvis.csri.toronto.edu!godzilla.ele.toronto.edu!moraes@ucbvax.Berkeley.EDU (Mark Moraes) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <3678@pdn.UUCP> reggie@pdn.UUCP (George W. Leach) writes: >In article <8807061628.AA22039@quartz.BBN.COM>, dm@DIAMOND.BBN.COM ("Dave Mankins") writes: > Yes, but a weed can also grow out of control. Withness all the toolkits >out there. There needs to be some consensus on A toolkit in order to make >applications more portable. With X10, people grumbled that there weren't any standard toolkits. With X11, there are too many ... :-) There aren't too many toolkits for X - the Xt intrinsics seem to have been accepted as a standard, it seems. I like it - it offers powerful primitives. You get the Athena widgets and the HP widgets layered on top on that - use one or both sets. According to the Open Look press releases, AT&T is going to layer it on top of Xt as well. (NeWS too). Majority of the X applications seem to use Xt with Xaw. The Andrew Toolkit is pretty much a system in its own right - more like an environment. CLUE is for Lisp, InterViews is for C++. I believe HP ported Xray to X11 to provide an upgrade path for X10 Xray users. They encourage use of the HP widgets. From don@brillig.umd.edu Sat Jul 23 21:59:17 1988 Date: Sat, 23 Jul 88 21:59:17 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: X vs NeWS - was --> is news loosing the battle? From: weiser.pa@Xerox.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) "Yes, that is true now. However, it is virtually impossible to implement either NFS or NeWS without the reference source." There are counterexamples to this. There are at least two no-cost implementations of Postscript, both capable of writing to screens, done with using the reference source. And of course many people have done NFS from the specs. We here have done one of each (although ours are not publically available). -mark From don@brillig.umd.edu Sat Jul 23 21:59:35 1988 Date: Sat, 23 Jul 88 21:59:35 EDT To: NeWS-makers@brillig.umd.edu Subject: Behavior of 'movecanvas' From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) It appears that movecanvas has some very strange behavior. If I execute the code at the end of this message, I create a canvas of size 200 X 200 and a child canvas within it of size 50 X 50 located at (0,0) within its parent. Suppose I do the following to use movecanvas: gsave C setcanvas 0 175 movecanvas grestore I would expect this to move the child halfway off the parent in the y direction. But,the child will actually only move to (0,150). Similar things occur if I try to move to (-25,0) (i.e., halfway off in the -x direction). In other words, I can't move off the screen at all in the in the -x or +y direction. I am guessing that this behavior has to do with the fact that NeWS is probably implemented using the original pixrect code, which as I recall has its (0,0) in the upper left corner. Thus, in that frame, it is impossible to move a canvas to have either a negative x or negative y value. Note that moving in the +x or -y direction works fine. Can anyone help me figure out a workaround so that I can move a child canvas arbitrarily w.r.t. its parent? -------------------------------------------------- /P framebuffer newcanvas def % define the parent canvas P /Retained true put P /Transparent false put gsave P setcanvas 0 0 200 200 rectpath P reshapecanvas % make the parent 200X200 grestore gsave P setcanvas 0 0 movecanvas % move parent to (0,0) w.r.t. framebuffer grestore /C P newcanvas def % make child canvas C /Retained true put C /Transparent false put gsave C setcanvas 0 0 50 50 rectpath C reshapecanvas % make child 50X50 0 0 0 setrgbcolor clippath fill % fill child with black for visibility grestore gsave C setcanvas 0 0 movecanvas % move child to (0,0) w.r.t. parent grestore % make both canvases visible P /Mapped true put C /Mapped true put % Try to move child part way off in +y direction gsave C setcanvas 0 175 movecanvas grestore % See what the location of C is w.r.t. parent gsave P setcanvas (x = % y = %\n) [C getcanvaslocation] dbgprintf grestore From don@brillig.umd.edu Sat Jul 23 22:00:10 1988 Date: Sat, 23 Jul 88 22:00:10 EDT To: NeWS-makers@brillig.umd.edu Subject: size of a unit? From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) It does not appear that the size of a unit within the default user space is 1/72nd of an inch, as in standard PostScript. Is this true? If so, why the deviation? I suspect that it may just be a hardware limitation, because the size of a unit appears to be about 1/83rd of an inch, on a 3/160, which sounds pretty close to the pixels per inch value. Thanks in advance. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Sat Jul 23 22:00:34 1988 Date: Sat, 23 Jul 88 22:00:34 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: bind function in NeWS From: adobe!greid@decwrl.dec.com Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >[Re: "bind" operator"] >That's to be "compatible" with 23.0 Postscript (grin). >It didn't do anything there either. >Paul Hudson That's not true; it worked exactly as documented, and still does (there are still lots of 23.0 PostScript printers out there :-) Glenn Reid Adobe Systems From don@brillig.umd.edu Sat Jul 23 22:00:42 1988 Date: Sat, 23 Jul 88 22:00:42 EDT To: NeWS-makers@brillig.umd.edu Subject: archiving this news group (have data, need administrator) From: linus!tony@gatech.edu (Tony E. Davis) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have been maintaining a personal archive of this newsgroup since appeared at this site. I was hoping to someday cull these articles for information useful or interesting to me. However, the day is fast approaching when I will be returning to school and will have to remove my files from the system. Before that time I'd like to find some kind soul with the time and resources to organize and maintain an archive of these articles. They contain a great deal of useful information which could be organized for retrieval by subject matter or simply by article numbers. Such an archive could also serve as a reference collection for those occasional definitive answers to questions such as 'How do I get program Y to run on machine Z?', 'Has A been ported to a B?', and 'How do I do K using program/library L?'. If you have the time, resources, and interest in making these articles available for anonymous ftp and automated email retrieval, please contact me at one of the addresses (or by phone) below. DO NOT send requests for individual articles, specific information, or a copy of the newsgroup traffic; such requests will be ignored. I don't have the time to fulfill them and I wouldn't want to subject the net to the bandwidth involved. My hope is to find an individual who can make them available to everyone via automatic email and anonymous ftp. What I have: Articles 1-643+ of Comp.windows.news (.6 Meg compressed) as they appeared on linus (a backbone site). A few primitive programs to help separate and sort individual articles. An automated archive mailer for responding to email requests (untested by anyone at this site). What I want: A kind individual with the disk space to store these articles for anonymous ftp and the time to beg, borrow, or create an automated email archive for them. Until 8-26-88: Tony Davis (617) 271-2146 The MITRE Corporation MS A114 Burlington Road Bedford, MA 01730 U.S.A. linus!tony tony%linus@mitre-bedford.ARPA After 8-26-88: Still Tony Davis, but phone, address, and email will change: @cs.brown.edu From don@brillig.umd.edu Sat Jul 23 22:11:39 1988 Date: Sat, 23 Jul 88 22:11:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Changing Root Menu From: David Walker Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is it possible to attach a menu (brought up by the right mouse button) to a button. I'm writing an application where i want to change the appearance of a button interactively by bringing up a menu when a right mouse click on the button is performed. Has anyone done this and could give me advice on how to implement it. thanks, david walker davidw@prl.philips.co.uk From don@brillig.umd.edu Sat Jul 23 22:11:43 1988 Date: Sat, 23 Jul 88 22:11:43 EDT To: NeWS-makers@brillig.umd.edu Subject: status of NDE? From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Can someone please tell me the status of NDE? I would also like information on exactly what it is, e.g. how it differs from NeWS 1.1. Thanks in advance. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Sat Jul 23 22:12:17 1988 Date: Sat, 23 Jul 88 22:12:17 EDT To: NeWS-makers@brillig.umd.edu Subject: server class browser errors From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Often, but not always, I get the following output (line breaks thanks to psterm) on my console when I start up Bruce Schwartz's (Sun) server class browser. The program seems to continue normally though. The output usually goes away when I restart the server. I am running on a 3/160 with NeWS 1.1. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- Process: 0x1E4BF4 Error: typecheck Stack: dictionary[42] /FrameEventMgr event(0x273BF8) /PaintProcess marker 1 0 0 null 18 18 null 0 Executing: 'rlineto' At: {'dup' 0 'exch' 'rlineto' 'exch' 0 *'rlineto' 'neg' 0 'exch' 'rlineto' 'closepath'} In: {4 2 'roll' 'moveto' *rect} In: {4 `copy' *rectpath insetrect rectpath} In: {ItemFrame 0 0 ItemWidth ButtonSize *rectframe ButtonFillColor `setcolor' 'gsave' 'fill' 'grestore' ItemBorderColor `setcolor' 'eofill' ItemBorderColor 16 16 ItemWidth ArrowSize 'sub' 2 'div' ItemFrame PaintArrow ItemFrame 0 ItemHeight ButtonSize 'sub' ItemWidth ButtonSize rectframe ButtonFillColor `setcolor' 'gsave' 'fill' 'grestore' ItemBorderColor `setcolor' 'eofill' ItemBorderColor 16 -16 ItemWidth ArrowSize 'sub' 2 'div' ItemHeight ItemFrame 'sub' PaintArrow} In: {'exch' array{6} 'loop' 'get' *'exec'} In: {/PaintButtons SimpleScrollbar *supersend} In: {BarViewPercent 1 'gt' array{3} *'if'} In: {ItemCanvas 'setcanvas' PaintBar *PaintButtons PaintBox} In: {ItemBegin *PaintItem /ItemPaintedValue ItemValue 'store' ItemEnd} In: {PaintBuffer /paint VScrollbar *`send' /paint HScrollbar `send'} In: {ItemBegin *PaintItem /ItemPaintedValue ItemValue 'store' ItemEnd} In: {/paint 'exch' *`send' 'pause' 'cleartomark' 'mark'} In: {'mark' 'exch' array{6} *'forall' 'pop'} In: {PicArray *paintitems} In: {'gsave' FrameCanvas 'setcanvas' FixClient? array{2} 'if' PaintFrame? array{1} 'if' ClientCanvas 'null' 'ne' array{2} 'if' *PaintClient FixClient? array{4} 'if' /PaintProcess 'null' 'store' 'grestore'} In: {`newprocessgroup' *CallPaintProcs} From don@brillig.umd.edu Sat Jul 23 22:12:31 1988 Date: Sat, 23 Jul 88 22:12:31 EDT To: NeWS-makers@brillig.umd.edu Subject: Rotated text From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've just started playing around with NeWS and have already run into some things that don't seem to work right. The current problem has to do with rotated text. If I run the following program through psh: %! /Times-Roman findfont 72 scalefont setfont /inch {72 mul} def 4 inch 4 inch translate 0 inch 0 inch moveto (Hello!) show 45 rotate 0 inch 0 inch moveto (Hello!) show 45 rotate 0 inch 0 inch moveto (Hello!) show 45 rotate 0 inch 0 inch moveto (Hello!) show 45 rotate 0 inch 0 inch moveto (Hello!) show 45 rotate 0 inch 0 inch moveto (Hello!) show 45 rotate showpage I get the word "Hello!" printed at various angles, just as I would expect, but only if the window is fairly large. If I use a window smaller than about 1/3 the hight of the screen, some of the Hello!'s come out looking horrible, with missing letters, extra blotches and strange places, etc. Much worse than you would expect simply because of screen resolution problems. It seems that the font generation machinery can't deal with rotated coordinate systems very well. Am I doing something wrong, or is this a fundemental problem in the system? Another problem has to do with what looks like bugs in the terminal emulators. Right now I'm using emacs in a h19 (console) window. Various strange things keep happening. Sometimes (repeatably when I do "!ps" on the last line of the screen) it draws a single-pixel-wide horizontal line about a third of the way across the screen. When I suspend or quit emacs, I'm left with a ">" on the last line of the screen. Ocassionaly I get random pieces of text stuck in odd places on the screen, which C-L from emacs won't clear (but redisplay in the frame menu will). Could these just be termcap problems or is there really something wrong? Lastly, my initial impression is that NeWS is s-l-o-w compared to suntools. It seems to take forever for windows to open and resizing or moving existing windows feels real sluggish compared to suntools windows. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Sat Jul 23 22:13:06 1988 Date: Sat, 23 Jul 88 22:13:06 EDT To: NeWS-makers@brillig.umd.edu Subject: Applications and bugs in X11 and NeWS From: al@eos.arc.nasa.gov (Al Globus) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Please send me information about applications that are IN USE that were developed with X11 or NeWS. Please do not tell me about applications that will be ready REAL SOON NOW. I'm also not interested in systems stuff, only end user applications. I'd like to know what the application does, about how many users it has, and how well the X11 or NeWS performed in development and use. I'll summarize for the net. Thanks in advance. From don@brillig.umd.edu Sat Jul 23 22:13:06 1988 Date: Sat, 23 Jul 88 22:13:06 EDT To: NeWS-makers@brillig.umd.edu Subject: will news1.1 be getting any better? From: super!rminnich@uunet.uu.net (Ronald G Minnich) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) ok, i am using news1.1. I like the idea of news, and the basic system is sort of there i guess, but there are problems. For example: 1) i generate a large postscript file via dvi2ps. I try to preview it. the window goes away, and eventually the console window does too. No clue as to what went wrong. 2) psterm is awful! The emulations don't quite work, sometimes dumping escape sequences on the screen; also when i grow a window i don't want the characters to grow, i want more of them. Anybody got a better psterm? I can't believe it shipped this way. 3) i type ^C a few times at a running process and the window disappears. is this weird signal handling in news_server, or problems in psterm, or what? any clues? I really would rather go with news or at least make it my primary windows system, esp. now that there is an amiga port. Anybody got a better psterm? How much better will things get? In other words, are there fundamental problems with this whole approach, or is it just the old 'you got version 1' problem? Inquiring minds want to know. ron From don@brillig.umd.edu Sat Jul 23 22:13:30 1988 Date: Sat, 23 Jul 88 22:13:30 EDT To: NeWS-makers@brillig.umd.edu Subject: bug in the NeWS driver for GNU Emacs From: Chris Maio Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There's a bug in the NeWS driver for GNU Emacs that can cause the NeWS window to hang at startup under certain conditions. To fix it, add the line setpgrp (0, getpid ()); just before the call to init_sigio () near line 733 in NeWS.c. The entire NeWS driver kit is available via anonymous ftp from columbia.edu in pub/ps-emacs.tar.Z, or via mail (send a message containing the line "send NeWS emacs-support" to archive-server@columbia.edu). Chris From don@brillig.umd.edu Sat Jul 23 22:15:33 1988 Date: Sat, 23 Jul 88 22:15:33 EDT To: NeWS-makers@brillig.umd.edu Subject: Can't Keep a Good Clock Down. From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I always litter my screen with windows, and have to uncover my clock to read it. I decided I was going to write a clock which would be smart enough to keep itself visible. I thought it was going to be easy, but I found no good way to find a free spot on the root canvas. I stooped to traversing the canvas list, and doing rectangle list calculations in PostScript. If anyone has a better way please let me know. I cringe every time I see the clock change knowing what its doing. If there isn't a better way, others may find the "findplace" routine below usefull. -greg. Bugs: This is not an accurate clock, because it relies on a sleep in the shell script to feed the correct time to NeWS. ------------------------------------------------------------------------ #!/bin/sh DATECOMMAND="date +%H:%M" trap "echo systemdict /DigitalTime null put | psh;exit" 15 2 # Need to put a non null value in DigitalTime echo "systemdict /DigitalTime (`$DATECOMMAND`) put" | psh psh < array canvas dup /Mapped get { dup getcanvaslocation [ 3 1 roll gsave 3 index setcanvas clippath pathbbox 4 -2 roll pop pop grestore ] exch } if } def % % Get the Rectangles of all the Mapped&Opaque Canvases on the Display. % Each is left in an array [x y w h] on the stack % /getcanvasrects { framebuffer /TopCanvas get getcanvasrect nextcanvas } def /nextcanvas { /CanvasBelow get dup null ne { getcanvasrect nextcanvas} { pop } ifelse } def % % Find the largest rectangle unoccupied in the root canvas which will fit % the given width & heigth. Return false if it does not exist. % /findplace { % w h ==> x y w h bool /outrects [ getcanvasrects ] def /inrects [[ clippath pathbbox ]] def outrects { subtractfromall pause } forall /maxarea -1 def /keeper null def inrects { /r exch def r 2 get 2 index gt { r 3 get 1 index gt { r 2 get r 3 get mul dup maxarea gt { /maxarea exch store /keeper r store } { pop } ifelse } if } if } forall pause pop pop keeper null eq { false } { keeper aload pop true} ifelse } def % % Subtract this rect from all the inrects. % /subtractfromall { % [x y w h] ==> - /r exch def /inrects [ inrects { subtractrect } forall ] def } def % % Subtract rectangle r from the rectangle on the stack if it intersects % /subtractrect { % [x y w h] ==> 1-4 of [x y w h] dup r hitrect { r mungerect } if } def % % check if 2 rects intersect % /hitrect { % [x y w h] [x y w h] ==> bool /r2 exch def /r1 exch def r1 0 get r1 2 get add r2 0 get ge dup { pop r2 0 get r2 2 get add r1 0 get ge dup { pop r1 1 get r1 3 get add r2 1 get ge dup { pop r2 1 get r2 3 get add r1 1 get ge } if } if } if } def % % Subtract the top rectangle from the rectangle underneath % Rectangles have already been tested, they must intersect. % /mungerect { % [x y w h] [x y w h ] ==> 1-4 of [x y w h] /r2 exch def /r1 exch def % left piece r2 0 get r1 0 get sub dup 0 gt % w bool { r1 4 array copy dup 2 4 -1 roll put } % [x y w h] { pop } ifelse % right piece r1 0 get r1 2 get add r2 0 get r2 2 get add sub dup 0 gt % w bool { [ r2 0 get r2 2 get add r1 1 get 4 -1 roll r1 3 get ] } % [x y w h] { pop } ifelse % bottom piece r2 1 get r1 1 get sub dup 0 gt % h bool { r1 4 array copy dup 3 4 -1 roll put } % [x y w h] { pop } ifelse % top piece r1 1 get r1 3 get add r2 1 get r2 3 get add sub dup 0 gt % h bool { [ r1 0 get r2 1 get r2 3 get add r1 2 get 5 -1 roll ] } % [x y w h] { pop } ifelse } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% { DigitalTime null ne { /NewWidth DigitalTime stringwidth pop 10 add def NewWidth Height findplace { 2 div 3 -1 roll add 3 1 roll 2 div add % cy cx dup CX ne 2 index CY ne or % cy cy bool have we moved { erase } if /CX exch store /CY exch store } if /Width NewWidth store /Xpos CX Width 2 div sub def /Ypos CY Height 2 div sub def Xpos Ypos Width Height dup 4 div 5 1 roll rrectpath 0 setgray fill 1 setgray Xpos 5 add Ypos 10 add moveto DigitalTime show } { erase quit } ifelse .5 sleep } loop } fork GIVETONEWS while true do echo "systemdict /DigitalTime (`$DATECOMMAND`) put" | psh sleep 55 done From don@brillig.umd.edu Sat Jul 23 22:38:09 1988 Date: Sat, 23 Jul 88 22:38:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: will news1.1 be getting any better? From: ulysses!cjc@ucbvax.Berkeley.EDU (Chris Calabrese[rs]) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <551@super.ORG>, rminnich@super.UUCP writes: > ok, i am using news1.1. I like the idea of news, and the basic > system is sort of there i guess, but there are problems. For example: > 1) i generate a large postscript file via dvi2ps. I try to preview it. > the window goes away, and eventually the console window does too. > No clue as to what went wrong. We had to create our own previewer to view troff documents, mabee the problems are related. Mabee the file is just too complicated for the previewer. Are you using psview? > 2) psterm is awful! The emulations don't quite work, sometimes dumping > escape sequences on the screen; also when i grow a window i don't want > the characters to grow, i want more of them. Anybody got a better > psterm? I can't believe it shipped this way. Funny, I've never had psterm dump esc. sequences, except that the BSD terminal driver will display control sequences as ^, and the function keys generate control sequences - function keys which I always hit by mistake. As for the number of chatacters in the window changing, just think about the difficulty of implementing this in UNIX with respect to the philosophy of NeWS. Sure it been done (AT&T 630), but this way is easer. What do you want for free - no flames, while NeWS is anything but free, you have to admit that psterm is thrown into the deal for free - not that anyone would use NeWS without it :-). > 3) i type ^C a few times at a running process and the window disappears. > is this weird signal handling in news_server, or problems in psterm, > or what? any clues? ^C? What system are you running on? On a Sun? The window will disappear if you kill all processes associated with it, but ^C shouldn't do it (unless you have this mapped as the kill character). On the other hand if you mean <^>, not control c, if you're doing this in psh, it's a sure way to exit NeWS. -- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc From don@brillig.umd.edu Sat Jul 23 22:38:21 1988 Date: Sat, 23 Jul 88 22:38:21 EDT To: NeWS-makers@brillig.umd.edu Subject: fill bug From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The following program demonstrates a bug in the fill operator. When the window becomes slightly taller than wide, the right leg of the star gets truncated. The program executes correctly when the fill operator is replaced with stroke. I am running on a Sun 3/160 running SunOS 3.4. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- /star { clippath pathbbox scale pop pop 0.2 0 moveto 0.5 1 lineto 0.8 0 lineto 0 0.65 lineto 1 0.65 lineto closepath fill } def /win framebuffer /new DefaultWindow send def { /PaintClient { star } def } win send /reshapefromuser win send /map win send From don@brillig.umd.edu Sat Jul 23 22:39:07 1988 Date: Sat, 23 Jul 88 22:39:07 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS From: sg1q+@andrew.cmu.edu (Simon Peter Gatrall) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In reply to some talk about reading bitmaps from PS printers, John Gilmore (gnu@hoptoad.uucp) wrote about new PS features that will be available in NeWS >The three primitives in NeWS that Sam might have been talking about are >copyarea, writecanvas, and writescreen. Copyarea copies the region >outlined by the current path, to a position (deltax, deltay) from >its current position. Writecanvas writes the current canvas to a >file. Writescreen writes the current canvas to a file, including >bits from canvases that lie on top of the current canvas (e.g. a >screendump). There's also a readcanvas which reads in a rasterfile, >and an imagecanvas which images the bits from one canvas onto another. I'm very curious if copyarea will provide for mode of copying, ie xor, bic, etc. This would make it easy to achieve all kinds of neat effects that would be a pain to do now. The only problem with all of this bitmap stuff is that it starts to reduce the portability of the code. Oh well! -Simon Gatrall sg1q+@andrew.cmu.edu From don@brillig.umd.edu Sat Jul 23 22:39:26 1988 Date: Sat, 23 Jul 88 22:39:26 EDT To: NeWS-makers@brillig.umd.edu Subject: something better than psterm From: super!rminnich@uunet.uu.net (Ronald G Minnich) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) well i just latched on to nterm, but there is only one problem. I can out-type it. Otherwise it really is a nice job. Anybody know if this whole situation might improve someday? ron From don@brillig.umd.edu Sat Jul 23 22:39:58 1988 Date: Sat, 23 Jul 88 22:39:58 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS for the Macintosh (Summary) From: mcvax!enea!kth!sics!hans@uunet.uu.net (Hans Eriksson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There are three companies doing NeWS for Macintoshes today: Grasshopper Group Hugh Daniel 212 Clayton Street San Fransisco CA 94117 +1 408 266-4783 grasshopper@toad.com They do NeWS for A/UX on Macintosh. Some excerpts from their brouschure: * Works with NeWS servers from SUN, Silicon Graphics, Whitechapel, Acorn * OPENLook will run under NeWS * "Complete client source is, of course, included" * run under A/UX 1.0 with A/UX supported monitors. minimum 4MB RAM and 5MB disk is recommended. * $225 for release 1.1.01 extra machine on the same network $150 extra manual $25 Wedge Computer Dick Bonsai 2 Winter Street Waltham, MA 02154 +1 617 891-1313 They do NeWS for MacOS. I called them and they said they have "released" a beta-version with communicates with a SUN (yes it must be a SUN) via the seral line (no TCP/IP or netting so far). They are considering a TCP/IP version by the end of the year. The big release of the seral-line-version should be out by the end of this summer. Liason 42 Robert Esbury Australia +61 612 922-7099 They do NeWS for MacOS. Due to time differenses (+9h) I have not been able to reach them. maybe someone else on the net (in Australia!) could give it a try? Unfortunately, no luck so far for me who want to run NeWS on MacOS on TCP/IP to our SUNs. Unless Liason 42 show up to be something... /hans -- Hans Eriksson Swedish Institute of Computer Science, Box 1263, S-164 28 KISTA, Sweden Tel: +46 8 752 15 27 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30 Internet (uucp): hans@sics.se EAN: hans@sics.sunet From don@brillig.umd.edu Sat Jul 23 22:39:58 1988 Date: Sat, 23 Jul 88 22:39:58 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: will news1.1 be getting any better? From: gorodish!guy@sun.com (Guy Harris) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > As for the number of chatacters in the window changing, just think about > the difficulty of implementing this in UNIX with respect to the > philosophy of NeWS. Sure it been done (AT&T 630), but this way is > easer. That's no excuse. Using SunView's "shelltool" has taught me that changing the number of characters is right, and changing their size is wrong, in typical cases. I suspect people who use X's "xterm" would agree. Saying "it's cheap and easy to resize the characters, and not so cheap and easy to change the number of characters, in NeWS" doesn't mean "psterm" is doing the right thing. UNIX has nothing to do with it here; it certainly has no connection with "the philosophy of NeWS" in this context. All UNIX needs to know about it is that the number of characters on the "terminal"s screen has changed, and you can do that with SIGWINCH and the TIOCGWINSZ "ioctl" (it's there in SunOS since 3.2, along with TIOCSWINSZ, although we forgot to document it - "fixed in 4.0"). UNIX systems that don't have those calls should pick them up, whether for X11, NeWS, or any other window system. I think "nterm" comes with 1.1. That does things right; if you make the window taller, you get more characters on the screen. It may not be documented (I don't know), but I think it's there. From don@brillig.umd.edu Sat Jul 23 22:40:33 1988 Date: Sat, 23 Jul 88 22:40:33 EDT To: NeWS-makers@brillig.umd.edu Subject: Yet Another Square Limit From: mcvax!unido!ecrcvax!andy@uunet.uu.net (Andrew Dwelly) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Just before last Christmas, John Pratt posted a postscript program to draw an accurate copy of Escher's square limit program (a la Henderson), for various reasons the program did not work under NeWS 1.0 (bugs, missing primitives etc.). What follows is a version that works under NeWS 1.1 John doesn't have access to the net currently, so I am posting, and collecting replies and comments which I will forward to him. Andy ------------------------------------------------------------------------------ #!/usr/NeWS/bin/psh % TRIANGULAR-DIVISION % Copyright John M. Pratt. ECRC Arabellastr 17, D8000 Munich 81 % -- With acknowledgements to M.C.Escher. % Produces a facsimile of "Square Limit. % Executes under psh, adapts to window size, and provides menu for rotation % Prepared as a exercise of graphic transformation, and curve drawing under NeWS /Fishdict 200 dict def Fishdict begin /Helvetica-Bold findfont 0.5 scalefont setfont % COLOUR CONTROLS /Colourdisplay false def /Parity 0 def /Swap {/Parity 0.5 Parity sub def} def %Parity is 0 or 0.5 /Colour 0 def %colour variable /Dark {/Colour Parity def Colour Set-Colour} def /Light {/Colour 0.5 Parity sub def Colour Set-Colour} def /White {/Colour 1 def Set-White} def /Comp {Colour 1 ne {Set-White} {Parity Set-Colour} ifelse} def /De-Comp{Colour 1 eq {Set-White} {Colour Set-Colour} ifelse} def /Set-Colour { Colourdisplay {1 0.5 sethsbcolor} {setgray} ifelse} def /Set-White { Colourdisplay {0 0 1 sethsbcolor} {1 setgray} ifelse } def % CONSTANTS AND PRECALCULATED TRANSFORMS /cm {28.35 mul} def /HeadMatrix [-0.5 0.5 0.5 0.5 0 10] def % 0 10 translate -Invroot2 Invroot2 scale 45 rotate /UpheadMatrix [-1 1 1 1 -10 -10] def % -45 rotate Root2 neg Root2 scale 0 -10 translate /TailMatrix [-0.5 -0.5 -0.5 0.5 0 10] def % 0 10 translate -Invroot2 Invroot2 scale -45 rotate /UptailMatrix [-1 -1 -1 1 10 -10] def % 45 rotate Root2 -Root2 scale 0 -10 translate /Op1 [-1 0 0 -1 0 20] def %matrix for duple opposite %0 10 translate 180 rotate 0 -10 translate /Head-to-headMatrix [0.5 -0.5 -0.5 -0.5 10 20] def %Op1 HeadMatrix matrix concatmatrix /Transform { 3 dict begin %simulates -- X Y matrix transform /Mat exch def /Y exch def /X exch def Mat 0 get X mul Mat 2 get Y mul Mat 4 get add add %X` on stack Mat 1 get X mul Mat 3 get Y mul Mat 5 get add add %Y` on stack end } def /Downtail {TailMatrix concat} def %apply to CTM /Op {Op1 concat} def %apply to CTM /DwnR {HeadMatrix Transform} def %applies Head matrix to point /UpR {UpheadMatrix Transform} def %applies UpHead matrix to point /DwnL {TailMatrix Transform} def %applies Tail matrix to point /UpL {UptailMatrix Transform} def %applies UpTail matrix to point /Opp {Op1 Transform} def %applies opposite matrix to point /Qflip {exch neg exch} def %Flip by X, X/Y point 180 /Qrot90 {exch neg} def %rotate X/Y point -90 /Qrotm90 {neg exch } def %rotate X/Y point 90 /Qxtran {3 -1 roll add exch} def %adds top to 3rd, X /* {aload pop} bind def % POINTS defined as [X Y] /A [10 10] def /A1 [9 8] def /A2 [7.5 6.2] def /Ah [A * -1 Qxtran -0.5 add ] def /B [6 5.6] def /B1 [4.8 5] def /B2 [2.2 4.5] def /C [0 5] def /C1 [-1.1 5.3] def /C2 [-4.2 6] def /D [B * Qrotm90] def /D1 [A1 * Qrotm90] def /D2 [A2 * Qrotm90] def /E [A * Qrotm90] def /E1 [A1 * DwnL] def /E2 [A2 * DwnL] def /Eh [Ah * Qflip] def /F [B * DwnL] def /F1 [F * 2 Qxtran 2 sub] def /F2 [-2 7] def /G [0 7.6] def /G1 [2 8.2] def /G2 [3.2 9.5 ] def /Gop [G * Opp] def /GuP [G * UpL] def /H [5.1 10] def /H1 [6.5 10.5] def /H2 [8 10.5] def /I1 [0 4] def /I2 [0 2] def /J [0 0] def /J1 [3 0] def /J2 [3 0] def /K [C * Qrot90] def /L [C * DwnR] def /L1 [C1 * DwnR] def /L2 [4.7 11] def /N [0 10.7] def /N1 [I1 * DwnR] def /N2 [I2 * DwnR] def /Nl [N * UpL] def /Nr [N * UpR] def /P [L * Qflip] def /Q1 [4.1 12.4] def /Q2 [2 13.1] def /Sq2 {nm Pupil} def % CURVES defined as [Point Point Point] /a [A1 * A2 * B * ] def /b [B2 * B1 * B * ] def /c [C1 * C2 * D * ] def /d [D2 * D1 * E * ] def /e [E1 * E2 * F * ] def /f [F1 * F2 * G * ] def /ft [F1 * UpL F2 * UpL G * UpL] def /g [G2 * G1 * G * ] def /h [H1 * H2 * A * ] def /ho [H2 * Opp H1 * Opp H * Opp] def /hu [H1 * UpR H2 * UpR A * UpR ] def /i [I2 * I1 * C * ] def /j [J2 * J1 * J * ] def /k [C2 * Qrot90 C1 * Qrot90 K * ] def /l [L1 * L2 * H * ] def /lu [L1 * UpR L2 * UpR H * UpR ] def /n [N2 * N1 * L * ] def /nt [I2 * I1 * C * ] def /nm (J M P) def /p [I2 * I1 * C * ] def /pr [I1 * Qrot90 I2 * Qrot90 Nr * ] def /q [Q2 * Q1 * H * ] def /qo [Q1 * Opp Q2 * Opp G * ] def % OUTLINE GROUPS defined as [curve curve .. arraylength] /OutA [f * e * d * c * i * j * k * a * 8] def /OutB [f * e * hu * lu * nt * pr * k * a * 8] def /OutC [qo * ho * hu * lu * nt * pr * k * a * 8] def /OutD [qo * ho * d * c * p * 5] def /OutE [qo * ho * d * c * i * j * k * a * 8] def /OutF [h * q * 2] def /OutG [ft * a * 2] def /OutH [f * e * d * c * p * 5] def /OutI [h * l * n * 3] def /Out1s [A * E * D * C * J * K * B * 7] def %used for lines /Out2s [A * E * H * UpR C * Nr * K * B * 7] def /Out3s [A * E * D * C * Nl * G * UpL B * 7] def % PROCEDURES /Fish1 {newpath %Convex 90, quadwing, concave 45, Triwing 1 A * moveto OutA * {curveto} repeat N * lineto OutI * {curveto} repeat fill } def /Fish2 {Colour 1 eq {} { %dont draw if white newpath %Convex 45, TriWing2, concave 45, Triwing 1 A * moveto OutB * {curveto} repeat N * lineto OutI * {curveto} repeat fill }ifelse } def /Fish3 {newpath %Convex 90, TriWing3, concave 45, Triwing 1 A * moveto OutG * {curveto} repeat Nl * lineto OutH * {curveto} repeat N * lineto OutI * {curveto} repeat fill } def /Fish4 {Colour 1 eq {} { newpath %Convex 45, Triwing2, concave 180, Duplewing A * moveto OutC * {curveto} repeat Gop * lineto OutF * {curveto} repeat fill }ifelse } def /Fish5 {newpath %Convex 90, Triwing3, concave 180, Duplewing A * moveto OutG * {curveto} repeat Nl * lineto OutD * {curveto} repeat Gop * lineto OutF * {curveto} repeat fill } def /Fish6 {Colour 1 eq {} { newpath %Convex 90, quad, concave 180, Duplewing A * moveto OutE * {curveto} repeat Gop * lineto OutF * {curveto} repeat fill }ifelse } def /Fish1s {newpath %Straight fish with Quadwing for border A * moveto Out1s * {lineto} repeat fill} def /Fish2s {newpath %Straight fish with Triwing1 for border A * moveto Out2s * {lineto} repeat fill} def /Fish3s {newpath %Straight fish with Triwing2 for border A * moveto Out3s * {lineto} repeat fill} def /Spine {newpath %Fishcentre line Ah * moveto C * 0.3 add C * -0.6 Qxtran 0.3 add Eh * curveto Eh * -0.05 add lineto C * -0.3 add -0.6 Qxtran C * -0.3 add Ah * -0.05 add curveto Ah * lineto gsave fill grestore } def /Tailribs {0.15 setlinewidth newpath -6 9 moveto -5 8 -4 7.3 -2.4 6.9 curveto stroke newpath -5.5 6.7 moveto -4.5 6.3 -3.5 6.2 -2.3 6 curveto stroke newpath -2.2 7.1 moveto -2.4 6.7 -2.4 6.2 -2.2 5.8 curveto stroke} def /EyeshapeL { -0.4 0.8 moveto 0.7 1.3 1.5 1.2 2.5 0.8 curveto 1.9 0 1.1 -0.4 0.1 -0.9 curveto 0 -0.2 -0.1 0.3 -0.4 0.8 curveto } def /EyeshapeR { 0 0.8 moveto 1.4 1.6 1.9 1.6 2.6 1.5 curveto 2.4 0.8 1.6 0 0.1 -0.8 curveto 0.1 -0.3 0.1 0.3 0 0.8 curveto } def /Pupil {-3 0.2 moveto White show 0 0 moveto} def /WhiteEye { 0.01 setlinewidth gsave 5.9 6.7 translate EyeshapeR stroke 0.2 0 translate 0.4 0.4 scale EyeshapeR fill grestore gsave 5.6 8.9 translate EyeshapeL stroke 0.2 0.1 translate 0.4 0.4 scale EyeshapeL fill grestore }def /DarkEye {gsave 5.9 6.7 translate EyeshapeR 0.2 0 translate 0.4 0.4 scale EyeshapeR eofill grestore gsave 5.6 8.9 translate EyeshapeL 0.2 0.1 translate 0.4 0.4 scale EyeshapeL eofill grestore} def /Bodylines {Spine Tailribs Colour 1 eq {WhiteEye} {DarkEye} ifelse} def /Ribl {newpath L * moveto l * curveto stroke } def /Ribk {newpath B * moveto k * curveto stroke }def /Ribf {newpath B * moveto ft * curveto stroke } def /Ribb {newpath C * moveto b * curveto stroke } def /Ribg {newpath H * moveto g * curveto stroke} def % WING Outlines for Clip Paths /QuadW {C * moveto b * curveto K * lineto J * lineto closepath}def /TriW1 { %wing on Hypoteneuse for triple H * moveto g * curveto N * lineto L * lineto closepath } def /TriW2 { %wing on head side for triple C * moveto b * curveto K * lineto Nr * lineto closepath } def /TriW3 { %wing on tail side for triple C * moveto b * curveto GuP * lineto Nl * lineto closepath } def /DupleW { %wing for duple H * moveto g * curveto Gop * lineto q * curveto closepath } def /Wingribs %stack WingRib, Translate-offset, Translate-inc, Y-Rotatione-inc {4 copy 4 copy %copy parameters given for 3 ribs 0.15 setlinewidth 0 1 2 {gsave %stack Wr To Ti Sy Loopv dup dup 0.25 mul 0.75 exch sub %stack ----Sy Lv Lv Sx exch 4 -1 roll mul 0.95 exch sub %stack ---To Ti Lv Sx Sy scale %stack --To Ti Lv mul add 0 exch translate %stack --Wr cvx exec %execute WingRibxx grestore } for %stack Sr } def /Quadribs {gsave QuadW clip newpath /Ribk 0.5 0 0 Wingribs grestore 0.2 setlinewidth Ribb } def /Triribs1 {gsave TriW1 clip newpath /Ribl -0.5 0 0.04 Wingribs grestore 0.2 setlinewidth Ribg} def /Triribs2 {gsave TriW2 clip newpath /Ribk 0.5 0.1 0 Wingribs grestore 0.2 setlinewidth Ribb } def /Triribs3 {gsave TriW3 clip newpath /Ribf 0.8 0.6 0.03 Wingribs grestore 0.2 setlinewidth Ribb }def /Dupribs {gsave DupleW clip newpath /Ribl -0.5 0 0.04 Wingribs grestore 0.2 setlinewidth Ribg }def /Decor1 {Comp Bodylines Quadribs Triribs1 De-Comp} def /Decor2 {Comp Bodylines Triribs2 Triribs1 De-Comp} def /Decor3 {Comp Bodylines Triribs3 Triribs1 De-Comp} def /Decor4 {Comp Bodylines Triribs2 Dupribs De-Comp} def /Decor5 {Comp Bodylines Triribs3 Dupribs De-Comp} def /Decor6 {Comp Bodylines Quadribs Dupribs De-Comp} def /Decors {Comp Spine De-Comp} def %STRUCTURAL PROCEDURES /Sq1 {4 { Dark Fish1 Decor1 Swap pause -90 rotate } repeat gsave Downtail 4 { Light Fish3 Decor3 20 0 translate White Fish2 Decor2 -90 rotate Swap pause } repeat grestore } def /Sq8 { gsave -15 15 translate 0.5 0.5 scale 4 { Dark Fish1 Decor1 -90 rotate Light Fish6 Decor6 Op White Fish4 Decor4 -90 rotate Dark Fish3 Decor3 20 0 translate Fish2 Decor2 -90 rotate Light Fish5 Decor5 Op White Fish6 Decor6 -90 rotate Dark Fish1 Decor1 Swap pause -90 rotate }repeat Downtail 4 { Light Swap Fish3 Decor3 20 0 translate White Fish2 Decor2 -90 rotate 3 {Light Fish3 Decor3 20 20 translate White 90 rotate Fish2 Decor2 -90 rotate pause }repeat }repeat grestore } def /Sq20 { gsave -22.5 22.5 translate 0.25 0.25 scale 4 { Dark Fish1 Decor1 -90 rotate Light Fish6 Decor6 Op 4{ White Fish4 Decor4 -90 rotate Dark Fish3 Decor3 20 0 translate Fish2 Decor2 -90 rotate Light Fish5 Decor5 Op } repeat White Fish6 Decor6 -90 rotate Dark Fish1 Decor1 Swap pause -90 rotate }repeat Downtail 4 { Light Swap Fish3 Decor3 20 0 translate White Fish2 Decor2 -90 rotate 9 {Light Fish3 Decor3 20 20 translate White 90 rotate Fish2 Decor2 -90 rotate pause }repeat }repeat grestore } def /Sq44 {gsave -26.25 26.25 translate 0.125 0.125 scale 4 { Dark Fish1 Decors -90 rotate Light Fish6 Decors Op 10{White Fish4 Decors -90 rotate Dark Fish3 Decors 20 0 translate Fish2 Decors -90 rotate Light Fish5 Decors Op } repeat White Fish6 Decors -90 rotate Dark Fish1 Decors Swap pause -90 rotate }repeat Downtail 4 { Light Swap Fish3 Decors 20 0 translate White Fish2 Decors -90 rotate 21 {Light Fish3 Decors 20 20 translate White 90 rotate Fish2 Decors -90 rotate pause }repeat }repeat grestore } def /Sq92 {gsave -28.125 28.125 translate 0.0625 0.0625 scale 4 { Dark Fish1 -90 rotate Light Fish6 Op 22{ White Fish4 -90 rotate Dark Fish3 20 0 translate Fish2 -90 rotate Light Fish5 Op } repeat White Fish6 -90 rotate Dark Fish1 Swap pause -90 rotate }repeat Downtail 4 { Light Swap Fish3 20 0 translate White Fish2 -90 rotate 45 {Light Fish3 20 20 translate White 90 rotate Fish2 -90 rotate pause }repeat }repeat grestore } def /Sq188 {gsave -29.1125 29.1125 translate 0.03125 0.03125 scale 4 { Dark Fish1s -90 rotate Light Fish1s Op 46{ White Fish2s -90 rotate Dark Fish3s 20 0 translate Fish2s -90 rotate Light Fish3s Op } repeat White Fish1s -90 rotate Dark Fish1s Swap pause -90 rotate }repeat grestore } def /Fishes { RotateFactor rotate 0.05 setlinewidth 1 setflat 1 setlinecap Colourdisplay {0 0 1 hsbcolor} {1} ifelse fillcanvas gsave Sq1 Sq2 Sq8 Sq20 Sq44 Sq92 Sq188 grestore } def %end of Fishes /Calcscale {initclip clippath pathbbox 2 copy 2 div exch 2 div exch translate 60 div exch 60 div exch scale pop pop} def /main{ /RotateFactor 0 def /Rotation {/RotateFactor currentkey cvi store /paintclient win send} def /win framebuffer /new DefaultWindow send def {/FrameLabel(Square-Limit) def /PaintClient{gsave Calcscale Fishes grestore} def /PaintIcon {gsave 3 3 scale 10 0 translate Fish1 Decor1 grestore} def /ClientMenu[(0) (10) (30) (45) (60) (90)][ {Rotation} ] /new DefaultMenu send def } win send ColorDisplay? /Colourdisplay exch def %defined in init.ps /reshapefromuser win send /map win send }def main end %of dict ------------------------------------------------------------------------------ Andrew Dwelly E.C.R.C. UUCP: mcvax!unido!ecrcvax!andy pyramid!ecrcvax!andy ArabellaStrasse 17 CSNET:ecrcvax!andy@Germany.CSNET D-8000 Muenchen 81, West Germany UUCP Domain: andy@ecrcvax.UUCP [Bump, Crash ...... Listen; who swears ?. Christopher Robin has fallen down stairs.] From don@brillig.umd.edu Sat Jul 23 22:41:11 1988 Date: Sat, 23 Jul 88 22:41:11 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS's use of floating point From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) How much use does NeWS (we're running version 1.1) make of floating point? A lot of the basic PostScript stuff like scale and rotate and scalefont seem like they almost have to be floating point intensive. Some of the stuff applications do, like the backgammon game calculating the arcs along which men are moved, also seem like they must be done with floating point. The reason I ask is because while NeWS comes with both 68010 and 68020 versions of the server, it doesn't come with versions for the various floating point hardware configurations. I've got a 68881 in my workstation; I wonder how much faster news_server would run if it was compiled with the -f68881 flag. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Sat Jul 23 22:41:53 1988 Date: Sat, 23 Jul 88 22:41:53 EDT To: NeWS-makers@brillig.umd.edu Subject: A mail popup utility for NeWS From: siegel@hc.dspo.gov (josh Siegel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I am posting this since I have gotten several requests... This pops up a little bubble on the screen whenever you get new mail (for those mailaholics)... you put something similer to: ,|" / " in your ".forward" For example, this is my .forward: siegel,|"/vc/siegel/games/mail/mail-forward sledge /siegel 2000" also, put a : "/UserName / def" in your .NeWSrc or your local user.ps or whatever your individual postscript initialization files are.... For example, mine contains: "/UserName /siegel def" Send comments and suggestions back to me.. --Josh Siegel ---- #include #include #include #include #include main (argc, argv) int argc; char *argv[]; { char from[255], subject[255], cc[255], to[255], tmp[255], buff[255]; int s, n; if (argc != 3 && argc != 4) exit (0); bzero (cc, sizeof (cc)); strcpy (from, "From: \\(null\\)\n"); strcpy (subject, "Subject: \\(null\\)\n"); strcpy (to, "To: \\(null\\)\n"); while (fgets (buff, 255, stdin) != NULL) { if (!strncmp (buff, "From:", 5)) strcpy (from, buff); if (!strncmp (buff, "Cc:", 3)) strcpy (cc, buff); if (!strncmp (buff, "To:", 3)) strcpy (to, buff); if (!strncmp (buff, "Subject:", 8)) strcpy (subject, buff); } if (argc == 4) s = phone (atoi (argv[3]), argv[1]); else s = phone (2000, argv[1]); if (s < 0) exit (0); write (s, "UserName ==\n", 12); read (s, buff, sizeof (buff)); if (strncmp (buff, argv[2], strlen (argv[2]))) exit (0); srandom (time ((long *) 0)); if (cc[0]) sprintf (tmp, "(%s) (%s) (%s) (%s)", from, to, subject, cc); else sprintf (tmp, "(%s) (%s) (%s)", from, to, subject); sprintf (buff, "%d %d [%s] popmsg pop\n", random () % 400, (random () % 700) + 100, tmp); n = strlen (buff); write (s, buff, n); close (s); exit (0); } phone (service, host) int service; char *host; { struct sockaddr_in sin; struct hostent *hp; int s; bzero ((char *) &sin, sizeof (sin)); sin.sin_port = htons (service); hp = gethostbyname (host); if (hp == NULL) return (-1); bcopy (hp->h_addr, (char *) &sin.sin_addr, hp->h_length); sin.sin_family = hp->h_addrtype; s = socket (AF_INET, SOCK_STREAM, 0); if (s < 0) return (-1); if (connect (s, &sin, sizeof (sin)) < 0) return (-1); return (s); } -- Josh Siegel (siegel@hc.dspo.gov) I like using a C-47A "puff dragon" to go shooting beer cans with. From don@brillig.umd.edu Sun Jul 24 17:51:53 1988 Date: Sun, 24 Jul 88 17:51:53 EDT To: NeWS-makers@brillig.umd.edu Subject: CAD user-interface From: mcvax!unido!infko!uro@uunet.uu.net (Uwe und Roland) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We are going to start a project to develop an "intelligent" CAD-System for use on a Sun-WS. On designing the user-interface, we are looking for literature, technical reports, etc. to get more informated on: - the design and specification of CAD user-interfaces in general - especially: the use of Sun-NeWS (V 1.1) to realize a CAD user-interface (or any other user-interface to comp. graphics applications) If you have any hints, please e-mail, we'll summarize to the net. --- Roland Berling, Universitaet Koblenz (EWH) Informatik Rheinau 3-4 D-5400 Koblenz (West Germany) UUCP: ..!unido!infko!uro uro@infko.UUCP From don@brillig.umd.edu Sun Jul 24 18:07:10 1988 Date: Sun, 24 Jul 88 18:07:10 EDT To: NeWS-makers@brillig.umd.edu Subject: The NeWS Book From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Springer Verlag will soon be publishing a book about NeWS, called "The NeWS Book." It's mentioned in the Springer Verlag ad on the back cover of July '88 CACM. The blurb: "... The NeWS Book, by Arden, Gosling, and Rosenthal (forthcoming in 1988). Developed by Sun Microsystems and distributed as part of a standard UNIX package, NeWS provides a uniquely extensible interpretive programming environment for application developers in a networked graphics and window systems environment. This is the book that will enable you to make full use of this revolutionary system." -Don From don@brillig.umd.edu Sun Jul 24 18:23:33 1988 Date: Sun, 24 Jul 88 18:23:33 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: psterm scaling characters From: Robert Scheifler Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: Sat, 23 Jul 88 22:38:09 EDT From: ulysses!cjc@ucbvax.Berkeley.EDU (Chris Calabrese[rs]) As for the number of chatacters in the window changing, just think about the difficulty of implementing this in UNIX with respect to the philosophy of NeWS. Sure it been done (AT&T 630), but this way is easer. In chatting with the original author of psterm, the motivation for this behavior was not because it was simpler. At the time, he was looking for a way of testing the font scaling code, and he figured having people in-house creating random-sized windows would be one good way. Of course, at that time psterm was not intended as a product. From don@brillig.umd.edu Sun Jul 24 18:24:15 1988 Date: Sun, 24 Jul 88 18:24:15 EDT To: NeWS-makers@brillig.umd.edu Subject: is news loosing the battle? From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) First of all, let me point out that I think the question "Is NeWS loosing the battle?" is totally meaningless. Right up there with "Is NeWS tighting the war?" sic(-; The X11/NeWS merge will be widely available as a standard part of AT&T Unix. A battle between X and NeWS is as pointless as a battle between VT100 escape sequences and Tektronix control codes! They're both widely supported and emulated standards, each one best for certain applications, and neither has destroyed the other. Terminal emulators such as xterm support both standards, and I don't think DEC is out to discourage people from using xterm's Tektronix features. Date: Thu, 7 Jul 88 19:52:37 EDT From: hpda!hp-sde!hpfcdc!hpfclp!diamant@ucbvax.Berkeley.EDU (John Diamant) Non-rectangular windows is "gee whiz," but frankly, I don't care about that at all. Other than having round clocks, I just don't see this as a big deal. Sheez, some people are so stuck in the rut of rectangular windows, that when I tell them that NeWS has arbitrarily shaped windows, they assume I mean arbitrary rectangles ... Non rectangular windows are invaluable for many applications! It's the kind of thing that once you're used to, you'll never want to do without! The shape of a NeWS window ("canvas") is defined by a PostScript path. They can have lines, arcs, bezier curves, and conic splines as edges. They can even have holes in them, and disconnected regions! You can use either the even-odd or the zero winding rule to define what's inside and outside the path. The shape of a canvas influences the clipping of graphical output, and the distribution of input events. Each canvas has its own default coordinate system, the one that was in effect when it was reshaped. Canvases can be used as arbitrarily shaped targets. NeWS processes can receive input events whenever the mouse enters, leaves, clicks, or moves around in a canvas, and event coordinates are reported in terms of the process's current coordinate system. NeWS canvases are natural to use as animated "sprites", using lightweight PostScript processes to periodically blink, move, or paint them. (This is a great way to implement a cursor, or a space invader!) Transparent canvases are like opaque canvases in that they have arbitrary shapes and coordinate systems, effecting clipping and event distribution, except that they don't have their own image -- the image of their (first opaque) parent canvas shows through. Graphical output on a transparent canvas gets clipped to its shape, and drawn through into the parent's image. A hypermedia browser that I'm porting to NeWS for Ben Shneiderman, called HyperTIES, displays documents containing text and graphics with "embedded menus" of links to other documents. Embedded menu buttons are overlayed on top of text and graphics, and highlight when you move the cursor into them. In NeWS HyperTIES, the embedded menu buttons are simply implemented using transparent canvases. Text buttons use canvases overlayed on top of words in text, shaped like rounded rectangles. Graphical buttons use canvases overlayed on top of parts of pictures, shaped like the Hubble Space Telescope, a Faint Object Spectrograph, a circle, a pie slice, Bill Joy's head, a rabbit, a mouse pad, or whatever part of a picture you want to link to some document! When the mouse moves into a button, there is some feedback to show that it can be pressed, such as a color change, animation, or a pop-up cut-out magnified image cookie with a shadow behind it. (Just map a pre-fab opaque canvas with the translated and scaled image and target shape!) The ability to have interpretive toolkits which can be swapped is useful, but there are other ways to accomplish this in X as well (using dynamic loading, for instance). There is a big difference between dynamically loaded toolkits, and toolkits written in an interactive interpretive environment. With NeWS, I can interactively debug PostScript code running in the server -- looking and and changing the values of variables, calling and redefining functions, setting breakpoints, examining and changing the execution state of lightweight NeWS processes, etc... The NeWS "Lite" user interface toolkit is based on Owen Densmore's object oriented programming package, a smooth fitting extension to the PostScript language. With Bruce Schwartz's class browser, you can interactively examine all the classes defined in the server. Toolkit hacking is *easy* to do in NeWS. For HyperTIES, I extended the NeWS "Lite" toolkit by making a Target subclass of Item, that highlights when the mouse moves into it. I then made subclasses of Target to do the kinds of highlighting I wanted for my application. When HyperTIES is run, it checks to see if the Target classes are defined in the server, and loads them in if they're not. I can hack on the pieces of the application interface and toolkit, reload 'em into NeWS, test them out, fix a bug, load 'em back up and try it out again, tweak a variable, play around some more, stick in some debugging statements, frob it until I get that funny condition, scrutinize a broken process's state, reach inside and redefine a function, continue the process, frob it mercilessly, sigh in relief, and then update the source code, iteration after iteration after iteration, all without restarting the NeWS client or recompiling anything at all! Probably the most significant difference between X and NeWS is the traffic between client and server. No, EXTENSIBILITY is the most significant difference between X and NeWS. Low client/server traffic is just one of the many advantages that comes from it. X is just not extensible the way NeWS is. An X11 client can ask the server if certain predefined extensions are available, and if they're not, the client can either give up or do without. NeWS extensibility is much more finer grained and application specific -- a client can load its own extensions into the server, teaching NeWS to communicate in whatever protocol is most convenient for the application. It's a dynamic protocol -- clients can make local or global extensions, on the fly! For example, when a CAD program needs to draw a particular integrated circuit for the first time, it could send the IC's name and a function to draw it, then extend the protocol by associating a token with the function. From then on, it can just send the token to draw the IC. First of all, Scheifler wrote a paper about why the traffic breakdown wouldn't be as good as the claims (because the communication for even simple operations like menus would be higher than expected). I don't think that's true. With NeWS, all the clients share the same menu code, which runs entirely in the server. There is no network traffic at all involved with making a menu selection in NeWS. The only communication that is required is informing the client of the results of the selection (which could be as terse as a one byte token -- who needs fixed size packets?). In many cases, the selection can be acted upon entirely in the server! One of the big advantages NeWS has over X in network utilization is that for many applications, repainting a window can be handled entirely in the server. Instead of the client responding to every damage event (when the window is exposed or resized), it sends to the server a program to paint the display (or a display list, and a program to interpret it), which is executed whenever needed. Second of all, it doesn't really matter! I'm a network administrator and I have some experience on this subject. Lan bandwidth is rarely the bottleneck in communications between two machines. We run diskless (including remote swap), remote X, etc. and the volume of traffic is just never that high (typically under 5% of lan utilization). That sure doesn't agree with the numbers I've heard for the % of lan utilization on nets with with diskless workstations. The way diskless clients eat up the net severely limits the number of them that can coexist on one piece of cable. I think network utilization is a very important factor. I want to be able to run clients over the Internet, and over the phone! Also, most X servers run with Unix Domain sockets when running locally, so lan overhead isn't a big issue. When you run clients locally, paging and context switching become big issues. (Are you paging over the net? Even more fun!) With X, if you run your window manager locally, and it rubber-bands a rectangle when you resize your window, there must be a Unix process context switch from the server to the window manager, and back to the server, every time you move the mouse. It's a big win to have the window manager running in the same Unix process as the server. No frantic context switching, and the WM does not need to keep its own copy of all those data structures that live in the server. With NeWS, switching to a new window manager is as easy as redefining the DefaultWindow class. With X11/NeWS, NeWS window managers can manage X windows, too! The only issue that remains is the performance in terms of throughput on the lan. We are already at the point where lan performance is within the same ballpark as disk transfer rates, so it isn't that big a deal, and we're getting faster lan technology too. Disk transfer rates just don't cut it when compared to memory transfer rates. We're getting faster and faster processors, as well! Do you really think that advances in lan speed are going to be able to keep up with advances in processor speed? I doubt it! -Don Don Hopkins don@brillig.umd.edu ...!uunet!mimsy!don From don@brillig.umd.edu Sun Jul 24 23:51:50 1988 Date: Sun, 24 Jul 88 23:51:50 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS's use of floating point From: frame!gergle!greg@Sun.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >I wonder how much faster news_server would run if it was >compiled with the -f68881 flag. No faster. It uses fixed point arithmetic. There are different assembler files for the different CPU's. -greg. From don@brillig.umd.edu Mon Jul 25 09:09:39 1988 Date: Mon, 25 Jul 88 09:09:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: will news1.1 be getting any better? From: aramis.rutgers.edu!porthos.rutgers.edu!gaynor@rutgers.edu (Silver) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The lack of a good terminal emulator is pretty much all that makes me hesitate to bring up NeWS instead of Sunview (X? Feh.). Regards, [Ag]. From don@brillig.umd.edu Mon Jul 25 10:17:26 1988 To: NeWS-makers@brillig.umd.edu Subject: Re: X vs NeWS - was --> is news loosing the battle? From: diamant@hpfclp.SDE.HP.COM (John Diamant) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: 12 Jul 88 04:18:07 GMT > Hmm... I don't know if i would call it foist. I think sun is bending > over backwards to accomodate the X fans of the world w/ the merged > NeWS/X11 server. Yes, the X11/NeWS server should satisfy everyone, but take a look at the history behind it. Also my comment was directed at the situation prior to having the X11/NeWS server. They really didn't have a lot of choice in the matter. Customers were demanding X for interoperability and the only way to get some of the vendors to look at NeWS was to provide it on the AT&T tape in the X11/NeWS merge (due to the large source licensing fee). Until it was clear that X11 was here to stay, Sun kept trying to make NeWS the standard and kill X. Only when it was clear that it wasn't going to work, did they join the bandwagon. > I think sun's attitude seems to more "may the best > one win". sun's policy on NeWS is pretty much like NFS , if you want > a reference source kit you hand over your XXXX amount of dollars and > you get it. Yes, that is true now. However, it is virtually impossible to implement either NFS or NeWS without the reference source. > >NeWS advantages over X: > >high power imaging model (2D) using absolute dimensions, rather than pixels > >non-rectangular windows > >Postscript available > > Not just available . postscript it is completely and pretty much seamlessly an > integral part of the server. the current plans for postscript under X just > seem like some weird abortion in comparison. Maybe you mean "aberration." Anyway, you're right that Postscript integration in NeWS is superior to the Postscript on X work. I didn't mean to imply that it wasn't. My separation of the imaging model from Postscript availability attempted to suggest that, but apparently I failed. > >disadvantages of NeWS relative to X: > >requires relatively powerful NeWS server -- a NeWS terminal will be more > > expensive than an X terminal > > I don't know if this is so true either. X is no doubt more thrify in resources > than NeWS but once you start using those monster X libraries (and you have > to to get anywhere with it) I'm not so sure the total resource usage will be > in X's favor. NeWS runs quit nicely on Macs and amigas and 386's. > I don't really think anybody is going to bother running X or NeWS on > anything smaller than those type of machines. I believe I have seen X product announcements for X on an IBM PC (8088). I'm pretty sure I've seen recommended configurations as low as 286 at least. I'm thinking in terms of dedicated X or NeWS terminals. The problem with NeWS terminals is that someone might try to run large portions of their program in the terminal, and it won't be able to handle it. It could probably handle reasonable client/server mixes, but there is nothing to prevent a NeWS program from attempting to run almost entirely in the server, which I'm sure would fail miserably on a NeWS terminal. > >programming process context switching and partitioning between client and > > server is a PAIN for the progammer. > Yeah, It's a pain sometimes. but I think It's well worth it just to get > the postscript paradigm Only if it saves you in software development cost elsewhere. If it makes developing the software harder, I don't think it's worth it. > > While on the subject of PostScript , there's the implementation of objects > and classes to consider too. This is a real boon when creating user interface > gadgets. Yes, that's true. Toolkits (on X) are object oriented too, of course. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant From don@brillig.umd.edu Mon Jul 25 10:18:56 1988 To: NeWS-makers@brillig.umd.edu Subject: Implementing N*S without the reference source From: mimsy!uunet!hoptoad!gnu (John Gilmore) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: 17 Jul 88 23:20:12 GMT > I think sun's attitude seems to more "may the best > one win". sun's policy on NeWS is pretty much like NFS , if you want > a reference source kit you hand over your XXXX amount of dollars and > you get it. diamant@hpfclp.SDE.HP.COM (John Diamant) wrote: > Yes, that is true now. However, it is virtually impossible to implement either > NFS or NeWS without the reference source. Sun designs a capable, very hard to build software product, builds it, and offers to sell the sources to anybody for cheap. The complaint is that they designed something that was too hard to clone? Be real... John "I cloned uucp without the reference sources" Gilmore PS: Besides, PostScript (the hard part of NeWS) has been cloned several times, one of which will be distributed free by the GNU project. -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com "And if there's danger don't you try to overlook it, Because you knew the job was dangerous when you took it" From don@brillig.umd.edu Tue Jul 26 11:11:46 1988 Date: Tue, 26 Jul 88 11:11:46 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS's use of floating point From: ken@gatech.edu (Ken Seefried iii) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In a related question, can NeWS use the Sky Floating Point board in a Sun 2? ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs, ken@gatech.edu inhp4, masscomp, rlgvax, sb1, uf-cgrl, ccastks@gitvm1.bitnet unmvax, ut-ngp, ut-sally}!gatech!ken soon to be open: ...!gatech!spooge!ken (finally ;'}) From don@brillig.umd.edu Tue Jul 26 12:01:39 1988 Date: Tue, 26 Jul 88 12:01:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Window Toolkits and Systems for a bunch of systems. From: steinmetz!vdsvax!barnett@uunet.uu.net (Bruce G. Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We are also looking for a window toolkit for user interfaces. The primary feature we are looking for is the ability to quickly develop complex applications. We have used an internally developed package that lets you interactively lay out panels with buttons, sliders, etc. Unfortunately, this isn't adequate. We *Would* like an interactive, object oriented environment. We would also like to have a somewhat portable window system, running on common workstations. (Sun, Apollo, DEC, HP, Symbolics). The Symbolic's Presentation Manager is nice, but is too text oriented. Common Windows is close, but lacking in some respects. (i.e. no control panels). NeWS has some advantages, but without a toolkit it is difficult to develop complex applications quickly. Are there plans for a DEC, HP or Apollo port of NeWS from a third party? Does Apollo's openDialogue provide more than an interactive panel layout facility? What other packages are available? Followups to comp.windows.misc. I will summarize email responses, etc. -- Bruce G. Barnett uunet!steinmetz!barnett From don@brillig.umd.edu Tue Jul 26 21:25:03 1988 Date: Tue, 26 Jul 88 21:25:03 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS meltdown From: eagle!icdoc!Ist!jh@ucbvax.Berkeley.EDU (Jeremy Huxtable) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I thought it was time one of these appeared as well.... %! % NeWS screen meltdown % % Jeremy Huxtable % % Mon Jul 25 17:36:06 BST 1988 % The procedure "melt" implements the ever-popular screen meltdown feature. /melt { 3 dict begin /c framebuffer newcanvas def framebuffer setcanvas clippath c reshapecanvas clippath pathbbox /height exch def /width exch def pop pop c /Transparent true put c /Mapped true put c setcanvas 1 1 1000 { pop random 800 mul random 600 mul random width 3 index sub mul random height 2 index sub mul 4 2 roll rectpath 0 random -5 mul copyarea pause } for framebuffer setcanvas c /Mapped false put /c null def end } def melt From don@brillig.umd.edu Tue Jul 26 21:27:39 1988 Date: Tue, 26 Jul 88 21:27:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Big brother From: eagle!icdoc!Ist!jh@ucbvax.Berkeley.EDU (Jeremy Huxtable) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Try this out on your NeWS server..... %! % eye.ps % % Jeremy Huxtable % % "Big Brother" implementation in PostScript. % Create an Eyeball class from the Default window class. /Eyeball DefaultWindow dictbegin /EyeX 0 def % Current eyeball position /EyeY 0 def /MouseEventMgr null def % Event manager dictend classbegin /Transform { initmatrix initclip clippath pathbbox scale pop pop .5 .5 translate } def /ShapeFrameCanvas { gsave ParentCanvas setcanvas FrameX FrameY translate FrameWidth FrameHeight scale .5 .5 .5 0 360 arc .5 .5 .2 0 360 arc FrameCanvas setcanvasshape grestore } def /PaintFrame { } def /DrawFrame { bordercolor setcolor clippath fill 0 0 .45 0 360 arc backgroundcolor setcolor fill } def /ShapeClientCanvas { } def /CreateClientCanvas { /ClientCanvas FrameCanvas newcanvas def } def /PaintClient { FrameCanvas setcanvas damagepath clipcanvas Transform DrawFrame clipcanvas EyeX EyeY 0 painteyeball } def /PaintFocus { } def /activate { % create event manager to watch the mouse. FrameCanvas setcanvas /MouseEventMgr [ MouseDragged { begin EyeX EyeY 1 painteyeball XLocation YLocation 0 painteyeball /EyeX XLocation store /EyeY YLocation store currentdict end redistributeevent } null % Action null % Canvas eventmgrinterest ] forkeventmgr def } def /painteyeball { % x y colour => setgray exch atan /angle exch def angle cos .2 mul angle sin .2 mul Transform .15 0 360 arc fill } def classend def % Now actually create a pair of eyes. /eyeball framebuffer /new Eyeball send def 100 700 16 16 /reshape eyeball send /map eyeball send /activate eyeball send /eyeball framebuffer /new Eyeball send def 145 705 16 16 /reshape eyeball send /map eyeball send /activate eyeball send From don@brillig.umd.edu Tue Jul 26 21:28:05 1988 Date: Tue, 26 Jul 88 21:28:05 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS magnifying glass From: eagle!icdoc!Ist!jh@ucbvax.Berkeley.EDU (Jeremy Huxtable) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! % NeWS magnifying glass % % Jeremy Huxtable % % Mon Jul 25 17:36:06 BST 1988 % Class "Magnifier" implements a NeWS magnifying glass. It consists of a % window, which displays the area around the cursor as you move it. Pressing % the left mouse button stops the magnifier, while selecting "Restart" from % the window menu starts it off again. "Zoom in/out" from the menu do what you % might expect. % % This file is just under 100 lines long (including comments). The SunView % glass program is an object file over 3/4 Mb in size, so there are no apologies % for lacking features. % % No doubt hundreds of wonderful features may be added, but here is a start... /Magnifier DefaultWindow [ /EventMgr /Factor ] classbegin /FrameLabel (Magnifying Glass) def /new { /new super send begin /Factor 1 def currentdict end } def /map { /map super send magnify } def /PaintClient { magnify_it } def /zoom { % increment => - /Factor Factor 3 2 roll add store Factor 0 eq { /Factor 1 store } if } def /magnify_it { framebuffer newcanvas % create source canvas framebuffer setcanvas % shape it to the same size as ClientCanvas currentcursorlocation exch ClientWidth 2 div sub exch ClientHeight 2 div sub ClientWidth Factor div ClientHeight Factor div rectpath dup reshapecanvas dup /Transparent true put % make it transparent dup /Mapped true put % and map it ClientCanvas setcanvas ClientWidth ClientHeight scale dup imagecanvas /Mapped false put % unmap the source canvas } def /magnify { EventMgr null eq { /EventMgr [ /MouseDragged { magnify_it redistributeevent } null null eventmgrinterest PointButton { pop stop_it } null null eventmgrinterest ] forkeventmgr def } if } def /stop_it { EventMgr null ne { EventMgr killprocess /EventMgr null def } if } def /DestroyClient { stop_it /DestroyClient super send } def classend def /window framebuffer /new Magnifier send def { /ClientMenu [ (Zoom in) { 1 /zoom ThisWindow send } (Zoom out) { -1 /zoom ThisWindow send } (Restart) { /magnify ThisWindow send } (Quit) { currentprocess killprocessgroup } ] /new DefaultMenu send def } window send /reshapefromuser window send /map window send From don@brillig.umd.edu Thu Jul 28 16:28:41 1988 Date: Thu, 28 Jul 88 16:28:41 EDT To: NeWS-makers@brillig.umd.edu Subject: No-cost Postscript. From: Paul Hudson Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Both the Postscript implmentations I've come across are not what I'd call compatible; either with the "reference source" (Red Book, I assume), or with Adobe implementations. The "reference source" is incomplete, and inconsistent; I don't know if this is true for the equivalent for NeWS. But then, there's no percentage for Adobe in producing an Implementor's Guide (grin). This just goes to show that there's no substitute for having the source, in practice (I personally would be happier with a *real* spec. in Z or VDM). I note that after all this mail that said "binaries are OK for NeWS", I get several pieces of mail describing bugs! (The prosecution rests ...). Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ From don@brillig.umd.edu Thu Jul 28 16:31:05 1988 Date: Thu, 28 Jul 88 16:31:05 EDT To: NeWS-makers@brillig.umd.edu Subject: Minor problem with nterm termcap entry From: steinmetz!vdsvax!montnaro@itsgw.rpi.edu (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Termcap entries for nterm are distributed with NeWS 1.1. The two entries (nterm and nterms) are missing Unix V6-style two char names at the beginning of the first line. 'Tset -' returns the *second* terminal name string it finds. For the Sun-distributed nterm entries they are the multiword names. The termcap(5) man page states: The first entry for each terminal gives the names which are known for the terminal, separated by `|' characters. The first name is always 2 characters long and is used by older version 6 systems which store the terminal type in a 16 bit word in a systemwide data base. The second name given is the most common abbreviation for the terminal, and the last name given should be a long name fully identifying the terminal. I added two-character "Nt" and "Nu" entries to the front of the nterm and nterms entries. I think Bill Joy needs to have a talk with those young whippersnappers in the NeWSroom, who think they know everything about Unix after just a few years... :-) -- Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa) From don@brillig.umd.edu Fri Jul 29 01:16:22 1988 Date: Fri, 29 Jul 88 01:16:22 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS Question From: ssc-vax!dmg@beaver.cs.washington.edu (David Geary) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've just received NeWS 1.1 for my Sun 3/60. Right now I'm wading through the documentation that I recieved with the software. However, before I've even started, I have a question that I cannot find an answer for in the documentation: If I write a NeWS-based application, can I run the application on another Sun that does NOT have NeWS loaded on it? If not, how much of the ~16 Megs of NeWS software must be loaded on the workstation? NeWS looks like interesting stuff to develop applications in, but my workstations do not have 16 Megs free just to support a couple of *neat* application programs. Thanx for the help... David Geary, Boeing Aerospace From don@brillig.umd.edu Fri Jul 29 01:17:13 1988 Date: Fri, 29 Jul 88 01:17:13 EDT To: NeWS-makers@brillig.umd.edu Subject: New Devices In NeWS From: mcvax!ukc!strath-cs!glasgow!orr@uunet.uu.net (Fraser Orr) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Our project is planning to purchase a tablet and pressure sensitive stylus, which we plan to connect to NeWS as a device. Has anyone out there done this sort of thing before? The stylus connects to an RS232 port, and I was planning to run a daemon that read this port and did 'sendevent's into the NeWS system. Is this a reasonable idea or do you think there would be timing problems? Any help in this regard would be appreciated, ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk From don@brillig.umd.edu Fri Jul 29 01:40:37 1988 Date: Fri, 29 Jul 88 01:40:37 EDT To: NeWS-makers@brillig.umd.edu Subject: Here are some easy questions... From: fluke!ssc-vax!dmg@beaver.cs.washington.edu (David Geary) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've just gotten started with NeWS, so forgive me if this is the ultimate novice question, but I can't run NeWS for more than a few minutes without the bottom 1/5 of the screen puking out, and telling me: "Window display lock broken because process xxxx blocked" How do I fix the lock? Can I get a new one at Ace Hardware? How do I stop this from happening. Secondly, can I start up the NeWS server and run NeWS in just one window inside of suntools? When I start up the server, it takes the whole screen. Thirdly, why did they name it NeWS instead of news? Typing CAPITAL N e CAPITAL W CAPITAL S is a pain. Thanks for all replies. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, ~ ~ Seattle - "THE DRIZZLE CAPITAL OF THE WORLD" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From don@brillig.umd.edu Fri Jul 29 01:41:26 1988 Date: Fri, 29 Jul 88 01:41:26 EDT To: NeWS-makers@brillig.umd.edu Subject: No-cost Postscript. From: Paul Hudson Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Both the Postscript implmentations I've come across are not what I'd call compatible; either with the "reference source" (Red Book, I assume), or with Adobe implementations. The "reference source" is incomplete, and inconsistent; I don't know if this is true for the equivalent for NeWS. But then, there's no percentage for Adobe in producing an Implementor's Guide (grin). This just goes to show that there's no substitute for having the source, in practice (I personally would be happier with a *real* spec. in Z or VDM). I note that after all this mail that said "binaries are OK for NeWS", I get several pieces of mail describing bugs! (The prosecution rests ...). Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ From don@brillig.umd.edu Sun Jul 31 04:12:50 1988 Date: Sun, 31 Jul 88 04:12:50 EDT To: NeWS-makers@brillig.umd.edu Subject: smooth motion in Huxtable's eye.ps From: icsia!fanty@ucbvax.Berkeley.EDU (Mark Fanty) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) NeWS animation which erases the old image before drawing the new one often has an unpleasant flickering. I liked Jeremy Huxtable's recently posted eye.ps (Re: Big brother) so much I decided to attempt a fix for the eyeballs. My solution uses clipping to avoid erasing any part of what will be the new eyeball. The new painteyeball is /painteyeball { % x y colour => setgray exch atan /angle exch def angle cos .2 mul angle sin .2 mul 2 copy 2 copy Transform gsave 0 0 .45 0 360 arc clip % avoid border % clip around new eye before erasing to avoid flicker .15 0 360 arc .8 0 360 arc eoclip backgroundcolor fillcanvas grestore .15 0 360 arc fill } def Also, remove the line EyeX EyeY 1 painteyeball in the mouse event manager. Mark Fanty International Computer Science Institute 1947 Center Street., Suite 600 Berkeley, CA 94704 (415) 643-7294 fanty@icsi.berkeley.edu From don@brillig.umd.edu Sun Jul 31 04:13:16 1988 Date: Sun, 31 Jul 88 04:13:16 EDT To: NeWS-makers@brillig.umd.edu Subject: Reference NeWS 1.1 under SunOS4.0 From: stan!claire@boulder.colorado.edu (Claire Campbell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi! I am attempting to get Reference NeWS 1.1 running on Sun4's under SunOS4.0. I have been working with Sun's Portable Software Group and between us, NeWS is now up and running. I do have a few recur- ring problems that have me stumped however. Is anyone out there attempting this same thing? If so, I'd love to exchange notes and ideas about how it's going! My current and elusive problem is: Occasionally, (most often following a core dump of the news_server, but not always), when I bring NeWS up it looks great -- Until I move the mouse. Then the main menu begins flashing around on the screen, tending toward the lower right corner, whenever the mouse moves. I can find no way to regain control of NeWS in this situation, and end up having to kill the server. In order to run NeWS correctly again, I have to REBOOT the system. In my PostScript error file I get lines and lines of: : Operation would block out of sync My only current thoughts are that: 1. It is SunOS4.0 related. 2. The mouse is getting out of wack. Is there a way to manually clear a mouse? (I've tried just unplugging it.) 3. When the news_server dies, it may leave some PostScript "downloaded" somewhere and this doesn't get cleared when started back up. In the PS manuals I've seen references to PS writing out to a file that will then be read back in next time. Anyone know about this? 4. This is still a real long shot, but it does seem that this behavior shows up most often following a lot of X use on the same device. Maybe X doesn't clean up the mouse or NeWS expects to be the only one to ever use something out there that X also uses? Any comments or suggestions would be greatly appreciated. I have reported this problem to the Portable Software Group at Sun, and I must say, even though this is an unsupported configuration, they've been really good about working with me! Thanks! Claire Claire Campbell stan!claire@boulder.edu Solbourne Computer, Inc. claire@stan.uucp (303) 447-2861 ...ncar!boulder!stan!claire From don@brillig.umd.edu Sun Jul 31 04:13:28 1988 Date: Sun, 31 Jul 88 04:13:28 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: size of a unit? From: sgi!msc@ucbvax.Berkeley.EDU (Mark Callow) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8807191313.AA21026@brillig.umd.edu>, marshall@software.ORG (Eric Marshall) writes: > > It does not appear that the size of a unit within the > default user space is 1/72nd of an inch, as in standard PostScript. > Is this true? If so, why the deviation? I suspect that it may > just be a hardware limitation, because the size of a unit appears > to be about 1/83rd of an inch, on a 3/160, which sounds pretty > close to the pixels per inch value. > > Thanks in advance. You got it. On Suns NeWS runs at screen resolution due to the frame buffer device drivers not providing resolution information. On Silicon Graphics machines, NeWS runs with 1/72nd inch default units (except 15 inch screens). I had to fix several bugs to make this work. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content." From don@brillig.umd.edu Sun Jul 31 04:13:54 1988 Date: Sun, 31 Jul 88 04:13:54 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS clients on VMS? From: unmvax!nmtsun!hydrovax@ucbvax.Berkeley.EDU (M. Warner Losh) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Has anybody out there ported the $NEWSHOME/clientsrc to VMS with Wollongong's TCP/IP implementation (I'd be very happy with CMU's, since I assume they are about the same from the user interface point of view). Of particular interest is the PSH program, with all of the libraries that it takes to get it going. What I'm trying to do is to use a VAXstation II as a "compute-server" and a SUN 3/60 as a "graphics-server". It would be nice to run a program on the VAX and have the output come out on the SUN running NeWS. I've been trying to port the stuff, but it is slow going due to the "portable" nature of the clientsrc stuff. If no-one has done this yet, does anyone know if I can distribute it after I have completed porting? Or is this like trying to distribute your hacked version of AT&T source code ..... Warner Losh -- cmcl2!lanl!unm-la!unmvax!nmtsun!hydrovax | My spelling and views are my own. csnet: hydrovax@nmt.edu | My employer doesn't know I can arpa: hydrovax.nmt@relay.cs.net | speak, so how can I speak for them? bitnet:hydrovax@nmt.csnet From don@brillig.umd.edu Sun Jul 31 04:16:58 1988 Date: Sun, 31 Jul 88 04:16:58 EDT To: NeWS-makers@brillig.umd.edu Subject: how to kill an nterm window From: super!rminnich@uunet.uu.net (Ronald G Minnich) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) ok, bring up an nterm window. then type 'cat' with no arguments. then hit lots of ^C (or whatever your interrupt character is). My nterm window will go away very fast. Question is, is this an nterm implementation problem or a news-related problem? Anyone care to comment? From don@brillig.umd.edu Sun Jul 31 05:18:24 1988 Date: Sun, 31 Jul 88 05:18:24 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: server class browser errors From: mcvax!philmds!nlgvax!berend@uunet.uu.net (Berend Munneke) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Often, but not always, I get the following output >(line breaks thanks to psterm) on my console when I start up >Bruce Schwartz's (Sun) server class browser. The program seems >to continue normally though. The output usually goes away when >I restart the server. I am running on a 3/160 with NeWS 1.1. After the '/map win send' in the file browse.ps I added the following line: 1000 { pause } repeat Now I don't get that error anymore. Maybe that 1000 is a little to big, but it works. From don@brillig.umd.edu Sun Jul 31 05:18:34 1988 Date: Sun, 31 Jul 88 05:18:34 EDT To: NeWS-makers@brillig.umd.edu Subject: caPITalS From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) David Geary asks: > Thirdly, why did they name it NeWS instead of news? Typing >CAPITAL N e CAPITAL W CAPITAL S is a pain. I tHiNk iTs a FaD. Look aT LaTeX and TeX and PostScript. jUSt A moDERN tHinG lIKe hULa hOOPS, eVERYbody hAS tO dO iT. iT wIlL GO AWAY eVENTually. But in the meantime, why don't we just refuse to type the capitals? Anybody out there want to help me start a boycott? News and latex and postscript are great without the capitals! Tom Schneider From don@brillig.umd.edu Sun Jul 31 05:18:45 1988 Date: Sun, 31 Jul 88 05:18:45 EDT To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS From: linus!philabs!mergvax!rkxyv@husc6.harvard.edu (Robert Kedoin) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) First, the novice questions: Is NeWS running on any non-Sun hardware ? Is it possible to port NeWS to non-Sun hardware and who can I contact for more information ? Second, the interesting question: I have seen mention made on this newsgroup and in "UNIX Review" about a combined X/NeWS server that will(?) be combined in the new AT&T System V Release 4. Can anyone point me in the direction for more information on this combined server ? Does this server mean that buy purchasing AT&T System V Release 4 one would also be purchasing a port of X and NeWS ? I apologize if these question have already been addressed here, but I just began reading this newsgroup. Thanks in advance for any information. -Rob Kedoin UUCP: ...{philabs,motown,icus}\!mergvax\!rkxyv ARPA: rkxyv%mergvax.UUCP@uunet.uu.net BITNET: rkxyv%mergvax.UUCP@uunet.uu.net.BITNET SNAIL-mail: Linotype Company - R&D 425 Oser Avenue Hauppauge, NY 11788 VOICE: (516) 434 - 2729 From don@brillig.umd.edu Sun Jul 31 05:19:41 1988 Date: Sun, 31 Jul 88 05:19:41 EDT To: NeWS-makers@brillig.umd.edu Subject: HyperTIES From: fluke!ssc-vax!benoni@beaver.cs.washington.edu (Charles L Ditzel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >From: don@BRILLIG.UMD.EDU (Don Hopkins) >Subject: is news loosing the battle? >Message-ID: <8807242028.AA24776@brillig.umd.edu> >Date: 24 Jul 88 22:24:15 GMT A hypermedia browser that I'm porting to NeWS for Ben Shneiderman, called HyperTIES, displays documents containing text and graphics with "embedded menus" of links to other documents. Embedded menu buttons are overlayed on top of text and graphics, and highlight when you move the cursor into them. Is this this a commercial product or a university project ? Will this be available soon ? From don@brillig.umd.edu Sun Jul 31 05:19:10 1988 Date: Sun, 31 Jul 88 05:19:10 EDT To: NeWS-makers@brillig.umd.edu Subject: reshapecanvas bug/feature? From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In doing some experiments I discovered that when the transform matrix associated with a parent canvas is modified using reshapecanvas, the children of that canvas are not affected by it. In particular, I would expect that doing a getcanvaslocation to find the location of a child w.r.t parent before and after the reshape would produce the same answer. In other words, if I have a child at (0,0) w.r.t. parent, and I arrange to put the parent's origin at (100,100), I would have expected that the child canvas would appear to move on the screen to the new (0,0) point so that getcanvaslocation would return (0,0) both before and after the origin change. Instead, the child canvas does not move w.r.t. screen, but it location w.r.t. parent changes. The consequence of this is that when I change the coordinates of a canvas, I have to visit all of its children and reshape them so that they will move to the correct locations. Is this reasonable behavior? Is this bug or a feature? From don@brillig.umd.edu Sun Jul 31 05:20:25 1988 Date: Sun, 31 Jul 88 05:20:25 EDT To: NeWS-makers@brillig.umd.edu Subject: Sun NeWS contact? From: dennis@boulder.colorado.edu Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Can anyone tell me the netmail address of someone in Sun to contact for help/clarification about the very strange behavior of NeWS 1.1? p.s. There has been much talk in this group about the relative merits of X vs. NeWS. Personally, I am beginning to believe that X will win: not because of technical superiority, but simply because the Sun NeWS implementation has too many bugs and undesirable behaviors. From don@brillig.umd.edu Sun Jul 31 05:21:02 1988 Date: Sun, 31 Jul 88 05:21:02 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS's use of floating point From: eagle!icdoc!qmc-cs!liam@ucbvax.Berkeley.EDU (William Roberts) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8807242004.AA17741@frame.com> greg@gergle.UUCP writes: >>I wonder how much faster news_server would run if it was >>compiled with the -f68881 flag. >No faster. It uses fixed point arithmetic. There are different assembler >files for the different CPU's. Not entirely true, there are genuine floats in there and compiling with -f68881 or -fsky does gain you something. It isn't very much though, because Sun do try to use their fixed-point stuff wherever possible. -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250 From don@brillig.umd.edu Sun Jul 31 05:21:42 1988 Date: Sun, 31 Jul 88 05:21:42 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS screen dump utility From: eagle!icdoc!Ist!jh@ucbvax.Berkeley.EDU (Jeremy Huxtable) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Here's a useful utility which allows you to dump arbitrary areas of the screen as Sun rasterfiles, and then display them in a window. Very useful for doing documentation. This works OK on Monochrome Sun3/50 and 3/75's, but hasn't been tested on a colour display. There appear to be some problems with NeWS's "writecanvas" operator. At least on our system, canvases written with "writecanvas" cannot be read back by anything, while rasterfiles written by other programs (e.g. FrameMaker) can't be read back using "readcanvas". "writescreen" and "readcanvas" seem to work together OK though. I have had some trouble with NeWS core dumping when using "readcanvas/imagecanvas", but presumably this will go away in the next release :-) ------cut here------ #! /usr/NeWS/bin/psh %! % NeWS Screen dumper % % Jeremy Huxtable % % Mon Jul 25 17:36:06 BST 1988 % Class "DumpWindow" implements a NeWS screen dumper. The window contains % three buttons and a text item: % The text item allows you to select the filename to dump to. % Dump - allows you to select a rectangle on the screen to dump to the file. % While dumping, the Dump window is unmapped so that it does % not interfere with the screen image. % Restore - allows you to select a rectangle on the screen into % which the image will be painted (directly onto the framebuffer). % Display - pops up a window which displays the image from the given file. % The image is scaled to fit into the window. % % BUGS: You can't zap the parent window until all Display windows have been % zapped. I can't find where the dangling reference to the window is. systemdict /Item known not { (NeWS/liteitem.ps) run } if /DumpWindow DefaultWindow [ /DumpItems /Filename ] classbegin /IconImage /screendump def /FrameLabel (Screen Dump) def /new { /new super send begin /DumpItems null def /Filename (,Scrndump) def 300 140 fboverlay setcanvas getclick 2 index sub % Subtract height from y to select top left 4 2 roll reshape activate currentdict end } def /PaintClient { DumpItems paintitems } def /set_name { /Filename exch def } def /message { % str => - /printstring DumpItems /message get send } def /activate { /DumpItems 5 dict dup begin /filename (File name:) Filename /Right [ /ItemValue cvx self /set_name exch /send cvx ] cvx ClientCanvas /new TextItem send 10 75 240 0 /reshape 5 index send def /message () () /Right nullproc ClientCanvas /new MessageItem send 10 45 240 0 /reshape 5 index send def /dump_button (Dump) [ self /do_dump exch /send cvx ] cvx ClientCanvas /new ButtonItem send dup /ItemFrame 1 put dup /ItemRadius 0.2 put 10 10 70 25 /reshape 5 index send def /restore_button (Restore) [ self /do_restore exch /send cvx ] cvx ClientCanvas /new ButtonItem send dup /ItemFrame 1 put dup /ItemRadius 0.2 put 100 10 70 25 /reshape 5 index send def /display_button (Display) [ self /do_display exch /send cvx ] cvx ClientCanvas /new ButtonItem send dup /ItemFrame 1 put dup /ItemRadius 0.2 put 190 10 70 25 /reshape 5 index send def end def DumpItems forkitems pop } def /do_dump { gsave unmap fboverlay setcanvas getwholerect waitprocess aload pop framebuffer setcanvas points2rect rectpath { Filename writescreen } errored { (Can't write file) } { () } ifelse message map grestore } def /do_restore { gsave fboverlay setcanvas getwholerect waitprocess aload pop framebuffer setcanvas points2rect 4 2 roll translate scale { Filename readcanvas } errored { (Can't read file) } { imagecanvas () } ifelse message grestore } def /do_display { { clear newprocessgroup Filename framebuffer /new ImageWindow send /reshapefromuser 1 index send /map exch send countdictstack 1 sub { end } repeat } fork pop } def /destroy { /DumpItems null def /destroy super send } def classend def /ImageWindow DefaultWindow [ /ImageCanvas ] classbegin /IconImage /screendump def /FrameLabel (Image Display) def /new { % filename => instance /new super send begin /FrameLabel 1 index def { readcanvas } errored { null } if /ImageCanvas exch def currentdict end } def /PaintClient { ImageCanvas null eq { clippath pathbbox exch 2 div exch 2 div moveto (Can't read image file) cshow pop pop } { clippath pathbbox scale pop pop ImageCanvas imagecanvas } ifelse } def classend def /map framebuffer /new DumpWindow send send From don@brillig.umd.edu Tue Aug 2 03:25:55 1988 Date: Tue, 2 Aug 88 03:25:55 EDT To: NeWS-makers@brillig.umd.edu Subject: How do I get 1 From: Wolf-Dieter Batz Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Ok, after reading this list for a while I agree that NeWS is a fine thing to work with/under. Now I would like to know how we can get 1 (or 2?). We have a SUNII and several SUNIII's /w 68881 FPU. Do we need different versions? - Wolf-Dieter BATZ From don@brillig.umd.edu Tue Aug 2 03:26:13 1988 Date: Tue, 2 Aug 88 03:26:13 EDT To: NeWS-makers@brillig.umd.edu Subject: Screen Dumper From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I just tried out Jeremy Huxtable's screen dump on a color 3/260c Sun. It worked nicely to capture the color! Then I tried it again and it said 'IO TRAP' and killed NeWS... and I was logged out (probably because after news ends my .login does a logout). So there's a bug here Jeremy! Tom Schneider toms@ncifcrf.gov From don@brillig.umd.edu Tue Aug 2 03:27:00 1988 Date: Tue, 2 Aug 88 03:27:00 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS terminal emulators From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm sort of new to NeWS, so maybe I'm just doing something wrong, but it looks to me that psterm is pretty much a disaster. Aside from the fact that it's slow as hell, most of the terminal emulations don't seem to work. The h19 works the best, but still has some bugs (ocassionally it jumps into underline mode and often leaves garbage characters on the screen). All the other terminal types (vt100, sun, etc) seem not to work at all when I try using (terminfo-based) CCA emacs. The "scrolling prototype" (nterm?) works better as far as getting the right stuff in the right place on the screen goes, but it's even slower than psterm; I can work about as fast on my 2400-baud dial-up! So, what should I do about a NeWS terminal emulator? Is there some other termcap and/or terminfo entry which will make psterm work right with more than 24 lines? Is there some hope that nterm will be faster in the next release (and I mean at least twice as fast, in order to make it reasonably useful)? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Tue Aug 2 03:27:36 1988 Date: Tue, 2 Aug 88 03:27:36 EDT To: NeWS-makers@brillig.umd.edu Subject: screendump utility bug From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) This is some more about Jeremy Huxtable's screendump. The error message is IOT trap. When I display (or was it restore? anyway, it's the one that puts things into a window) it works fine... until I try to kill the window with a zap - my whole server was zapped! Everything I typed was garbled and the cursor was only partially responsive... I was forced to kill the news server by remote logging in over the net. So there is a bug in this that can be rather nasty. It's a great tool otherwise! Tom From don@brillig.umd.edu Tue Aug 2 04:01:15 1988 Date: Tue, 2 Aug 88 04:01:15 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: caPITalS From: allosaur.cis.ohio-state.edu!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8807291539.AA05921@fcs260c2.ncifcrf.gov> toms@NCIFCRF.GOV writes: >David Geary asks: >> >>Thirdly, why did they name it NeWS instead of news? Typing CAPITAL >>N e CAPITAL W CAPITAL S is a pain. > >I tHiNk iTs a FaD. Look aT LaTeX and TeX and PostScript. jUSt A >moDERN tHinG lIKe hULa hOOPS, eVERYbody hAS tO dO iT. iT wIlL GO >AWAY eVENTually. As has been discussed here before, it's also hard to pronounce in such a way as to distiguish the window system from the message system from the Japanese workstation. At the NeWS SIG at SUG in San Jose last December, it was agreed (by everyone present except those from Sun) that the correct way to pronounce the window system was "knee-wiss". The local NeWS hacquers didn't like that idea much, so they've started pronouncing the name of Steve Jobs' new company (also using odd CapiTaliZation) as "knee-zit". -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob From don@brillig.umd.edu Tue Aug 2 04:02:46 1988 Date: Tue, 2 Aug 88 04:02:46 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS terminal emulators From: hoptoad!gnu@ucbvax.Berkeley.EDU (John Gilmore) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Terminal emulators are one of NeWS's big holes now. We at the Grasshopper Group have been working on psterm, and it is now much better. If you were at Usenix, we demoed a mid-life version of it there. It can be set for any font, font size, # rows, or # columns. It can either stretch the font, or the #rows/cols, when you resize the window. It has an optional scroll bar. It slices, it dices, it writes bad checks. We also clarified the client source copyright with Sun so that we could post it to the net. We're interested in making NeWS more of a viable window system -- nobody will buy our Mac A/UX version if NeWS loses in the general market, after all. The code is currently being tested and packaged up, and it will go into the comp.sources.unix queue when it works and is easy to install. We hope that you won't be happy with that version, but will hack it and slash it and send it back to us for an updated reposting; it's work in progress, not an artistic jewel, and in particular the user interface needs work. Eric Messick did the changes, with kibbutzing from me and Hugh Daniel. There are some things that are hard to fix given psterm's structure. Psterm is a "termcap interpreter" -- everything it knows about a terminal comes from the terminal's termcap entry. If your program knows more about VT100's than what the termcap entry says, there will be escape sequences that psterm cannot figure out. If your terminfo description is more complete than your termcap description, ditto. Our version of psterm defaults to emulating the "psterm" terminal, which *no* programs know funny things about. We provide termcap and terminfo descriptions for the "psterm" terminal, which match exactly, and which are optimized for use with psterm. If you have made bugfixes to NeWS 1.1's psterm, please send them to me; we will try to merge them into the comp.sources.unix posting, to make everyone's life easier. -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com "And if there's danger don't you try to overlook it, Because you knew the job was dangerous when you took it" From don@brillig.umd.edu Tue Aug 2 04:02:44 1988 Date: Tue, 2 Aug 88 04:02:44 EDT To: NeWS-makers@brillig.umd.edu Subject: Is NeWS UseABLE? From: fluke!ssc-vax!dmg@beaver.cs.washington.edu (David Geary) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I will soon be writing a graphical interface to Unix for Sun workstations. Recently I received NeWS, and have been playing with it for about a week or so. I'm trying to figure out whether or not NeWS is mature enough to for such a project. I'd like to know what bugs you have found with NeWS, and what you like/dislike about it. Here's a summary of my impressions so far: Pros: 1) The postscript language, along with the object-oriented features in NeWS give a very powerful development tool for implementing user interfaces. 2) NeWS code, since it runs via an interpreter appears to be *easy* to debug. Cons: 1) The whole thing seems sluggish to me. I thought that SunView window manipulation was slow compared to my Amiga, but NeWS seems even worse than SunView. Right now, I'm running vi inside of a VT102 emulator (psterm??), and I can outtype it at will. 2) If I run NeWS inside of SunView, by "setenv FRAMEBUFFER x y w h" (BTW, thanks to all who replied to my previous posting on this), I don't get a window, I just get a non-sizeable area of the screen that I can only run NeWS in - yuck. If I run SunView application inside of NeWS, I get an unsightly border around the SunView application. I'd like to be able to just run a NeWS application inside of SunView, in a window that looks and behaves just like a SunView window. Anybody else care to add to this discussion? NeWS seems *neat* to me, but I'm unsure of it's maturity. (Actually, I'm unsure of my maturity too). Thanx. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, ~ ~ Seattle - "THE DRIZZLE CAPITAL OF THE WORLD" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From don@brillig.umd.edu Tue Aug 2 04:01:55 1988 Date: Tue, 2 Aug 88 04:01:55 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: caPITalS From: amsdsg!jeff@uunet.uu.net (Jeff Barr) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) NeWS is not named NEWS because NEWS is trademarked by Sony for their workstation product line. Apparently, case does matter in trademark names! This is straight from a Sony representative, later confirmed by SUN. Jeff -- +-----------------------------------------------------+ | Jeff Barr AMS uunet!amsdsg!jeff 800-832-8668 | +-----------------------------------------------------+ \ "This space for rent". / From don@brillig.umd.edu Tue Aug 2 04:18:03 1988 Date: Tue, 2 Aug 88 04:18:03 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: X windows for Silicon Graphics Machines (HELP) From: THRUSH.STANFORD.EDU!jim@ucbvax.berkeley.edu (Jim Helman) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1174@cod.NOSC.MIL> waagen@cod.NOSC.MIL (Don E. Waagen) writes: >I need to know if X windows has been ported to the Silicon Graphics 4D >or 3130 machines. Any help will be appreciated. SGI's new window system on the 4D series called FourSight, supports X11, NeWS and GL, SGI's 3-D graphics library. All of the standard tools are implemented in NeWS. ico and xclock are the only X applications in the distribution. And with good reason, the X support seems to be the least well developed of the three interfaces. It is extremely slow and somewhat buggy. But SGI did manage to beat Sun to the market with a combined X/NeWS server. How slow is it? It's SOOO slow that it makes X11R2 on a color Sun-3 seem snappy, e.g. 3-5 seconds to scroll a full height xterm or gnuemacs window. Not bad for a 4D/70 rated at 10MIPS! Still a not-quite-ready-for-prime-time X/NeWS server is better than none at all.... Jim Helman (jim@thrush.stanford.edu) Department of Applied Physics Stanford University From don@brillig.umd.edu Tue Aug 2 17:14:09 1988 Date: Tue, 2 Aug 88 17:14:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Fun with windows: make your workstation look more like a Mac... From: mcvax!ukc!stl!tjcm@uunet.uu.net (Crawford Macnab) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <17523@tut.cis.ohio-state.edu> elwell@ichthyosaur.cis.ohio-state.edu (Clayton M. Elwell) writes: >This article contains a context diff for the file 'mac.ps' in NeWS 1.1 >that makes the mac-style window class more mac-like. Also, since the We have only recently received our official release of NeWS 1.1 and I have been unable to find any file called 'mac.ps'. Did this only appear in early releases of NeWS 1.1 (perhaps removed from later ones for legal reasons :-)) ?? Could somenone post this file to me or if there appears to be a lot of interest to the net. Thanks in advance, -- Crawford Macnab ( tjcm@stl.stc.co.uk +44-279-29531 Ext 2153 ) STC TECHNOLOGY LTD, London Road, Harlow, Essex, CM17 9NA, United Kingdom. From don@brillig.umd.edu Tue Aug 2 17:14:23 1988 Date: Tue, 2 Aug 88 17:14:23 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS terminal emulators From: super!rminnich@uunet.uu.net (Ronald G Minnich) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <3411@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > I'm sort of new to NeWS, so maybe I'm just doing something wrong, >but it looks to me that psterm is pretty much a disaster. Aside from the No, you're right, psterm is a disaster. So is nterm, the newer replacement. I say nterm is a disaster cause while using it i spent most of my time waiting for it to echo what i had typed. Two weeks of that sh*t and i finally gave up on NeWS, for now. Kinda sad, i really like NeWS, but the only tool that works is the clock. If you are going to have a windows system it really ought to have a terminal emulator to start .... Some good guys from another company have told me that a real psterm will show up on comp.sources.unix soon; hope real soon, as i can not use NeWS till it appears. The thing that gets me is this is NeWS1.1; i can't imagine what 1.0 was like. Does 1.1 == beta-release version 1? If this is the X-11 competition it is going to need more work! ron P.S. Well, i don't know what you can do, but i am back in SunTools. From don@brillig.umd.edu Tue Aug 2 17:14:52 1988 Date: Tue, 2 Aug 88 17:14:52 EDT To: NeWS-makers@brillig.umd.edu Subject: landscape psview and psterm sluggishness From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anybody know how to get pages sizes other than 8-1/2 x 11 using psview? I'm specifically interested in 11 x 8-1/2 (i.e. landscape mode) but it would be nice if there was a general procedure for specifying the page size. BTW, yesterday (and earlier) I complained about the slowness of psterm. Columbia!chris pointed out that if you have enough idle machines you should run a news server on your workstation and psterm on another machine to split the load between 2 CPUs. Actually, I think it's more that you get to use twice the physical memory that makes the difference. Even better, do an rlogin to yet a third machine to do your real work. I tried it and it does make indeed make a difference. I can still out-type psterm, but at least windows come up a lot faster (almost instantaneously). I don't know what I'm going to do comes September when there aren't any idle machines, but that's another problem. Actually, I wouldn't be surprised if two people on two workstations, each running psterms on each others CPUs to their own news servers wouldn't see better overall performance than if they each ran local psterms. With a local psterm, when I do something, both my psterm and my server have to wake up at the same time. WIth cross-psterms, you don't have this synchronous CPU demand peaking. Just a guess. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Tue Aug 2 17:15:09 1988 Date: Tue, 2 Aug 88 17:15:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Here are some easy questions... From: steinmetz!vdsvax!barnett@uunet.uu.net (Bruce G. Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2126@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: |"Window display lock broken because process xxxx blocked" I don't know if this is your error, but from Page 5 of READ THIS FIRST: "NeWS 1.1 incorporates a process timeout mechanism. This prevents a single errant process from grabbing the NeWS server, preventing other NeWS processes from running. A clock counts down seconds from a global timeout value. It is reset everytime the server switches to another process. If it reaches zero, the current process gets a TIMEOUT error. The timeout value defaults to 15 seconds. If you find processes are getting timeout errors (for example when displaying complex graphics) the timeout value can be modified (globally) by using the SETJOBTIMEOUT operator described in Appendix D.6 of the PostScript Language Reference Manual. For example, statusdict begin 90 setjobtimeout end will set the timeout to 90 seconds." -- Bruce G. Barnett uunet!steinmetz!barnett From don@brillig.umd.edu Tue Aug 2 23:08:17 1988 Date: Tue, 2 Aug 88 23:08:17 EDT To: NeWS-makers@brillig.umd.edu Subject: Broken display lock From: convex!vitsun!pat@uunet.UU.NET (Patrick Turley) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2126@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: >"Window display lock broken because process xxxx blocked" In SunView, processes obtain locks from the windowing system before they write to the screen. These locks time out after 1 second of virtual process time (I think that's right - check the SunView manual if the precise number interests you). If the lock is broken, that is the message you get. I don't have NeWS here so I don't know a lot about it but it seems logical to infer from what I've heard that it is going through the usual SunView arbitration mechanisms (NeWS will run in a SunView window, won't it?) but taking too long on something. I was once interested in increasing the timeout value and called up Sun software support to find out if it was a system parameter that I could fiddle with in some configuration file or something. It turns out that it doesn't appear in a any configuration file but you can increase it by poking a particular location in the kernel. Of course, that means the new value is only good until the system goes down. Perhaps this could be automated by feeding adb's stdin with a script in rc.local. Pat +-------------------------+---------------------------------------+ | | | * * | Patrick Turley | | | | | * * * * | Senior Software Engineer | | | | | * * * * * * | Visual Information Technologies | | | | | * * * * * * | 3460 Lotus Drive | | | | | * * * * | Plano, TX 75075 | | | | * * | (214) 596-5600 convex!vitsun!pat | +-------------------------+---------------------------------------+ From don@brillig.umd.edu Tue Aug 2 23:08:24 1988 Date: Tue, 2 Aug 88 23:08:24 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: SLOW nterm and NeWS terminal emulators From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I agree that the terminals under the current news are too slow. But I still want to use the great graphics, so I use the suntool windows running under news. Unfortunately they override all the news graphics, but they can be set aside when I need to do graphs (the psh and psview must be run from nterm, the news server ignores them if they come from a suntool.) If you want to set this up yourself, get news to come up in your .login, and put (shelltools) forkunix in a file named user.ps in your home directory. Then put a file named shelltools in your bin, containing: shelltool -Wp 0 66 -Ws 650 834 -WP 528 0 -Wl "left" -WL "left"& shelltool -Wp 0 66 -Ws 650 834 -WP 528 0 -Wl "left" -WL "left"& shelltool -Wp 502 333 -Ws 650 567 -WP 592 0 -Wi -Wl "mid" -WL "mid"& shelltool -Wp 658 66 -Ws 494 834 -WP 656 0 -Wi -Wl "right" -WL "right"& shelltool -Wp 0 0 -Ws 527 63 -WP 0 0 -W -Wl "strip" -WL "strip"& mailtool -Wp 8 189 -Ws 646 708 -WP 912 0 -Wi -i 1& clock -Wp 0 270 -Ws 218 39 -WP 848 0 -Wi & By the way, does anyone know how to add to this system to get one of the nterms to appear when I log in? And how can I get my pair of pet eyes to appear too? Regards to all - Tom Schneider toms@ncifcrf.gov From don@brillig.umd.edu Tue Aug 2 23:09:15 1988 Date: Tue, 2 Aug 88 23:09:15 EDT To: NeWS-makers@brillig.umd.edu Subject: Broken display lock From: convex!vitsun!pat@uunet.UU.NET (Patrick Turley) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2126@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: >"Window display lock broken because process xxxx blocked" In SunView, processes obtain locks from the windowing system before they write to the screen. These locks time out after 1 second of virtual process time (I think that's right - check the SunView manual if the precise number interests you). If the lock is broken, that is the message you get. I don't have NeWS here so I don't know a lot about it but it seems logical to infer from what I've heard that it is going through the usual SunView arbitration mechanisms (NeWS will run in a SunView window, won't it?) but taking too long on something. I was once interested in increasing the timeout value and called up Sun software support to find out if it was a system parameter that I could fiddle with in some configuration file or something. It turns out that it doesn't appear in a any configuration file but you can increase it by poking a particular location in the kernel. Of course, that means the new value is only good until the system goes down. Perhaps this could be automated by feeding adb's stdin with a script in rc.local. Pat +-------------------------+---------------------------------------+ | | | * * | Patrick Turley | | | | | * * * * | Senior Software Engineer | | | | | * * * * * * | Visual Information Technologies | | | | | * * * * * * | 3460 Lotus Drive | | | | | * * * * | Plano, TX 75075 | | | | * * | (214) 596-5600 convex!vitsun!pat | +-------------------------+---------------------------------------+ From don@brillig.umd.edu Tue Aug 2 23:59:03 1988 Date: Tue, 2 Aug 88 23:59:03 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Here are some easy questions... From: neptune!pvo3366@cs.orst.edu (Paul O'Neill) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4993@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: > >the timeout value can be modified (globally) by using the >SETJOBTIMEOUT operator described in Appendix D.6 of the PostScript >Language Reference Manual. For example, > > statusdict begin 90 setjobtimeout end > >will set the timeout to 90 seconds." > Appendix D of the 'red book' is Apple Laserwriter specific. We have NeWS 1.0. Any reference to statusdict blows its mind. The real solution here is to open a console (psterm or commandtool) for all those messages to go to. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU/Oceanography Corvallis, OR 97331 503-754-3251 From don@brillig.umd.edu Wed Aug 3 00:02:02 1988 Date: Wed, 3 Aug 88 00:02:02 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: neptune!pvo3366@cs.orst.edu (Paul O'Neill) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2135@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > >2) If I run NeWS inside of SunView, by "setenv FRAMEBUFFER x y w h" >(BTW, thanks to all who replied to my previous posting on this), I >don't get a window, I just get a non-sizeable area of the screen >that I can only run NeWS in - yuck. If I run SunView application..... This is a neat trick!! I couldn't find any postings describing this, so I assume people must have mailed it to you. Does it really work as quoted in your posting? It took me a long time to figure out setenv FRAMEBUFFER '/dev/fb x y w h' was what was required. Where is this documented? Wizards---why won't setenv FRAMEBUFFER /dev/win* work? Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU/Oceanography Corvallis, OR 97331 503-754-3251 From don@brillig.umd.edu Wed Aug 3 00:04:44 1988 Date: Wed, 3 Aug 88 00:04:44 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Here are some easy questions... From: neptune!pvo3366@cs.orst.edu (Paul O'Neill) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4993@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: > >the timeout value can be modified (globally) by using the >SETJOBTIMEOUT operator described in Appendix D.6 of the PostScript >Language Reference Manual. For example, > > statusdict begin 90 setjobtimeout end > >will set the timeout to 90 seconds." > Appendix D of the 'red book' is Apple Laserwriter specific. We have NeWS 1.0. Any reference to statusdict blows its mind. The real solution here is to open a console (psterm or commandtool) for all those messages to go to. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU/Oceanography Corvallis, OR 97331 503-754-3251 From don@brillig.umd.edu Wed Aug 3 00:05:00 1988 Date: Wed, 3 Aug 88 00:05:00 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: neptune!pvo3366@cs.orst.edu (Paul O'Neill) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2135@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > >2) If I run NeWS inside of SunView, by "setenv FRAMEBUFFER x y w h" >(BTW, thanks to all who replied to my previous posting on this), I >don't get a window, I just get a non-sizeable area of the screen >that I can only run NeWS in - yuck. If I run SunView application..... This is a neat trick!! I couldn't find any postings describing this, so I assume people must have mailed it to you. Does it really work as quoted in your posting? It took me a long time to figure out setenv FRAMEBUFFER '/dev/fb x y w h' was what was required. Where is this documented? Wizards---why won't setenv FRAMEBUFFER /dev/win* work? Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU/Oceanography Corvallis, OR 97331 503-754-3251 From don@brillig.umd.edu Thu Aug 11 01:15:54 1988 Date: Thu, 11 Aug 88 01:15:54 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS Calendar Tool? From: John F. Fowler Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Anyone know where I might get a NeWS version of the Calendar Tool? Mail Tool? John Fowler Syracuse University Computing and Network Services Internet: jffowler@icarus.cns.syr.edu Machinery Hall Bitnet: oprjff@suvm Syracuse, NY 13244-1260 USA AT&T: (315) 423-2861 From don@brillig.umd.edu Thu Aug 11 02:40:53 1988 Date: Thu, 11 Aug 88 02:40:53 EDT To: NeWS-makers@brillig.umd.edu Subject: Printing from NeWS From: sunloop!mrmellow!rich@Sun.COM (Rich Holada TSE Chicago Loop Sales) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) NeWS GU's, When I first started hacking in NeWS I was told that because it is based on PostScript I would get printing (to a PostScript Printer) for free. Well, now I am generating a subclass of Litewindows to do two dimensional graphing in a NeWS window. The logical follow-up is to take the graph I have generated and spool it off to a LaserWriter. I know how to lpr PostScript code to a printer but that's not what I am looking for. I am looking to push a button on my tool and having the PostScript stream directed to the LaserWriter instead of a NEWSSERVER. Does anyone know how to do this or better yet know where I could get a hold of a piece of code which demos this ability? Thanks in advance. Rich (Shit Happens) Holada Sun Microsystems TSE {texsun, sunbird, sun}!sunloop!rich From don@brillig.umd.edu Thu Aug 11 02:41:43 1988 Date: Thu, 11 Aug 88 02:41:43 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: caPITalS From: pdn!pdnag1!wolfe@uunet.uu.net (0000-Mike Wolfe(0000)) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <19094@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: toms@NCIFCRF.GOV writes: <>David Geary asks: <>> <>>Thirdly, why did they name it NeWS instead of news? Typing CAPITAL <>>N e CAPITAL W CAPITAL S is a pain. <> , dmg@ssc-vax.UUCP (David Geary) says: > I will soon be writing a graphical interface to Unix for Sun > workstations. Recently I received NeWS, and have been playing with > it for about a week or so. > I'm trying to figure out whether or not NeWS is mature enough to > for such a project. Why not ? Certainly others are writing NeWS-based applications...Sun itself recently released an IBM 3270 emulator that runs under NeWS. However, NeWS 1.1 remains an unsupported product and that may figure in your thinking...(for that matter X remains an unsupported product also..) Sun will release an X/NeWS merged product soon... (Silicon Graphics incidentally already has an X/NeWS window system which according to the net traffic works better with NeWS than X...:-) > that I can only run NeWS in - yuck. If I run SunView application > inside of NeWS, I get an unsightly border around the SunView > application. I'd like to be able to just run a NeWS application > inside of SunView, in a window that looks and behaves just like a > SunView window. It sounds like you are anticipating 4.1 when NeWS, X and Sunview windows will cohabitate the screen peacefully...for the moment you'll have to live with the white edging on your Sunview windows I generally have some of the same gripes about type-ahead that you have however i realize that 1) the product is unsupported and 2) provides me with an initial development environment while i wait for the supported NeWS/X window system. ----------------------------------------------------- My opinions are obviously my own and not my employers... From don@brillig.umd.edu Thu Aug 11 03:09:25 1988 Date: Thu, 11 Aug 88 03:09:25 EDT To: NeWS-makers@brillig.umd.edu Subject: Greyscale hardcopy from NeWS windows? From: spe@spice.cs.cmu.edu (Sean Engelson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is there a quick and easy way to get a greyscale PS hardcopy file of a NeWS window? There dooesn't seem to be any way to either go directly from a CPS program to a printable PS file, or from an 8-bit Sun rasterfile to greyscale PostScript. Thanks for any help. -Sean- -- ---------------------------------------------------------------------- Sean Philip Engelson /// I don't want a pickle, Asst. Research Scientist /// I'd rather ride on my bi-cycle. and Chief Lizard \\\/// I don't want a tickle, Carnegie-Mellon University \\// I'd rather ride on my bi-cycle. Computer Science Dept. AMIGA! And I don't wanna die, I'd rather ride on my bicy-- cle! ---------------------------------------------------------------------- Do you desire life, and wish to see good from your days? Curb your tongue from evil, and your lips from maliciousness; Turn from evil and do good, seek out peace, and pursue it. ---------------------------------------------------------------------- My opinions are my own, and do not reflect official policy, either explicit or implied, of the Carnegie-Mellon University Computer Science Department. ---------------------------------------------------------------------- ARPA: spe@spice.cs.cmu.edu UUCP: {harvard | seismo | ucbvax}!spice.cs.cmu.edu!spe ck *before* the timeout occurs. The timeout is necessary, by the way, to prevent a lock from remaining after a process has unexpectedly died. But this is digressing and becoming a Suntools conversation. Are we correct in assuming that this NeWS behaviour is analogous to the Suntools windowlock? ------------------------------------------------------------------------ \\\ Deke Kassabian, URochester Department of Electrical Engineering \\\ \\\ deke@ee.rochester.edu "I never metacharacter \\\ \\\ or ...!rochester!ur-valhalla!deke I didn't like......" \\\ ------------------------------------------------------------------------- "Isn't fun the BEST thing to have ?" From don@brillig.umd.edu Thu Aug 11 03:22:54 1988 Date: Thu, 11 Aug 88 03:22:54 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: Greg Earle Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >2) If I run NeWS inside of SunView, by "setenv FRAMEBUFFER x y w h" >(BTW, thanks to all who replied to my previous posting on this), I >don't get a window, I just get a non-sizeable area of the screen >that I can only run NeWS in - yuck. If I run SunView application >inside of NeWS, I get an unsightly border around the SunView >application. I'd like to be able to just run a NeWS application >inside of SunView, in a window that looks and behaves just like a >SunView window. It may be `yuck', but that's what you get. If you don't like it, run NeWS (to take over the entire framebuffer) from inside SunView using overview(1). You seem to want to consider NeWS a window-able application of SunView, and it just isn't. It's on the same level as SunView, and must be looked at that way. You get an unsightly border around SunView applications because this is done on purpose to prevent strange mouse droppings from occurring when one goes from a SunView window frame borderinto a NeWS window or NeWS root window. You're lucky that you can even run SunView binaries inside of NeWS; you can't go the other way! You'd like to be able to run NeWS applications under SunView, but (right now) this is not possible. When SunView 2 is released (as a toolkit for X11/NeWS), you'll be able to do so, because by then SunView will be a subset of X11/NeWS and everything will be one big, happy family. Until then, sorry ... - Greg Earle Sun Los Angeles Consulting From don@brillig.umd.edu Thu Aug 11 03:23:30 1988 Date: Thu, 11 Aug 88 03:23:30 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Fun with windows: make your workstation look more like a Mac... From: mcvax!tnosel!westc!msteen@uunet.uu.net (Martien F. van Steenbergen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'd like a copy too. Martien. From don@brillig.umd.edu Thu Aug 11 03:24:15 1988 Date: Thu, 11 Aug 88 03:24:15 EDT To: NeWS-makers@brillig.umd.edu Subject: show bug using rotated text From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The following program demonstrates that the show operator doesn't properly space rotated text when given a character string with more than a single character: /Times-Bold findfont 30 scalefont setfont 200 200 moveto 90 rotate (Hello) show Both the 'e' and 'o' characters overwrite the 'H'. If the show command is given only a single character to display: (H) show (e) show (l) show (l) show (o) show it works fine. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Thu Aug 11 03:24:31 1988 Date: Thu, 11 Aug 88 03:24:31 EDT To: NeWS-makers@brillig.umd.edu Subject: mac.ps etc. From: saqqara.cis.ohio-state.edu!elwell@tut.cis.ohio-state.edu (Clayton Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Well, now I'm confused. The file 'mac.ps' and a corresponding demo program called 'macdemo' were on our NeWS 1.1 beta tape. I gather they were not on the actual release tape, but then again no one from made so much as a peep about my posting. The files don't have any copyright notices, so... Unless I get an objection from Sun in the next week or so, I'll post my patched versions, which actually are much more Macintosh-like than the ones from Sun. Lawyers, here's your chance... :-). Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Thu Aug 11 03:26:43 1988 Date: Thu, 11 Aug 88 03:26:43 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS terminal emulators + other sunview baggage From: unmvax!intvax!diegert@ucbvax.Berkeley.EDU (Carl F. Diegert) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) If you have a Sun with two frame buffers (and two monitors), you can have your NeWS and your suntools too! Run suntools on each frame buffer, run adjscreens, then run "overview -w news_server" on one. Now you can slide over to your good-old vi suntools window, etc. From don@brillig.umd.edu Thu Aug 11 03:27:20 1988 Date: Thu, 11 Aug 88 03:27:20 EDT To: NeWS-makers@brillig.umd.edu Subject: real constants From: unmvax!intvax!diegert@ucbvax.Berkeley.EDU (Carl F. Diegert) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) potemkin% psh dbgstart Debugger installed. Installing executive. Welcome to NeWS Version 1.1 % the following is as I expected.. 1.0 10000.0 div = 1e-4 % the following isn't.. 0.0001 = 0 0.0001 cvr = 9.155273e-5 8878 cvr dup = 0.0001 mul = 8878 0.8128051 Is is me that's doing something stupid? From don@brillig.umd.edu Thu Aug 11 03:28:13 1988 Date: Thu, 11 Aug 88 03:28:13 EDT To: NeWS-makers@brillig.umd.edu Subject: Looking for good books on NeWS programming From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Are there any good books on NeWS programming? I've been working from the documentation that comes with the Sun NeWS release, but it's really pretty pathetic. I mean, stuff like "This list does not describe the arguments to these functions. You should look at the header file for the complete form of the function" just doesn't cut it, especially when the "header file" is some of the ugliest #define hackery I've ever seen. Even the SunView documentation was better than this. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Thu Aug 11 03:33:18 1988 Date: Thu, 11 Aug 88 03:33:18 EDT To: NeWS-makers@brillig.umd.edu Subject: Bugs in NeWs documentation From: phri!roy@nyu.edu (Roy Smith) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) As a followup to my recent flamage about the NeWS documentation I want to point out two specific mistakes, one just ugly and embarrassing, the other horribly confusing and inexcusable. Both give you the distinct impression that they were really rushing to push the docs out the door and didn't have the time to do it right. 1) On page 215 of the "NeWS 1.1 Manual" (the CPS man page), the description of the -i option reads, "... For example, and would be defined in the second file." This isn't so bad; once you've puzzled over it for a minute, it becomes obvious that some text is missing and it's easy enough to go to the man page source file and see what happened. It looks like somebody ran the man pages off with the wrong macro package. Not fatal, but not something I'd be proud to ship to a customer. 2) On page 47 of the "NeWS Application Scenario", the cps source code is listed for go4.cps. IT'S WRONG! The end of the definition for draw_board reads "... } for stroke } def" in the manual, but if you go to the actual file Sun supplies (/usr/NeWS/clientsrc/app_guide/go/go4.cps, you see: /draw_board { % - => - (draw the playing surface) board_color setcolor clippath fill line_color setcolor 0 1 BOARD_MAX { dup 0 moveto 0 BOARD_MAX rlineto 0 exch moveto BOARD_MAX 0 rlineto } for stroke pause } def Note the "pause" stuck in after the "stroke"! For someone struggling to figure out how this all works by building an application based on the examples given, crap like this can really ruin your day (I'm still trying to figure out which version of the code is the correct one). Isn't the sample code in the manual imported directly from the working source files? If yes, then how could a line of code be left out? If no, then why not? Hey folks (you NeWS people at Sun are reading this, aren't you?), I'm sorry if I sound so pissed, but this whole NeWS deal is really making my opinion of Sun take a nosedive. I know I only paid $100 for the package, but that's not the point. Before we ordered NeWS, I had a longish talk with my salescritter about it. The talk went something like this: Me: Sure, NeWS sounds like the way to go (and the way of the future) but I'm not interested in playing with a beta test release. Critter: No, no, no, this isn't beta test. Me: But I keep hearing about all these various bugs people keep finding and stuff like that. I'd just as soon wait for the real thing. Critter: This is the real thing; what we're shipping now is a production-quality system, with all the wrinkles ironed out, and it's N (for some random value of N which I can't remember now) times faster than the 1.0 release. Sorry Sun, but this just doesn't cut it. The idea is neat, perhaps even wonderful. But the implementation is slow, buggy, and incomplete (running dbxtool, for example, under news does work, but it's hardly what I'd call convenient). The documentation is just as bad; confusing, incomplete, and in some case, just plain WRONG. The pity of it all is that all you needed to do to get a happy customer (me) was to tell me all this when I bought it. If my salescritter had just said told me "yes, it's a lot better than 1.0, but it's not really production quality yet; that'll be version 1.2" at least I would have known what I was getting into. Maybe I wouldn't have bothered, but if I didn't, I certainly would have bought the next release, and presumably been happy with it because it would have worked. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" From don@brillig.umd.edu Thu Aug 11 03:34:29 1988 Date: Thu, 11 Aug 88 03:34:29 EDT To: NeWS-makers@brillig.umd.edu Subject: Books on NeWS From: hanauma!rick@labrea.stanford.edu (Richard Ottolini) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) A NeWS book will be published later this year, probably around the time Sun releases combined NeWS/X11. It is by the architect of NeWS, Jim Gosling, and two others. From don@brillig.umd.edu Thu Aug 11 03:37:06 1988 Date: Thu, 11 Aug 88 03:37:06 EDT To: NeWS-makers@brillig.umd.edu Subject: Mailbox monitor for NeWS From: elwell@tut.cis.ohio-state.edu (Clayton Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) This little program, while less flashy than some that have come by in this newsgroup, is quite useful. You give it a pair of x and y coordinates, and it puts up an icon showing whether or not you have mail. It could be made smarter, but it works. -----------------------------CUT HERE--------------------------------- #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # psbiff.c # psbiff.cps # This archive created: Wed Aug 10 15:27:43 1988 export PATH; PATH=/bin:$PATH if test -f 'psbiff.c' then echo shar: will not over-write existing file "'psbiff.c'" else cat << \SHAR_EOF > 'psbiff.c' #include #include #include #include #include #include "psbiff.h" char mailbox[80]; struct passwd *pw; struct stat st; main(argc, argv) int argc; char **argv; { long t; int x, y; if (argc < 3) { fprintf(stderr, "usage: psbiff x y"); exit(1); } x = atoi(argv[1]); y = atoi(argv[2]); ps_open_PostScript(); initialize(x, y); ps_flush_PostScript(); pw = getpwuid(getuid()); sprintf(mailbox, "/usr/spool/mail/%s", pw->pw_name); for (;;) { time(&t); sleep(10); if (stat(mailbox, &st)) { nomail(); } else if (t <= st.st_mtime) { newmail(); } else if (st.st_size > 0) oldmail(); else nomail(); ps_flush_PostScript(); } ps_close_PostScript(); } SHAR_EOF fi # end of overwriting check if test -f 'psbiff.cps' then echo shar: will not over-write existing file "'psbiff.cps'" else cat << \SHAR_EOF > 'psbiff.cps' %! cdef initialize(x,y) newprocessgroup /icon framebuffer newcanvas def /xcurs /xcurs_m icon setstandardcursor gsave framebuffer setcanvas 0 0 64 64 rectpath icon reshapecanvas grestore icon /Retained true put icon setcanvas x y movecanvas /destroy { icon /Mapped false put currentprocess killprocessgroup } def /slide { gsave icon setcanvas InteractionLock { interactivemove } monitor grestore } def [ /DoItEvent { gsave /ClientData get cvx exec grestore } /Window null eventmgrinterest AdjustButton { slide } DownTransition icon eventmgrinterest ] forkeventmgr /mailimage 64 64 1 [64 0 0 -64 0 64] { } buildimage def /nomailimage 64 64 1 [64 0 0 -64 0 64] { } buildimage def gsave textcolor setcolor 64 64 scale false nomailimage imagemaskcanvas backgroundcolor setcolor true nomailimage imagemaskcanvas grestore icon /Mapped true put cdef oldmail() icon setcanvas gsave textcolor setcolor 64 64 scale false mailimage imagemaskcanvas backgroundcolor setcolor true mailimage imagemaskcanvas grestore cdef nomail() icon setcanvas gsave textcolor setcolor 64 64 scale false nomailimage imagemaskcanvas backgroundcolor setcolor true nomailimage imagemaskcanvas grestore cdef newmail() icon setcanvas gsave backgroundcolor setgray 64 64 scale false mailimage imagemaskcanvas textcolor setgray true mailimage imagemaskcanvas grestore SHAR_EOF fi # end of overwriting check # End of shell archive exit 0 Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Thu Aug 11 03:38:39 1988 Date: Thu, 11 Aug 88 03:38:39 EDT To: NeWS-makers@brillig.umd.edu Subject: can't talk(1) in psterm From: Eric Marshall Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) ya just can't. Eric Marshall Software Productivity Consortium 1880 North Campus Commons Drive Reston, VA 22091 (703) 391-1838 CSNET: marshall@software.org ARPANET: marshall%software.org@relay.cs.net OR @relay.cs.net:marshall@software.org From don@brillig.umd.edu Thu Aug 11 03:39:36 1988 Date: Thu, 11 Aug 88 03:39:36 EDT To: NeWS-makers@brillig.umd.edu Subject: A Fontal Lobotomy ? From: mcvax!unido!ecrcvax!andy@uunet.uu.net (Andrew Dwelly) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've been playing around with the fonts supplied with NeWS 1.1 and seem to be having rather a problem with Times-Roman. Scaling it to 20 (pixels) and then using it to show a small piece of text seems to print out quite a lot of rubbish. Almost as if some other text were being printed first, and then only partially erased by the "real" text. I know NeWS is generally held to be a touch flakey in the area of font scaling, rotation etc. Am I seeing an example of this, or could there be some other explanation ? (corrupt fonts ? something worse ?) Andy Andrew Dwelly E.C.R.C. UUCP: mcvax!unido!ecrcvax!andy ArabellaStrasse 17 or pyramid!ecrcvax!andy D-8000 Muenchen 81, West Germany UUCP Domain: andy@ecrcvax.UUCP [Bump, Crash ...... Listen; who swears ? Christopher Robin has fallen down stairs.] From don@brillig.umd.edu Thu Aug 11 03:39:57 1988 Date: Thu, 11 Aug 88 03:39:57 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Bugs in NeWs documentation From: mcvax!unido!ecrcvax!johng@uunet.uu.net (John Gregor) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <3426@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >As a followup to my recent flamage about the NeWS documentation I >want to point out two specific mistakes, Also the entry for 'fork' is missing in my manual. It should be on page 138 next to 'forkunix.' -- John Gregor johng%ecrcvax.UUCP@pyramid.COM From don@brillig.umd.edu Fri Aug 12 08:40:45 1988 Date: Fri, 12 Aug 88 08:40:45 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: A Fontal Lobotomy ? From: salt.uucp!gerber@uunet.uu.net (Andrew Gerber) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <611@ecrcvax.UUCP> andy@ecrcvax.UUCP (Andrew Dwelly) writes: > >I know NeWS is generally held to be a touch flakey in the area of font >scaling, rotation etc. Am I seeing an example of this, or could there >be some other explanation ? (corrupt fonts ? something worse ?) > > Andy > >Andrew Dwelly >E.C.R.C. UUCP: mcvax!unido!ecrcvax!andy >ArabellaStrasse 17 or pyramid!ecrcvax!andy >D-8000 Muenchen 81, West Germany UUCP Domain: andy@ecrcvax.UUCP I don't know about the problem you mentioned, but we have had a problem with text rotation on our Sun 3/50's. The funny thing is, the same code works great on the 4/110. Instead of roating an entire line of text, the sun 3/50 rotates only single characters, making them look like they are dancing. Anyone else noticed this problem? ----------------------------------------------------------------------------- Andrew S. Gerber | McDonnell Douglas Communication Industry Systems uunet!salt!gerber | 5299 DTC Blvd, Englewood, CO 80111 salt!gerber@uunet.uu.net | (303) 220 6231 ----------------------------------------------------------------------------- From don@brillig.umd.edu Fri Aug 12 08:40:50 1988 Date: Fri, 12 Aug 88 08:40:50 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: mcvax!ritd.co.uk!mr@uunet.UU.NET Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'd like to endorse the item from Charles Hedrick *especially* the comment about the window of opportunity for NeWS closing rapidly. I really hope that Sun responds to this message (but don't hold out much hope :-(). Martin Reed, Racal Imaging Systems Ltd +--------------------------------------------------------+ |uucp: mr@ritd.co.uk,{mcvax!ukc!ritd,sun!sunuk!brains}!mr| `Just hold |Global String: +44 252 622144 | these two |Paper: 309 Fleet Road, Fleet, Hants, England, GU13 8BU | wires...' +--------------------------------------------------------+ Nobody is responsible for anything I say. Including me. From don@brillig.umd.edu Fri Aug 12 08:41:38 1988 Date: Fri, 12 Aug 88 08:41:38 EDT To: NeWS-makers@brillig.umd.edu Subject: real constants From: Paul Hudson Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Real constants aren't always real under NeWS of course. Are you suffering from SUN's attempt at fixed point? (I've no way of checking: we don't run NeWS). Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ From don@brillig.umd.edu Fri Aug 12 08:47:56 1988 Date: Fri, 12 Aug 88 08:47:56 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Printing from NeWS From: dwf%beta@LANL.GOV (Dave Forslund) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Your might try looking at the code in gnuplot and surfmodl on tumtum.cs.umd.edu Both provide examples of how to do this. Dave Forslund Los Alamos National Laboratory (dwf@lanl.gov) From don@brillig.umd.edu Fri Aug 12 08:48:09 1988 Date: Fri, 12 Aug 88 08:48:09 EDT To: NeWS-makers@brillig.umd.edu Subject: Simple mouse/menu access From: att!ihnp4!ihlpf!warren@ucbvax.Berkeley.EDU (Montgomery) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I face a problem when porting an application into a new windowing system that strikes me as common, but few windowing systems provide a good solution for. My appliction would like to use the mouse for pointing and menues, and take explicit control of a scrollbar if provided, but would otherwise like to treat the screen like a terminal. Most windowing systems seem to offer me the choice of running my application under a terminal emulator (e.g. xterm, shelltool) that provides no access to the mouse and no control of the scrollbar, or running directly on the windowing system, which requires that I explicitly paint the screen using calls to the windowing library instead of escape sequences and usually requires that my application be re-structured to be event driven, which isn't very natural for it. What I'd really like is: Changes in the mouse buttons reported via escape sequences in the same input stream as the keyboard. Mouse position either reported with the button events or available via a function call. Some way of presenting menues, either by specifying in advance that a certain button is for menues, giving a menu, and having the selection reported in the input stream, or by having some function that puts up a menu and returns a selection invokable after a mouse push. Explicit control over any scrollbars, either through an escape sequence that controls where the bar is displayed or through a function call that does it. Mouse pushes in the scroll bar would be reported in the same way as other mouse pushes, perhaps with different encoding. The closest thing I have seen to this is the windowing system on the Unix PC, which can be set up to report mouse events the way I'd like and provides the ability to put up a menu, but I have yet to see comparable things for X, News, or Sunview. Any suggestions? -- Warren Montgomery ihlpf!warren From don@brillig.umd.edu Fri Aug 12 08:48:16 1988 Date: Fri, 12 Aug 88 08:48:16 EDT To: NeWS-makers@brillig.umd.edu Subject: Creating new icon fonts - Help required From: mcvax!ukc!strath-cs!glasgow!cathy@uunet.uu.net (Catherine Anne Wood) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is there an easy way to incorporate new icons into NeWS ? At the moment the only way I can see is to generate a new icon font ... and that seems to have its problems. I want to be able to use icons I design with the SunView icon editor. I have managed to create a new icon font using the procedure described in the manual (Chapter 16) but still have two problems : a) Having created my own font how do I use BOTH it and the standard icon font. I want to create items using both fonts. What I really want is to be able to dynamically alter the font used to create items so I (and other users of my system) can have different fonts for different uses. b) Any changes made to the font after NeWS has been started up are unavailable until the next time NeWS is loaded. There is a routine "findfilefont" - Reads the font family file named by the string and constructs and returns a font object that refers to it Which the manual says is the routine to use to have a font loaded into NeWS after it has started up. However I cannot get this to work - it keeps giving the error "invalidfont". The font does however work okay if I stop NeWS and restart it. Is there an easier way !!!! - Am I going about this the hard way ? ARPANet: cathy%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk JANET: cathy@uk.ac.glasgow.cs UseNet: mcvax!ukc!cs.glasgow.ac.uk!cathy Mail: Cathy Wood, Computer Science, 17 Lilybank Gardens, GB-GLASGOW G12 8QQ From don@brillig.umd.edu Tue Aug 16 00:22:09 1988 Date: Tue, 16 Aug 88 00:22:09 EDT To: NeWS-makers@brillig.umd.edu Subject: caPitAl In News From: toms@ncifcrf.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Mike Wolfe's suggestion for how to avoid those AwFuLl CaPiTalS > I pronounce it "Snooze" as in "Sun NeWS", try it, it fits. is great! How about writing it out as 'sunews'? Tom Schneider toms@ncifcrf.gov From don@brillig.umd.edu Tue Aug 16 00:22:27 1988 Date: Tue, 16 Aug 88 00:22:27 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Creating new icon fonts - Help required From: ichthyosaur.cis.ohio-state.edu!elwell@tut.cis.ohio-state.edu (Clayton M. Elwell) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) cathy@cs.glasgow.ac.uk (Catherine Anne Wood) writes: Is there an easy way to incorporate new icons into NeWS ? At the moment the only way I can see is to generate a new icon font ... and that seems to have its problems. Well, I've played with this a little. What I did was to create a new window class that (among other things) overrides the standard PaintIcon method. If the window's IconImage is a name, it just shows the icon as usual. If it's a canvas, though, it paints it using 'imagemaskcanvas' if it's monochrome or 'imagecanvas' if it's color. This lets you have multicolored icons on a color display. This way, too, the new icons can be compiled into your program (using buildimage), so that new users don't have to make sure that they have a new font installed. Clayton M. Elwell Ohio State University CIS Dept. Research Computing Facility "... there was a *third* possibility that we hadn't even counted upon ..." --Arlo Guthrie, "Alice's Restaurant" From don@brillig.umd.edu Tue Aug 16 00:23:20 1988 Date: Tue, 16 Aug 88 00:23:20 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Bugs in NeWs documentation From: cca.ucsf.edu!ccb.ucsf.edu!dick@cgl.ucsf.edu (Dick Karpinski) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The NeWS and the Open Look documentation is said to refer to the local graphics device as a window server and the distant applications engine as a window client. I am fully aware that this makes good sense when you understand the mechanism. However, I am acutely aware that novices find this confusing. The local thing is client. The distant thing is server. Don't confuse me. Don't confuse me with facts or opinions. My workstation is me or my agent. Distant hosts serve me and my agent. Change the terminology pronto. Please. We did it wrong with electricity. Electrons got to be negative because we didn't know better when we assigned plus and minus. We humans operate as association engines. The term "negative" has, if I may, negative connotations. I claim that this error in naming has had negative consequences for centuries. Let us try to avoid such problems with our newest technologies. Please don't tell me it is too late to change, now. I know it will be expensive to rewrite those details in the documentation, but not fixing this will plague us for years if not decades whenever we bring another novice into our world. In considering how to accomplish the change, I conclude that the terms server and client should be abandonned in favor of new terms which comply better with the novice user's image of the situation. Perhaps the local device should be the window agent and the distant one be the application vendor or provider. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797 From don@brillig.umd.edu Tue Aug 16 00:23:38 1988 Date: Tue, 16 Aug 88 00:23:38 EDT To: NeWS-makers@brillig.umd.edu Subject: YinYang bug... From: gregm@Sun.COM (Greg McLaughlin) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There is a small bug in the YinYang root spin routine sent out a while back. Once awaitevent returns it needed to pop the unused event. If run long enough the NeWS stack would overflow. Here is the patched version: Greg McLaughlin Sun Microsystems Inc. ----------------------------TimeYinYang---------------------------------- % Set the yin/yang to spin by queuing events. /TimeYinYang { % - => process { /d 2 dict dup begin /RotateYinYang { /YinYangAng YinYangAng 5 add store % change the 5 to adjust % the speed gsave framebuffer setcanvas YinYangAng 160 60 yinyang grestore SendNewYinYangEvent } def end def /e1 createevent def e1 /Name d put e1 expressinterest /SendNewYinYangEvent { e1 createevent copy dup begin /Name /RotateYinYang def /TimeStamp currenttime .05 add def end sendevent } def SendNewYinYangEvent { awaitevent pop} loop } fork } def From don@brillig.umd.edu Tue Aug 16 23:17:20 1988 Date: Tue, 16 Aug 88 23:17:20 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS operators: arccos, arcsin, arctan From: steinmetz!vdsvax!montnaro@itsgw.rpi.edu (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Can somebody explain why the NeWS operators arc{cos,sin,tan} aren't named or written in the same spirit as the PostScript atan operator? -- Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa) From don@brillig.umd.edu Tue Aug 16 23:17:30 1988 Date: Tue, 16 Aug 88 23:17:30 EDT To: NeWS-makers@brillig.umd.edu Subject: Macpaint-like psh script (source included) From: mahendo!wlbr!mh@elroy.jpl.nasa.gov (Mike Hoegeman) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I started whipping this up over last weekend but had to stop once monday rolled around and I had to start doing real work again. Whenever I add anything substantial I'll repost it. Below are some comments that I gleaned from section of code further down. You should be able to run this whole file thru psh. comments, suggestions, flames can be mailed to me at mike@etn-wlv.eaton.com or ...ihnp4|scgvax!wlbr!mh -Mike Hoegeman ------ cut here ------ #!/usr/NeWS/bin/psh % paintdemo.ps % Author: Mike Hoegeman (mike@etn-wlv.eaton.com) % Function: simple window dressing for demoing the PaintCan object with % % Notes: % The Calling syntax is as follows... % paintdemo [rasterfilename] % if is not supplied, a dialog box pops up to % allow the user to read in an input file. % paintcan.ps % Function: % % Beginnings of macpaint-like canvas object. Definitely not finished but is does % work. PaintCan is intentionally not a window so you can wrap it in any kind of % window dressing (har-dee-har-har) you prefer. The paintprog module is a % simple example... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% /FILENAME ($1) def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %+ % createcolormenu: proc => - % Function: creates a color menu which executes proc with the selected color on the stack %- /createcolormenu { [ %% make a row of greyscale type color boxes 1 dup dup rgbcolor [exch {colorsquare}] .925 dup dup rgbcolor [exch {colorsquare}] .875 .125 neg .250 { dup dup rgbcolor [exch {colorsquare}] } for %% then extract the colors out of colordict ColorDict { exch pop [exch {colorsquare}] } forall ] [ {currentkey 0 get user_proc exec} ] /new LitePullRightMenu send dup { %% => user_proc inst /user_proc 3 -1 roll cvx def /colorsquare { % parallax board likes eofill much better! /paint eq { 20 20 rect setcolor eofill } { pop 20 20 } ifelse } def /LayoutStyle [7 ColorDict length 1 index div ceiling exch 1 add] def /StrokeSelection? true def /CellHorizGap 2 def /CellVertGap 2 def %%/RetainCanvas? true def } exch send } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %+ % Module: paintcan.ps % Author: Mike Hoegeman % Function: % % Beginnings of macpaint-like canvas object. Definitely not finished but is does % work. PaintCan is intentionally not a window so you can wrap it in any kind of % window dressing (har-dee-har-har) you prefer. The paintprog module is a % simple example... % % You may have to change some of the file names below... % % Notes: % Modification History: % Date Author Reason % ------------------------------------------------------------- % 10Jun88 MCH Initial Release. % ------------------------------------------------------------- %- %RUN%(/u/mike/paint/menu.ps) run /PaintCan Object dictbegin %+ % Instance variables % ------------------ %- /EventMgr nulldict def %% contains event mgr process /Interests nulldict def /User nulldict def %% place for user to stash things if they wish /OperationMenu nulldict def /MiscMenu nulldict def /TopMenu nulldict def %% Top level menu for paintcanvas... /XMenu nulldict def %% child menus... /PointMenu nulldict def /ToolMenu nulldict def /ColorMenu nulldict def /ModeMenu nulldict def /InputFile (/usr/tmp/paintfile) def /OverLayCanvas nulldict def %% /DisplayCanvas nulldict def %% Display Canvas /DetailCanvas nulldict def %% used when in detail mode (not implemented yet....) /BufCanvas nulldict def %% Buffer Canvas /ParentCanvas nulldict def %% Parent to DisplayCanvas and BufCanvas /ObjPath { rectpath } def %% proc which builds shape of the paintcan /MsgProc { dbgprintf } def %% %+ % The SaveStyle instance variable designates when automatic saves are to be done. % The following are valid: % % /before_each_operation - % /at_toolchange - %- /SaveStyle /at_toolchange def /ObjX 0 def %% x y w and h of the paintcan /ObjY 0 def /ObjW 0 def /ObjH 0 def %% These guys hold the current painting parameters /RoundOff 1 def /PointSize 1 def /ForeColor 0 0 0 hsbcolor def %% current color /LineCap 1 def /LineJoin 1 def /LineMitre 1 def %% describes the current painting operation we are doing %% current ops available are... %% /do_stroke /do_fill %% /CurrentOperation /do_stroke def %% describes the way we perform CurrentOp %% current tools available are... %% /pencil /oval /rectangle /line /polygon %% /CurrentTool /pencil def %% All Operations are started by a /DownTranstion on PointButton %% defines what Op to do when a mouse down is hit for PointButton %% /StartOpProc { CurrentOperation CurrentTool FollowDrag } def dictend classbegin % ---- Class variables % ---- Methods /MenuClass LitePullRightMenu def /RXLocation { XLocation RoundOff neg and } def /RYLocation { YLocation RoundOff neg and } def /LineWidth { PointSize } def /drawbegin { gsave DisplayCanvas setcanvas %% line stuff 1 setlinequality 30 setmiterlimit LineCap setlinecap LineJoin setlinejoin LineWidth setlinewidth %% color stuff ForeColor setcolor } def /drawend { grestore } def %% filename | null => - %% /read { 1 dict begin /inputfile exch dup null eq { pop InputFile } if def CheckCanvases gsave DisplayCanvas setcanvas clippath pathbbox scale pop pop { inputfile readcanvas pause } errored { pop (error reading file %\n) [inputfile] MsgProc } { imagecanvas } ifelse grestore end } def %% filename | null => - %% /write { 1 dict begin /outfile exch dup null eq { pop InputFile } if def gsave { newpath DisplayCanvas setcanvas outfile writecanvas } errored { (could not write to file %\n) [outfile] MsgProc } { %% } ifelse grestore end } def %+ %- /savetobuffer { gsave BufCanvas setcanvas clippath pathbbox scale pop pop DisplayCanvas imagecanvas grestore } def /save? { SaveStyle eq { savetobuffer } if } def /undo { 1 dict begin /tmp DisplayCanvas def /DisplayCanvas BufCanvas store /BufCanvas tmp store end DisplayCanvas /Mapped true put BufCanvas /Mapped false put CreateInterests CreateOverLayCanvas } def /CreateMenus { TopMenu nulldict eq { /ToolMenu [ (Pencil) {{/at_toolchange save? /CurrentTool /pencil def} ThisPaintCan send} (Line) {{/at_toolchange save? /CurrentTool /line def} ThisPaintCan send} (Rectangle) {{/at_toolchange save? /CurrentTool /rectangle def} ThisPaintCan send} (Polygon) {{/at_toolchange save? /CurrentTool /polygon def} ThisPaintCan send} (Oval) {{/at_toolchange save? /CurrentTool /oval def} ThisPaintCan send} ] /new MenuClass send def { /RowMajor? false def /StrokeSelection? true def /CenterItems? false def } ToolMenu send /OperationMenu [ (Stroke) { {/CurrentOperation /do_stroke def} ThisPaintCan send } (Fill) { {/CurrentOperation /do_fill def} ThisPaintCan send } ] /new MenuClass send def { /RowMajor? false def /StrokeSelection? true def /CenterItems? false def } OperationMenu send /MiscMenu [ (Set Grid) { { /RoundOff PointSize def } ThisPaintCan send } (Save) { /savetobuffer ThisPaintCan send } %% SaveMenu ] /new MenuClass send def { /CenterItems? false def } MiscMenu send /ColorMenu { {/ForeColor exch store} ThisPaintCan send } createcolormenu store XMenu nulldict eq { /XMenu [ (Undo) { /undo ThisPaintCan send } (Save To Buffer) { /savetobuffer ThisPaintCan send } ] /new MenuClass send def } if /PointMenu [(1) (2) (4) (6) (8) (10) (12) (14) (16) (18) (20) (24) (32) (64)] [ { currentkey cvi {/PointSize exch store} ThisPaintCan send } ] /new MenuClass send def { /LayoutStyle [2 7] def /CellHorizGap 5 def } PointMenu send /TopMenu [ (Point Size) PointMenu (Tool) ToolMenu (Operation) OperationMenu (Colors) ColorMenu (Misc) MiscMenu /sun30 XMenu ] /new MenuClass send store { /LayoutStyle /Horizontal def /CellHorizGap 4 def /PullRightDelta 0 def /Border 2 def /CenterItems? true def } TopMenu send } if } def /CreateOverLayCanvas { /OverLayCanvas DisplayCanvas createoverlay def } def /CreateCanvases { BufCanvas nulldict eq { /DisplayCanvas ParentCanvas newcanvas store DisplayCanvas begin /Retained true def /Transparent false def end /BufCanvas ParentCanvas newcanvas store BufCanvas begin /Retained true def /Transparent false def end gsave ParentCanvas setcanvas ObjX ObjY translate 0 dup ObjW ObjH rectpath DisplayCanvas reshapecanvas 0 dup ObjW ObjH rectpath BufCanvas reshapecanvas grestore CreateOverLayCanvas } if } def /do_stroke { stroke } def /do_fill { eofill } def /rectangle { { points2rect rectpath } bb } def /oval { { points2rect ovalpath } bb } def /line { { 4 2 roll moveto lineto } bb } def %+ % bb: event operation pathproc => bool % Function: back-end to the /rectangle, /oval, and /line procs... %- /bb { 2 dict begin /pathproc exch def /operation exch def begin EventMgrDict /x0 known { Name PointButton eq Action /UpTransition eq and { erasepage %% got the terminating mouse up so we are all done dragging , %% now figure out what we are supposed to do with the bounding box %% we've built.. operation { /do_fill /do_stroke { DisplayCanvas setcanvas EventMgrDict begin x0 y0 end RXLocation RYLocation pathproc operation cvx exec } /Default {} } case false %% tell FollowDrag to stop.. }{ OverLayCanvas setcanvas erasepage EventMgrDict begin x0 y0 end RXLocation RYLocation pathproc stroke true %% tell FollowDrag to keep going } ifelse }{ %% set the x0,y0 of the bounding box we are building... %% Name PointButton eq Action /DownTransition eq and { EventMgrDict dup /x0 RXLocation put /y0 RYLocation put } if true %% keep going.. } ifelse end % event end } def %% event operation => bool /pencil { 1 dict begin /operation exch def begin %eventdict Name /MouseDragged eq EventMgrDict /LastX known and { operation /do_stroke eq { EventMgrDict begin LastX LastY end moveto RXLocation RYLocation lineto stroke } { gsave EventMgrDict begin LastX LastY end moveto RXLocation RYLocation lineto stroke grestore RXLocation RYLocation lineto } ifelse } { operation /do_stroke ne { RXLocation RYLocation moveto } if } ifelse %% See if we are done penciling. %% If we are not doing a stroke we've been constructing a path %% and drawing it on an overlay. now we gotta take the path %% and perform the desired operation on the display %% Action /UpTransition eq Name PointButton eq and % if we're done and we're not stroking.... dup operation /do_stroke ne and { %% operation uses the currentpath operation cvx exec } if not %% our return value for FollowDrag.... EventMgrDict dup /LastX RXLocation put /LastY RYLocation put end % eventdict end %scope dict } def /polygon { {} poly_bb } def %%%% utilities used by poly_bb %+ % poly_buildpath: [ [x y].... [xN yN] ] => - % Function: take an array of x y points and build a line segment path out of them %- /poly_buildpath { dup 0 get aload pop moveto 0 arraydelete { aload pop lineto } forall } def /ending_segment { %% (ending polygon segment...\n) [] MsgProc erasepage EventMgrDict begin %% add the segment we just finished to the %% polygon path that we are building.. currentcanvas DisplayCanvas setcanvas /points points [[RXLocation RYLocation]] append def setcanvas %% paint what we've got so far on the Overlay.. points poly_buildpath end %% EventMgrDict operation cvx exec } def %+ % poly_bb: event operation pathproc => bool % Function: %- /poly_bb { 3 dict begin /pathproc exch def /operation exch def begin % event %% 'till we get a mouse down on the point button, don't do anything... EventMgrDict /points known { Name [ MenuButton { %% hitting the menu button while constructing the polygon cancels the construction erasepage false %% return val } PointButton { Action /DownTransition eq { ending_segment } if true %% return val } AdjustButton { Action /DownTransition eq { ending_segment %% (polygon end...\n) [] MsgProc erasepage DisplayCanvas setcanvas %% build the path EventMgrDict /points get poly_buildpath %% paint the path... operation cvx exec } if false %% return val } MouseDragged { %% (polygon feedback...\n) [] MsgProc %DisplayCanvas setcanvas %EventMgrDict begin x0 y0 end RXLocation RYLocation %OverLayCanvas setcanvas %erasepage %gsave pathproc stroke grestore true %% return val } /Default { %% Some event we don't care about (at the moment) (??? % % [%-%] \n\n) [Name Action XLocation YLocation] MsgProc true %% return val } ] case }{ Name PointButton eq Action /DownTransition eq and { %%% (% % polygon init...\n) [Name Action] MsgProc %% starting the polygon DisplayCanvas setcanvas EventMgrDict /points [ [RXLocation RYLocation] ] put OverLayCanvas setcanvas } if true %% return val } ifelse end %% event end %% scope dict } def /FollowDrag { 4 dict begin /proc exch cvx def /operation exch def /EventMgrInit { drawbegin } def %% if at any time proc returns false we stop this event tracking %% process .03 blockinputqueue [ %% also give proc any ensuing mouse drags and mouse ups [PointButton AdjustButton] { operation proc exec not { currentprocess killprocess }{ } ifelse } [/DownTransition /UpTransition] DisplayCanvas eventmgrinterest /MouseDragged { operation proc exec not { currentprocess killprocess } if } null DisplayCanvas eventmgrinterest ] forkeventmgr %% => event process exch unblockinputqueue redistributeevent waitprocess end } def /CreateInterests { EventMgr nulldict ne { %% kill any old event mgr... EventMgr killprocess /EventMgr nulldict store } if /Interests 4 dict begin %% leave room for subclassing... /MenuEvent MenuButton %% event name {/showat TopMenu send} %% eventproc /DownTransition %% Action DisplayCanvas %% canvas eventmgrinterest def /StartOpEvent PointButton { %% => event %% turn off this interest while we do StartOpProc Interests /StartOpEvent get /Name /__funky_stuff__ put Interests /MenuEvent get /Name /__funky_stuff__ put /before_each_operation save? StartOpProc Interests /StartOpEvent get /Name PointButton put Interests /MenuEvent get /Name MenuButton put } /DownTransition DisplayCanvas eventmgrinterest def currentdict end def /EventMgr Interests forkeventmgr def } def %+ % new: x y w h parentcanvas => - %- /new { /new super send begin /ParentCanvas exch def /ObjH exch def /ObjW exch def /ObjY exch def /ObjX exch def currentdict end } def /map { CheckCanvases DisplayCanvas /Mapped true put } def /unmap { DisplayCanvas null ne { DisplayCanvas /Mapped true put } if } def %+ % Function: return the bounding box of the displaycanvas %+ /bbox { ObjX ObjY ObjW ObjH } def /destroy { DisplayCanvas nulldict ne { DisplayCanvas nukeinterests % to insure we GC everything... [/BufCanvas /DisplayCanvas /User] { nulldict exch store } forall EventMgr killprocess } if } def %+ % Function: Implements deferred initialization of the canvases %- /CheckCanvases { DisplayCanvas nulldict eq { CreateCanvases CreateMenus CreateInterests } if } def %+ % reshape: x y w h => - %- /reshape { /ObjH exch def /ObjW exch def /ObjY exch def /ObjX exch def gsave ParentCanvas setcanvas ObjX ObjY translate [BufCanvas DisplayCanvas] { 0 0 ObjW ObjH ObjPath reshapecanvas } forall grestore } def %+ % move: x y => - % function: Move the canvas to location x y (relative to it's parent) %- /move { gsave initmatrix /ObjY exch def /ObjX exch def ObjX ObjY DisplayCanvas setcanvas movecanvas grestore } def classend def %% end of class definition %+ % Utilities %- /ThisPaintCan { null sendstack { dup /DisplayCanvas known { exch pop exit } { pop } ifelse } forall } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %+ % nuke-interests: can => - % recursively cleans up any interests left laying around for any % canvas "can" and all it's children. good for use before destroying a % object. (courtesy of Don Hopkins) %- /nukeinterests { begin %% Clear out the parent Interests {revokeinterest} forall %% Clear out each child (recursively) TopChild { dup null eq {pop exit} if dup nukeinterests /CanvasBelow get } loop end } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %+ % Module: paintdemo % Author: Mike Hoegeman (mike@etn-wlv.eaton.com) % Function: simple window dressing for demoing the PaintCan object with % % Notes: % The Calling syntax is as follows... % paintdemo [rasterfilename] % if is not supplied, a dialog box pops up to allow the user to read % in an input file. % % Modification History: % Date Author Reason % ------------------------------------------------------------- % 10Feb88 MCH Initial Release. % ------------------------------------------------------------- %- %RUN%(/u/mike/paint/paintcan.ps) run /PaintWindow LiteWindow [] classbegin %% Methods /destroy { %% make sure we get everything GC'ed FrameCanvas nukeinterests /destroy super send } def classend def /main { /win framebuffer /new PaintWindow send def { /FrameLabel (PaintCan Demo) def /PaintClient {ColorDict /LightGrey get fillcanvas} def /BorderLeft 4 def /BorderRight 4 def /BorderBottom 4 def } win send 0 0 656 508 /reshape win send /map win send { /reshape {} def /reshapefromuser {} def %% make the paint canvas.. pause /PCan 4 4 640 480 ClientCanvas /new PaintCan send def { %% some menu mashing here to redo the Xmenu %% redefine XMenu /XMenu [ (Undo) { /undo ThisPaintCan send } (Save To Buffer) { /savetobuffer ThisPaintCan send } (Read From File) { { self /read do-read-write-window } ThisPaintCan send } (Save To File) { { self /write do-read-write-window } ThisPaintCan send } ] /new DefaultMenu send store } PCan send /map PCan send } win send } def %% main /rwwin nulldict def %% paintcan /read | /write => - /do-read-write-window { rwwin nulldict eq { /rwwin make_rwwin store } if { /Operation exch def /PCan exch def items /doitbutton get /ItemLabel Operation 64 string cvs put } rwwin send currentcursorlocation rwwin /FrameHeight get 2 div sub 0 max exch rwwin /FrameWidth get 2 div sub 0 max exch /move rwwin send /map rwwin send /totop rwwin send } def /make_rwwin { 1 dict begin %% create the window... /window framebuffer /new PaintWindow send def { /PCan nulldict def /Operation {} def %% set the stuff we need to set before the reshape takes place... %% (make it look sorta like a dialog box) /FrameFillColor FrameTextColor def /BorderTop 4 def /BorderLeft 4 def /BorderRight 4 def /BorderBottom 4 def /FramePath { 4 5 1 roll rrectpath } def } window send %% shape it 0 0 356 100 /reshape window send { %% disable the menu's [/ClientMenuEvent /FrameMenuEvent] { dup FrameInterests exch known { FrameInterests exch undef } { pop } ifelse } forall %% install all the stuff needed for the items /PaintClient { ColorDict /Yellow get fillcanvas items paintitems} def %% define liteitem notifier procs for the items that will live in the window... /nullnotify {} def %% make the liteitems 4 dict begin /doitbutton (Do It) /doitnotify ClientCanvas 64 0 /new ButtonItem send dup /ItemBorderColor .5 .5 .5 rgbcolor put 72 4 /move 3 index send def { /doitnotify { rwwin /Operation get { /read /write { rwwin /items get /dir_item get /ItemValue get (/) append rwwin /items get /file_item get /ItemValue get append { Operation PCan send /Operation {} def /PCan nulldict def } rwwin send /unmap rwwin send } /Default { } } case } def } doitbutton send /cancelbutton (Cancel!) /cancelnotify ClientCanvas 64 0 /new ButtonItem send dup /ItemBorderColor .5 .5 .5 rgbcolor put 4 4 /move 3 index send def { /cancelnotify { { /Operation {} def /PCan nulldict def } rwwin send /unmap rwwin send } def } cancelbutton send /dir_item (Directory:) (HOME) getenv /Right /nullnotify ClientCanvas 340 0 /new TextItem send 4 72 /move 3 index send def { /nullnotify {} def } dir_item send /file_item (File:) FILENAME /Right /nullnotify ClientCanvas 164 0 /new TextItem send 4 50 /move 3 index send def { /nullnotify {} def } file_item send currentdict end /items exch def /itemmgr items forkitems def } window send window end %localscope } def %% makerwwin %% fire up the paint window main %% if no file name supplied, ask user for one.. FILENAME () eq { win /PCan get /read do-read-write-window } if From don@brillig.umd.edu Tue Aug 16 23:17:48 1988 Date: Tue, 16 Aug 88 23:17:48 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Bugs in NeWs documentation (really: terminology confusing to novices) From: allosaur.cis.ohio-state.edu!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1327@ucsfcca.ucsf.edu> dick@ucsfccb.UUCP (Dick Karpinski) writes: > >The NeWS and the Open Look documentation is said to refer to the >local graphics device as a window server and the distant applications >engine as a window client. I am fully aware that this makes good >sense when you understand the mechanism. However, I am acutely aware >that novices find this confusing. > >The local thing is client. The distant thing is server. Don't >confuse me. Don't confuse me with facts or opinions. My workstation >is me or my agent. Distant hosts serve me and my agent. When I need to explain the window server/client relationship, I describe it in terms the user is already familiar with, and which keep things rational and consistent. In economic terms: A server allocates a scarce resource to clients who want access to parts of it. In the case of a supermarket, there are only a finite number of loaves of bread on the shelf and the supermarket manages contention between the customers (clients) who want that bread. They do it by requiring money in exchange, and throttle the demand by maintaining long lines at the checkout counter, among other things. In the case of a file server, the scarce resources are blocks on a disk. Only the server machine has direct access, every client must request portions, and the server doles them out as it sees fit, and scheduling demand between other requests as well as mine. It allocates it fairly by normal request queueing mechanisms at various levels of the protocol stack. In the case of a window server, the scarce resources are the acreage on my screen, and my input devices. There are a finite, countable number of pixels, keys, mice, and mouse buttons available. Screen space and input events are apportioned fairly by algorithms relating to geometry, overlap heirarchies, etc. (Anyone who thinks they know about time-sharing schedulers can handle this.) Once they have this much down, I generalize it yet more and say that the Cray across campus is the cycle server, but my Sun runs the window server. Each needs something the other has in order for the application to run, so each provides the other some of the resources it is uniquely best at providing. When I have to explain what's going on in a server-based window system, I find it much easier to first explain the architecture so that the audience knows just a little bit about what's going on "behind the curtains". Then they have a much better understanding of what they are really trying to do, and my phone doesn't ring with so many questions about incomprehensible error messages, etc. Explain the mechanism to the novice, and {s}he will be happier in the long run. I find this true in most technical fields that I try to explain to novices, not just with window systems. For instance, my wife is a brilliant elementary music teacher, but she never considered herself too hot at "science stuff". She now understands how our airplane flies in terms of compressible flow of air molecules over the wings, and therefore is beginning to understand how and why temperature variations affect wing and engine performance. Then she came full-circle and connected that back to "warming up" an instrument. Don't try to hide the details, if the audience really wants to know! If they build an incorrect mental model too early, it could be very hard to replace it with what's *really* happening later on. >Change the terminology pronto. Please. The terminology has been arrived at through several years of work by lots of folks in the field (not just the authors of the NeWS and Open Look documentation), and is pretty well entrenched. It is even appropriate to describe what's happening. Don't bother trying to change it now. Sorry, I've really strayed from the subject here. Oh well... -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob From don@brillig.umd.edu Fri Aug 19 12:45:42 1988 Date: Fri, 19 Aug 88 12:45:42 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Bugs in NeWs documentation From: kimba!hvr@sun.com (Heather Rose) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1327@ucsfcca.ucsf.edu> dick@ucsfccb.UUCP (Dick Karpinski) writes: >The NeWS and the Open Look documentation is said to refer to >the local graphics device as a window server and the distant >applications engine as a window client. I am fully aware >that this makes good sense when you understand the mechanism. >However, I am acutely aware that novices find this confusing. You're right. It is confusing. The word "server" has come to mean many things. Even the traditional reference to server has become muddled now that you have an nfs server, a client server, a news server, and a yp server. And on top of that we add the window server and compute server. Seems to me that the word "server" has come to mean a much broader class of items. But in general, it helps to think of the "server" as the one allocating resources. The nfs server gives/gets files to/from the requesting clients. The client server gives disk space via nfs to diskless clients. The news server distributes articles to rn clients to read. The yp server sends and receives password and other networking information to the yp clients. Then the window server allocates realestate on the monitor to client processes and transmits input to the clients and output from the clients to the necessary places. The compute server takes some instructions from the client and delivers the results after the appropriate number of CPU cycles. In general, it helps to think of the server co-habitating with the resources it is allocating. The window server worries about what is displayed on the monitor, so it would live closer to the monitor. The window clients do not necessarily have to do much "window stuff" at all. For instance, say you have a complex expert system working on a mainframe. And now you want to add a wiz-bang UI to it. So, you get Suns to do the UI with the NeWS server running on the Sun and handling user-input and screen output. Then the client of NeWS (the expert system) runs on your mainframe (the compute server). Then the mainframe sends information to the Sun like (give me more data) or (here is my result). The Sun then takes that information to translate it into something meaningful to the user by displaying information on the monitor. I think the field of computer science is running out of words in many areas. Maybe it's time to use latin or greek like medical science has. Then no one would know what anything meant :-) Heather Rose Tech. Support--Windows and Graphics From don@brillig.umd.edu Fri Aug 19 12:46:37 1988 Date: Fri, 19 Aug 88 12:46:37 EDT To: NeWS-makers@brillig.umd.edu Subject: NeWS mail notifier From: eagle!icdoc!Ist!jh@ucbvax.Berkeley.EDU (Jeremy Huxtable) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Here is (yet) another NeWS mail notifier which shows you when mail arrives and allows you to read the article. It was inspired by the recent posting to this group by Josh Siegel. When mail arrives you get a little envelope appearing on your screen which is the icon for a window displaying the offending article. Documentation consists of the comment at the top of the program. Suggestions for enhancements will be gratefully received. Some possible ones are: o Use a TextCanvas type window for reading the mail item. o For short messages, pop up a postcard rather than an envelope. o For really long messages, pop up a parcel icon. o For really short messages, pop up a telegram and change all the message into upper case with periods replaced by STOP etc. -----------------cut here-------------- #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh newsbiff.c <<'END_OF_newsbiff.c' X/* X** Created By: X** X** Jeremy Huxtable (jh@ist.co.uk) X** X** Mon Aug 15 12:33:25 BST 1988 X** X*/ X X/* X**LIBS: -lcps X*/ X X/* X** newsbiff.c: X** X** Usage: newsbiff host username [port] X** X** Inspired by the program posted by Josh Siegel (siegel@hc.dspo.gov), X** this program will notify you via your NeWS server when new mail arrives. X** The mail item should be given as standard input. The program opens a X** connection to the NeWS server (if any) on , checks that the X** user is the same as , and pops up an icon shaped like an X** envelope. You can click on this icon to get a window displaying the X** whole mail item. X** X** To use this you must change two files: X** X** 1) in your "user.ps" you need a line of the form: X** UserProfile /UserName () put X** and you probably need to disable network security: X** systemdict /NetSecurityWanted false put X** X** 2) in your ".forward" file in your home directory X** you need a line of the form: X** ,|"newsbiff " X** for example, my one goes: X** jh,|"/u/jh/bin/newsbiff isharp jh 2000" X** X** Of course, this is only a "biff" type program. It merely tells you X** that mail has arrived and lets you read it, nothing else. X** X** Any suggestions for enhancements gratefully received. X*/ X X#ifdef SYSVREF X#ifdef INTERLANTCP X#include X#include X#include X#else X#include X#endif X#else X#include X#include X#include X#endif X X#include X#include "newsbiff.h" X X#define MAXSTR 256 X Xmain(argc, argv) X int argc; X char *argv[]; X{ X struct hostent *hp; X char from[MAXSTR]; X char line[MAXSTR]; X char server[MAXSTR]; X int port = 2000; X int count = 0; X X if (argc != 3 && argc != 4) X exit(1); X X if (argc == 4) X port = atoi(argv[3]); X X if (!(hp = gethostbyname(argv[1]))) X exit(2); /* Host unknown */ X X /* X ** There ought to be a better way of doing this rather than X ** putting NEWSSERVER into the environment. X */ X sprintf(server, "NEWSSERVER=%lu.2000;%s\n", ntohl(*(u_long *)hp->h_addr), argv[1]); X putenv(server); X if (!ps_open_PostScript()) X exit(3); /* Can't contact NeWS server */ X X ps_username(line); X if (strcmp(line, argv[2]) != 0) X exit(4); /* User name doesn't match */ X X strcpy(from, "Anon"); X ps_begin_list(); X while (fgets (line, 255, stdin)) { X line[strlen(line)-1] = 0; X if (count++ > 50) { X ps_string("More follows......"); X break; X } X ps_string(line); X sscanf(line, "From: %s", from); X } X ps_end_list(); X ps_mailwindow(from); X ps_close_PostScript(); X exit(0); X} END_OF_newsbiff.c if test 2692 -ne `wc -c newsbiff.cps <<'END_OF_newsbiff.cps' X% X% NeWS interface for the "newsmail" program. X% X X#define NAME_TAG 1 X X% Get the user name of the owner of the NeWS server Xcdef ps_username(string s) => NAME_TAG(s) X UserProfile /UserName known X { UserProfile /UserName get } X { (?) } ifelse X NAME_TAG tagprint typedprint X X% Three procedures for sending down an array of strings Xcdef ps_begin_list() X [ X Xcdef ps_end_list() X ] X Xcdef ps_string(string s) X s X X% Actually create the icon. Xcdef ps_mailwindow(string sender) X X/MailWindow DefaultWindow [ X /Text % Text of the mail item X /Sender % Name of the sender X] Xclassbegin X /TextFont /Times-Roman findfont 14 scalefont def X /SmallFont /Times-Roman findfont 7 scalefont def X /Margin 10 def X X /new { % text sender => instance X /new super send begin X /Sender exch def X /Text exch def X /Iconic? true def X /IconX 50 def X /IconY 800 def X /IconWidth 64 def X /IconHeight 40 def X X IconX IconY % position of window X % Now calculate the width and height of the window X TextFont setfont X 0 Text { stringwidth pop max } forall X Margin 2 mul add BorderLeft add BorderRight add % Width X X TextFont fontheight Text length mul Margin 2 mul add X BorderTop add BorderBottom add % Height X X 3 2 roll 1 index sub IconHeight add 3 1 roll % Adjust Y position X reshape % Shape the window X IconX IconY move % Move the icon to its proper place X currentdict X end X } def X X % Write the mail item into the window. X /PaintClient { X 1 fillcanvas 0 setgray X TextFont setfont X Margin ClientHeight Margin sub TextFont fontheight sub moveto X Text { X show X Margin currentpoint exch pop moveto X 0 TextFont fontheight neg rmoveto X } forall X } def X X % Make the Icon look like an envelope. X /PaintIcon { X gsave X IconCanvas setcanvas X 1 fillcanvas 0 strokecanvas X matrix currentmatrix X IconWidth IconHeight scale X 0 0 moveto 0 1 lineto .5 .3 lineto 1 1 lineto X 1 0 lineto closepath clip % Set flap clipping path X 0 0 moveto .5 .7 lineto 1 0 lineto stroke % Draw two lines clipped by flap X initclip % Reset clip path X 0 1 moveto .5 .3 lineto 1 1 lineto stroke % Draw flap X .5 .7 moveto X setmatrix X SmallFont setfont Sender cshow X grestore X } def X Xclassend def X X% Create the window. We create a new process group so that the window X% does not get zapped when the C program closes its socket. X{ X newprocessgroup X sender framebuffer /new MailWindow send X /map exch send X} fork clear END_OF_newsbiff.cps if test 2574 -ne `wc -c Makefile <<'END_OF_Makefile' XCFLAGS=-O XINCLUDE=-I/usr/NeWS/include XLIBS=/usr/NeWS/lib/libcps.a X Xnewsbiff: newsbiff.c newsbiff.h X $(CC) $(CFLAGS) $(INCLUDE) newsbiff.c -o newsbiff $(LIBS) X Xnewsbiff.h: newsbiff.cps X cps newsbiff.cps END_OF_Makefile if test 202 -ne `wc -c , dick@ccb.ucsf.edu (Dick Karpinski) writes: > The NeWS and the Open Look documentation is said to refer to > the local graphics device as a window server and the distant > applications engine as a window client... > > [ WRONG! ] > > ...The local thing is client. The distant thing is server. This hadn't occurred to me, but you're absolutely right! Furthermore, even the _implementation_ of applications under NeWS might not follow the local "server", remote "client" model. For example, a Postscript process in the workstation might be in control of the application, but make requests to a data-base server on a remote machine. Server/client is a relationship between _processes_. At the relevant level of abstraction, NeWS is not a process. It is virtual machine supporting Postscript processes, some of which might be servers, some clients. While we're at it, the term "host" also seems to be terminally confusing. Radford Neal From don@brillig.umd.edu Sun Aug 21 17:42:05 1988 Date: Sun, 21 Aug 88 17:42:05 EDT To: NeWS-makers@brillig.umd.edu Subject: Emulating some NeWS operator extensions in PostScript From: steinmetz!vdsvax!montnaro@itsgw.rpi.edu (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Sun's NeWS product has lots of extensions to handle input, events, multitasking, and so forth. It also has a few more generally useful operators that I'd like to emulate for LaserWriters and such. Some are easy to fake (the color stuff), some require a bit of thought (arccos, arcsin, arctan, currentpath), some aren't worth doing (like input, monitors, and events - just modify the stack appropriately), and some I can't think of how to do at all (undef, contrastswithcurrent, copyarea). Can anybody give me some pointers on the following (defs from the NeWS 1.1 manual): copyarea dx dy => - Copies the area enclosed by the current path to a position offset by dx,dy from its current position. For example, you could use this primitive to scroll a text window. The nonzero winding number rule is used to define the inside and outside of the path. [ There is a corresponding eocopyarea that uses the even/odd winding rule. ] contrastswithcurrent color => boolean Returns true if the color argument is different than the current color. The test takes into account the characteristics of the current device. The standard boolean operators, like eq can be used to compare colors without accounting for the current device. undef dict key => - Removes the definition (if any) of key from dict. [ Note that undef doesn't make a copy, but modifies the dictionary in question. ] -- Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa) From don@brillig.umd.edu Sun Aug 21 17:43:36 1988 Date: Sun, 21 Aug 88 17:43:36 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Bugs in NeWs documentation (really: terminology confusing to novices) From: linus!encore!bzs@husc6.harvard.edu (Barry Shein) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) What's the confusion here? Server: something which provides a resource, such as a piece of hardware. Disk servers provide disks, window servers provide screens. Servers might abstract their resources, NFS makes disks look like file systems, NeWS/X make screens look like window systems. Client: something which uses these resources by indirect requests to the server. Disk clients use other's disks, window clients use other's screens. Servers control the resources (eg. can refuse service, ensure security and integrity in general.) Servers can run w/o clients, clients are meaningless w/o servers and generally just exit(1) immediately or loop looking for them. -Barry Shein, ||Encore|| From don@brillig.umd.edu Sun Aug 21 17:44:43 1988 Date: Sun, 21 Aug 88 17:44:43 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: linus!encore!bzs@husc6.harvard.edu (Barry Shein) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) (I swear I am trying to remain open-minded, don't confuse hard questions with strong opinions.) Does there exist any graphics editor which can take a postscript image description and let you edit it visually in some useful way? Is this hard? I think it's possible, but my intuitions say it's very hard, not sure why exactly other than that such editors tend to want object descriptions and postscript doesn't particularly lend itself to that (it could be enforced as a discipline of course, I mean that given some random graphic image from someone it won't likely be structured in any particularly useful way.) So such programs have to define some other file format, typically their own (I guess QuickDraw was designed with this in mind?), which can later be translated to postscript if desired. This tends to deny the idea that ps is an image transmission/storage language. If I store an interesting image in ps I'm not sure I can later edit it (say a bunch of clip-art I might want to touch up for layout later, I suppose anything is possible by simply overlaying with new opaque elements, but the real issue is being able to do something like point to an area and say "fill it w/ gray 80%" or change the light source.) What would it have taken to have made postscript also appropropriate for graphical editing? Not sure. This is just a bunch of questions. -Barry Shein, ||Encore|| From don@brillig.umd.edu Thu Aug 25 03:29:32 1988 Date: Thu, 25 Aug 88 03:29:32 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Simple mouse/menu access From: cbmvax!jesup@rutgers.edu (Randell Jesup) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <5613@ihlpf.ATT.COM> warren@ihlpf.ATT.COM (Montgomery) writes: > My appliction would like to use the mouse for >pointing and menues, and take explicit control of a scrollbar if >provided, but would otherwise like to treat the screen like a >terminal. Most windowing systems seem to offer me the choice of >running my application under a terminal emulator (e.g. xterm, >shelltool) that provides no access to the mouse and no control of >the scrollbar, or running directly on the windowing system, which >requires that I explicitly paint the screen using calls to the >windowing library instead of escape sequences and usually requires >that my application be re-structured to be event driven, which isn't >very natural for it. What I'd really like is: This has been thought of before, in the Amiga OS. The console device (that is attached to windows optionally) is essentially an ANSI 3.64 terminal emulator. It also has additional escape sequences that allow you to turn on things such as mouse buttons reporting, mouse position, window resizing, etc. While not every thing can be done through this, it allows most of what you're looking for. >Changes in the mouse buttons reported via escape sequences in the >same input stream as the keyboard. Mouse position either reported >with the button events or available via a function call. Available. >Some way of presenting menues, either by specifying in advance that >a certain button is for menues, giving a menu, and having the >selection reported in the input stream, or by having some function >that puts up a menu and returns a selection invokable after a mouse >push. Menu numbers are returned when a menu is selected. Intuition (the windowing system) calls for setting/clearing menustrips can be used with this. >Explicit control over any scrollbars, either through an escape >sequence that controls where the bar is displayed or through a >function call that does it. Mouse pushes in the scroll bar would be >reported in the same way as other mouse pushes, perhaps with >different encoding. Scrollbars are not currently directly part of the user interface. Proportional gadgets (with x and/or y freedom, and either automatic knobs (% of width/height) or custom images are part of the OS, and can be reported via the console.device. Also requesters that pop up will send set/clear messages, and disks inserted/removed will send messages (though it doesn't identify which disk at this time). There is also a timer entry, I think you can get 1/10 sec messages there. All messages are timestamped in secs and microsecs, and include modifier key/button states. >The closest thing I have seen to this is the windowing system on the >Unix PC, which can be set up to report mouse events the way I'd like >and provides the ability to put up a menu, but I have yet to see >comparable things for X, News, or Sunview. Any suggestions? -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup From don@brillig.umd.edu Thu Aug 25 03:29:42 1988 Date: Thu, 25 Aug 88 03:29:42 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: asente@decwrl.dec.com (Paul Asente) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <3499@encore.UUCP> bzs@encore.UUCP (Barry Shein) writes: >Does there exist any graphics editor which can take a postscript image >description and let you edit it visually in some useful way? > >Is this hard? I think it's possible, but my intuitions say it's very >hard, not sure why exactly other than that such editors tend to want >object descriptions and postscript doesn't particularly lend itself to >that (it could be enforced as a discipline of course, I mean that >given some random graphic image from someone it won't likely be >structured in any particularly useful way.) >... >What would it have taken to have made postscript also appropropriate >for graphical editing? Not sure. This is just a bunch of questions. Funny you should ask this question. I spent the last few years of my life doing a thesis on this very subject. You are right; it's very hard. My solution was to design a new language that was very close to PostScript but had the idea of objects. It would be possible to imbed this in PostScript by defining new operators, but it was still a new language. There are reasons that you don't want to do this by imbedding -- PostScript is so flexible that it's impossible to statically analyze a program and deduce anything interesting about it. In order to make editing fast you have to do some reasoning about the program, so I gave up some of PostScript's flexibility. PostScript programs that are "well behaved" can mechanically be translated into my language, but others cannot. If you want all the details, you can order report 87/6 from DEC WRL: Carmen Rouse DEC Western Research Laboratory 100 Hamilton Avenue Palo Alto, CA 94301 -paul asente asente@decwrl.dec.com decwrl!asente From don@brillig.umd.edu Thu Aug 25 03:29:50 1988 Date: Thu, 25 Aug 88 03:29:50 EDT To: NeWS-makers@brillig.umd.edu Subject: News on a 386 machine (other than the 386i)? From: "Michael_Powers.Henr801M"@Xerox.COM Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is there an implementation of NeWS (1.1 preferably) available commercially for a Compaq386 running Unix V.3 with an EGA or higher resolution monitor? Any info greatly appreciated. Michael Powers Xerox Corp. powers.henr801m@xerox.com From don@brillig.umd.edu Thu Aug 25 03:30:24 1988 Date: Thu, 25 Aug 88 03:30:24 EDT To: NeWS-makers@brillig.umd.edu Subject: Call for Papers: RASTER IMAGING AND DIGITAL TYPOGRAPHY From: hersch%elma.epfl.ch@CUNYVM.CUNY.EDU Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) ----------------------------------------------------------------- RASTER IMAGING AND DIGITAL TYPOGRAPHY International Workshop, Ecole Polytechnique Federale, Lausanne, Switzerland October 12-13, 1989 Chairman: Roger D. Hersch, EPFL Vice-Chairmen: Jacques ANDRE, INRIA-IRISA - Rennes Debra Adams, Xerox Parc Aim/Scope Raster image processors for non-impact printers and plotters require highly sophisticated algorithms and performant hardware. Outline character acquisition, design, manipulation and rasterization, as well as graphic and image rendering are of major concern to scientists and engineers involved in the development of raster imaging devices. Authors are invited to submit papers describing original research results on the most relevant and recent developments in digital typography and raster imaging. Contributions are welcomed on any of the topic areas covered by the above theme. This includes (and is not limited to) : - Shape acquisition (curve fitting) - Shape manipulation - Character design - Character representation and transformation - Measuring type quality - Character structures (generation/recognition) - Page-description languages - Rasterization algorithms - Rasterization accuracy - Fast rasterization hardware Submit extended abstracts (2-3 pages) or full papers in English by January 15, 1989. Authors will be notified by March 15, 1989. Camera ready full papers are due by April 29, 1989. The abstracts should contain: Title, Authors, Authors' affiliation, Keywords, Main Text, References, and Authors' Biography. All accepted papers will be published in the Conference Proceedings. Potential contributors are encouraged to give advance notice of their intention to submit a paper. For more information : Send abstracts to : Dr Jacques ANDRE Prof Roger D. HERSCH INRIA-IRISA - Rennes LSP/EPFL Campus Univ. de Beaulieu 37, av. de Cour F-35042 RENNES CEDEX CH-1007 LAUSANNE France Switzerland Tel (33) 99 36 20 00 Tel (4121) 47 43 57 from 1.11.88: 693 43 57 email: jandre@irisa.uucp hersch@elma.epfl.ch telefax: (4121) 47 39 09 from 1.11.88: 693 39 09 telex 450 420 epfi ch International Workshop on Raster Imaging and Digital Typography Chairman: Roger D. Hersch, EPFL Vice-chairmen: Jacques Andre, INRIA/IRISA Debra Adams, Xerox Parc Program Committee Sten Andler, IBM Almaden Research Center, San Jose Philip Apley, Bitstream Patrick Baudelaire, DEC PRL Rick Beach, Xerox Parc Johan Berlaen, Agfa-Gevaert Charles Bigelow, Stanford University Bruno Borghi, Metasoft Jim Flowers, DEC Fontlab Crispin Goswell, Rutherford Appleton Laboratory Andre Gurtler, Schule fuer Gestaltung, Basel Ernst Imhof, Digital Type Systems, Switzerland Peter Karow, URW Unternehmensberatung, Hamburg Hideko Kunii, Ricoh Research Center S.P. Mudur, National Center for Software Technology, Bombay Theo Pavlidis, SUNY at Stony Brook, NY Stephen Schiller, Adobe Systems, Mountain View Richard Southall, Xerox EuroParc Peter Stucki, University of Zurich From don@brillig.umd.edu Thu Aug 25 03:31:39 1988 Date: Thu, 25 Aug 88 03:31:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: terminology confusing to novices From: cca.ucsf.edu!ccb.ucsf.edu!dick@cgl.ucsf.edu (Dick Karpinski) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <3500@encore.UUCP> bzs@encore.UUCP (Barry Shein) writes: > >What's the confusion here? The confusion is that novices have heard of servers and clients and often think of themselves as the client and distant hosts as servers. In the case of a window server, the distant host provides the content to be shown, and the local workstation provides the screen to show it on. This is close enough to name servers and disk servers and the like (distant content provider, local content user/displayer) that these naive users are confused when the server/client naming conflicts with the there/here location. I have no quarrel with the technical accuracy of the present use of the terminology. I suggest that the words client and server be expunged and other terms substituted to reduce the barrier to achieving a sense of order and mastery by those who begin as novices. Here it is important to recognize that we tend to have developed considerable confidence in dealing with computers and complex descriptions of their operation. However, more than ever before, new users have no interest in achieving any general computer competency, only in understanding enough to get their particular tasks done. I notice that the server/client terms in re windows confused me and that several others agreed, even without my prompting, that the terms tended to confuse beginners. That is a hazzard which I believe worth avoiding. That is all. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797 From don@brillig.umd.edu Fri Aug 26 03:43:50 1988 Date: Fri, 26 Aug 88 03:43:50 EDT To: NeWS-makers@brillig.umd.edu Subject: currentpath and setpath From: pterodactyl.cis.ohio-state.edu!zwicky@tut.cis.ohio-state.edu (Elizabeth D. Zwicky) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've been working on a program recently where I wanted to keep some paths around to re-use them later, and trying to use "currentpath" and "setpath". My *best* results so far have been no output. At worst, my window system hangs. The intermediate possibility is an "invalidaccess" error executing "pathforallvec" when I try to do a stroke. You can get the no results effect by starting up psh, typing executive, giving it the path of your choice (0 0 moveto 100 100 lineto, for instance), and typing "currentpath setpath stroke". Nothing happens. For a more impressive demonstration, do a "10 setlinewidth", do the random path "currentpath setpath stroke" again (producing the invalidaccess error), *and then actually draw a line*. In the version of NeWS we run, this appears to have the result of scaling by the linewidth. I do not have a good repeat-by for the total hang result yet; narrowing it down is understandably slow, since I keep having to reboot my Sun... Is this a result of running 1.1 Beta instead of real 1.1? Am I smoking my socks? Is NeWS smoking its socks? I know (from hacking on printers) how to do a grody disgusting hack that fakes a currentpath using pathforall, but I was really hoping that there would be a clean way to do this and "currentpath" looked so good. Elizabeth D. Zwicky (zwicky@cis.ohio-state.edu) From don@brillig.umd.edu Fri Aug 26 03:43:57 1988 Date: Fri, 26 Aug 88 03:43:57 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: Is NeWS UseABLE? From: imagine!pawl13.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <229.8808111329@jura.ritd.co.uk> mr@ritd.co.UK writes: >I'd like to endorse the item from Charles Hedrick >*especially* the comment about the window of opportunity for NeWS closing >rapidly. I really hope that Sun responds to this message (but don't hold >out much hope :-(). Me too. But I would like to add that I think that the window has essentially closed. Too bad. I think that NeWS was a great system but that unavailability of (even buggy) releases and especially code has just about killed all but parochial interest in NeWS as it has made the kind of ubiquitous hacking and production of tools and toys difficult for many people - and in the Unix (tm - and all standard hand waving) world that is one of the things that sells systems. jeff putnam jefu@pawl.rpi.edu "It is easier to get forgiveness than permission." From don@brillig.umd.edu Sat Aug 27 21:35:21 1988 Date: Sat, 27 Aug 88 21:35:21 EDT To: NeWS-makers@brillig.umd.edu Subject: Re: currentpath and setpath From: Rafael Bracho Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Re: Elizabeth D. Zwicky's message, the currentpath/setpath combination is known not to work with stroke. This bug has been reported to Sun and they promised it will be fixed in the merged server. The invalidaccess problem with pathforallvec was just found by a member of my project this week and we haven't reported it yet. There is yet another problem with currentpath/setpath and a "feature": It seems that under some circumstances, pointinpath causes a SIGSEV crash of the server when the path was a saved path. The feature is that paths saved and then restored seem to have lost their currentpoint; this means that you can't add to one of those paths (sigh). Rafael Bracho RXB@SPAR-20.SLB.COM From don@brillig.umd.edu Sun Aug 28 10:28:39 1988 Date: Sun, 28 Aug 88 10:28:39 EDT To: NeWS-makers@brillig.umd.edu Subject: Fresh Pie Menu Source Code & The Pseudo-Scientific Visualizer From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The following 5 files contain the PostScript source code that runs under NeWS 1.1, and SGI's 4Sight 1.1. It should work just fine with Grasshopper's MacNews, too. If you are using a Sun or a Mac or anything else, use "psh" to load the files piemenu.ps, pullout.ps, neatwin.ps, and visualize.ps, in that order. You only need sgipie.ps if you're running 4Sight 1.1 on a Silicon Graphics Iris. In that case, load the files piemenu.ps, sgipie.ps, pullout.ps, neatwin.ps, and visualize.ps, in that order. If you put the files in your NeWS directory, you can put the following lines into your user.ps to load them automatically when you start the server: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% (NeWS/piemenu.ps) LoadFile pop framebuffer /GLCanvas known { % SGI 4Sight? (NeWS/sgipie.ps) LoadFile pop } if (NeWS/pullout.ps) LoadFile pop (NeWS/neatwin.ps) LoadFile pop %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Here is a short description of the 5 files: piemenu.ps A few bug fixes since last posting. Root no longer stops repainting after piemenu.ps is run from a menu. If /DontSetDefaultMenu is defined in systemdict, then loading piemenu.ps will not set DefaultMenu to PieMenu. sgipie.ps Initial posting. A subclass of PieMenu that runs in the overlay plane of the SGI Iris 4D, under 4Sight version 1.1 (Silicon Graphic's port of NeWS 1.1). Only load this if you're running 4Sight. pullout.ps Initial posting. A subclass of PieMenu that uses cursor distance from the menu center to specify an argument to the menu selection. Each menu key has an array of possible arguments, from which the cursor distance selects the argument value. The values in the arrays are "Things" (cf. litemenu.ps & colordemo) that are painted in the menu center as feedback. neatwin.ps A few bug fixes since last posting. Now shares one set of global frame menus between all windows. Hacked so "spin" won't mess up the global frame menu. If DontSetDefaultWindow is defined in systemdict, then loading neatwin.ps will not set DefaultWindow to NeatWindow. visualize.ps A program for the Pseudo-Scientific Visualization of live PostScript data structures in the NeWS server. Demonstrates the use of class PulloutPieMenu. The Pseudo-Scientific Visualizer is the class browser for the other half of your brain. Feel free to redistribute any of this code! (And you can make as many backup copies of it as you want, as long as you print out and burn any old versions! :-) -Don Don Hopkins don@brillig.umd.edu ...!uunet!mimsy!don 5819 Ruatan St., College Park, MD 20740 USA From don@brillig.umd.edu Sun Aug 28 10:28:54 1988 Date: Sun, 28 Aug 88 10:28:54 EDT To: NeWS-makers@brillig.umd.edu Subject: piemenu.ps (file 1 of 5) From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % @(#)piemenu.ps % % Pie menu class implementation. % Copyright (C) 1987. % By Don Hopkins. % All rights reserved. % % Simple Simon popped a Pie Men- % u upon the screen; % With directional selection, % all is peachy keen! % % Pie Menus are provided for UNRESTRICTED use provided that this % copyright message is preserved on all copies and derivative works. % This is provided without any warranty. No author or distributor % accepts any responsibility whatsoever to any person or any entity % with respect to any loss or damage caused or alleged to be caused % directly or indirectly by this program. This includes, but is not % limited to, any interruption of service, loss of business, loss of % information, loss of anticipated profits, core dumps, abuses of the % virtual memory system, or any consequential or incidental damages % resulting from the use of this program. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % May 28 1987 Don Hopkins % First cut, based on LitePullRightMenu. % % May 30 1987 Don Hopkins % Uses "Thing"s from liteitem.ps for key labels. A thing can be a % string, or a keyword. The string is shown in MenuFont. The % keyword can be either the name of an icon in icondict, or bound % on the dict stack to an executable function. The function takes % a boolean as input; if true, it draws itsself; if false, it % returns its width and height. % NOTE: in NeWS 1.1, a Thing is either: a string, a keyword (icon % name only), an executable array (taking /draw or /size as % input), or an Object dict (sent a /draw and /size messages). % See the colornames demo! % Better label positioning scheme: top or bottom justify labels at % at the very bottom or top of the menu, and left or right justify % labels on the right or left sides of the menu. The points % relative to which the labels are justified are positioned at % evenly spaced angles in a circle around the menu center. The % instance variable PieInitialAngle is the angle of the first % point. LabelRadius is the distance from the menu center to each % point, calculated as: % LabelMinRadius + LabelRadiusPerKey * % NOTE: LabelRadiusPerKey is obsolete now. LabelRadius is automatically % pushed out until no labels overlap. % If the menu can't be centered on the location of the button % event that invoked it, then warp the cursor to the menu center % plus how much it has moved since the button down event, so that % pop up menus near the screen edge and static menus work % correctly. But ARRRGH FOO: setcursorlocation is broken!!! It % moves the cursor, but next time you move the mouse, the cursor % pops back to where it used to be! The Sun X server used to have % the same problem with XWarpMouse. Makes you wonder. Well, % anyway, I commented it out, because it's more confusing with % setcursorlocation broken than it is not warping at all. % NOTE: It's fixed now, so it works right! % % July 13 1987 Don Hopkins % Fixed up handling of retained canvases. Changed SliceLines to % SliceWedges, and made it draw wedges inside of LabelRadius. % Put in MoveMenu, which moves the menu, making sure that it's % completely on the screen, and the mouse is in the menu center. % (The latter part should be uncommented when setcursorlocation % is fixed.) Changed slice highlighting. % Implemented an oops function. Pressing the adjust button moves % the top menu so the cursor's back in its center. (Well, % setcursorlocation is still broken ...) If the mouse is already % in the menu center, then the menu is popped down and the % one below it is moved so its center is at the cursor. % NOTE: Oops works much better now that setcursorlocation is fixed! % On AdjustButton Down (Ker), the cursor moves to the menu center. % On AdjustButtonUp (Chunk), if the cursor is still in the menu % center, the menu is popped down, leaving you in the previous % menu (if any), at the location you invoked this menu from. % % July 24 1987 Don Hopkins % Changed to work with NeWS 1.1 litemenu.ps ... (just in time for SIGGRAPH!) % % August 20, 1987 Don Hopkins % Uncommented out and fixed the mouse warping code. Added display % interruption, so that if the events that would make the menu % selection are already in the event queue, then the menu is not % displayed. I'm not sure if the way I'm doing it is the best way, % but it seems to work. I'm still not sure that the way mouse warping % near the screen edge and display interruption are interacting is % really correct. It should not warp the mouse if the events are % already in the queue, so maybe warping should be defered, as well. % There was also a problem with /Damaged events generated when the % canvas is reshaped, being put into the queue before the /MapMenu % event is. This was causing the menu to be painted before the % defered mapping took place, which is not the way I think it should % work. So I kludged around it. There's got to be a safer way to % make it work right. % NOTE: This kludge has been flushed in favor of drawing the menu % before it's mapped. % A delay has been added to the map event, to facilitate mouse-ahead % display suppression. If you click down and up, without moving out % of the menu center, you will get the menu as soon you let up, but % if you click down and move, without letting up, there will be a % delay before it is mapped, during which time if you let up in an % active slice region, the mapping of the menu will be suppressed % (unless there is a submenu), and the selection you have chosen % acted upon immediatly. The submenu delay is shorter than the delay % of a menu with no parent, so that when you mouse-ahead quickly % into a submenu, you will see the submenu mapped first. (Because % the parent menu is less important than the active submenu, now % that you've already made the selection.) This may sound quite % bizarre, but it seems to work pretty nicely for me. % % March 29, 1988 Don Hopkins % Lots of changes have been made, too many to go into excruciating % detail, but I've put notes in the above comments to bring them % somewhat up to date. Please destroy any evil old copies of % piemenu.ps and replace them with this!!! % % August 28, 1988 Don Hopkins % Fixed "go!" so the framebuffer's event manager would not end up % with the currentcanvas of the process from which it was invoked. % (This was causing damage on the framebuffer not to be repainted % if piemenu.ps was run from a menu.) % Added the DontSetDefaultMenu flag. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Things to do: % % Teach it to use items as menu keys. Create PieItems like buttons, % cycles, sliders and pull-out menus based on the distance, % etc... (Use Things that are Objects!) % % Figure out some sort of light-weight feedback to use with mouse-ahead % display suppression, short of mapping the menu. % % Make each slice a canvas, and map just the choosen slices. Leave % a trail of wedges to the current active submenu. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% systemdict begin systemdict /Item known not { (NeWS/liteitem.ps) run } if systemdict /LiteMenu known not { (NeWS/litemenu.ps) run } if %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Utilities % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Replace the go! function with one that starts a root event manager % that listens for (and ignores) menu button up events. This is so they % don't get dropped on the floor before a pie menu can express interest % in them. (Crucial for effective mouse-ahead!) /go! { verbose? { (Starting root eventmgr\n) print } if systemdict /rooteventmgr known { rooteventmgr type /processtype eq { rooteventmgr killprocess } if } if { countdictstack 1 sub {end} repeat framebuffer setcanvas /rooteventmgr [ /rootmenu where { pop MenuButton { {newprocessgroup /showat rootmenu send} fork pop } /DownTransition framebuffer eventmgrinterest MenuButton { } /UpTransition framebuffer eventmgrinterest } if /Damaged {newprocessgroup damagepath clipcanvas PaintRoot newpath clipcanvas} null framebuffer eventmgrinterest ] forkeventmgr def } fork pop } def systemdict /rooteventmgr known { rooteventmgr type /processtype eq { go! } if } if % Coerce an angle to be >=0 and <360. % Note: mod returns integers, so's no good. /NormalAngle { % angle => angle dup 0 lt { dup 360 sub 360 idiv 360 mul sub } if dup 360 ge { dup 360 idiv 360 mul sub } if } def % From demomenu.ps % Fake method to send to a menu that returns a copy of the menu in the % new menu style. Recursivly changes all sub-menus. One thing to look % out for is that it does not change variables bound to the sub-menus % that were changed, so setting /rootmenu to the result of sending % /flipstyle to rootmenu will give you a new root menu, with a new % terminal sub-menu, but /terminalmenu will still be bound to the old % one, so sending messages to terminalmenu will not change the % terminal menu you get under the new rootmenu. But sending /flipstyle % to terminalwindow would not update the terminal menu under rootmenu. % So get your changes in before you flip styles! Or use /searchkey to % find the new menu, and re-def it in systemdict. /flipstyle { % - => newmenu 0 1 MenuActions length 1 sub { dup getmenuaction % fixed to use getmenuaction! dup type /dicttype eq { /flipstyle exch send % i menu' MenuActions 3 1 roll put % - } {pop pop} ifelse } for MenuKeys MenuActions /new DefaultMenu send } def % Override flipdefaultmenustyle, a function invoked from the user % interface menu. /flipdefaultmenustyle { % - => - (Flips default menu style) /DefaultMenu DefaultMenu SunViewMenu eq {PieMenu} {SunViewMenu} ifelse store } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % SimplePieMenu class % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% /SimplePieMenu LiteMenu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Instance variables % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% dictbegin % The slice currently painted. /PaintedValue null def % Inner radius around which labels are positioned. Based LabelMinRadius, % LabelRadiusPerKey, and the length of MenuKeys. /LabelRadius null def % Minimum radius for label positioning. /LabelMinRadius 25 def % Radius to step by when sizing menu /LabelRadiusStep 5 def % Extra radius to add when sizing menu /LabelRadiusExtra 10 def % Direction in which the keys are laid out around the circle. /Clockwise true def % Pie menu outer radius. Based on LabelRadius and the bounding boxes of % the Key Things. /PieRadius null def % The angle at which the first key is placed. /PieInitialAngle 90 def % up % The number of degrees a slice takes up. Based on length of MenuKeys. /PieSliceWidth null def % The current direction in degrees from the menu center to the cursor. /PieDirection null def % The current distance from the menu center to the cursor. /PieDistance null def % Angle used in loops. /ThisAngle null def % Amount to move the menu so that it fits entirely on the screen. /DeltaX null def /DeltaY null def % Flag to remember if we've gotten a menu button down event before. /GotDown false def % Don't ask. /SplatFactor 0 def % Interruptable display event /MapMenuEvent null def % Delays to use before mapping, if a button up has not happened yet. /MapLongDelay 1 60 div def % root menu popup delay /MapShortDelay .25 60 div def % submenu popup delay dictend %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Class variables % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% classbegin % Highlight: true strokes, false fills. /StrokeSelection false def % Width of border just inside PieRadius perimiter. /Border 3 def % Gap between outermost label edge and border. /Gap 9 def % Radius of numb hole in menu center that makes no menu selection. /NumbRadius 14 def % Fudge factors for menu positioning. /MouseXDelta 0 def /MouseYDelta -3 def % Draw lines delimiting slices. /SliceWedges true def % Draw arrows in the directions of slices. /SliceArrows false def % Drill a hole through the menu center, as big as NumbRadius. /NumbHole false def % Save the bits so pop-up is fast. /RetainCanvas? true def % Nice menu font... /MenuFont /Helvetica-Bold findfont 12 scalefont def % Draw arrow pointing to current selection? /HiLiteWithArrow? true def % Menu line attributes /MenuLineWidth 0 def /MenuLineCap 1 def /MenuArrowWidth 1 def /MenuArrowCap 1 def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Class methods % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Calculate and set the menu % LabelRadius, PieRadius, MenuWidth, and MenuHeight. Shape the canvas % and set the cursor. /layout { gsave MenuFont setfont initmatrix /PieSliceWidth 360 MenuKeys length 1 max div store % Get the size of all the keys, and point them in the right direction /ThisAngle PieInitialAngle store MenuItems { begin w null eq {/Key load ThingSize /h exch def /w exch def} if /ang ThisAngle def /dx ang cos def /dy ang sin def dx abs .05 lt { % top or bottom /xoffset w -.5 mul def /yoffset ang 180 gt {h neg} {0} ifelse def } { % left or right /xoffset ang 90 gt ang 270 lt and {w neg} {0} ifelse def /yoffset h -.5 mul def } ifelse /ThisAngle ThisAngle PieSliceWidth Clockwise {sub} {add} ifelse NormalAngle store end } forall % Push the keys out so none of them overlap /LabelRadius LabelMinRadius def MenuItems length 1 gt { 0 1 MenuItems length 1 sub { /i exch def /nexti i 1 add MenuItems length mod def { i calcrect nexti calcrect rectsoverlap not {exit} if /LabelRadius LabelRadius LabelRadiusStep add def } loop } for } if /LabelRadius LabelRadius LabelRadiusExtra add def /PieRadius LabelRadius dup mul def MenuItems { begin /x dx LabelRadius cvr mul def % XXX: cvr is for NeWS math bug /y dy LabelRadius cvr mul def /X x xoffset add def /Y y yoffset add def dx abs .05 lt { % top or bottom x abs w 2 div add dup mul y abs h add dup mul add } { % left or right x abs w add dup mul y abs h 2 div add dup mul add } ifelse PieRadius max /PieRadius exch store end } forall /PieRadius PieRadius sqrt Gap add Border add round store /MenuWidth PieRadius dup add store /MenuHeight MenuWidth store grestore } def /calcrect { % item_number => x y w h MenuItems exch get begin LabelRadius dx mul xoffset add LabelRadius dy mul yoffset add w h end } def /reshape { MenuGSave framebuffer setcanvas newpath PieRadius dup dup 0 360 arc closepath NumbHole { PieRadius dup NumbRadius 1 sub 360 0 arcn closepath } if SplatFactor { 6 { PieRadius dup add random mul } repeat curveto } repeat MenuCanvas eoreshapecanvas /beye /beye_m MenuCanvas setstandardcursor % So retained canvases don't have their old image upon popup: RetainCanvas? { MenuCanvas setcanvas MenuFillColor fillcanvas } if grestore } def % Make sure nothing's highlighted if there's a retained canvas. % Layout the menu, make the canvas, and reshape it, as needed. Try to % center the menu on (XLocation, YLocation) (the location of the event % or the (X, Y) arguments), but if needed, move it so that it's % completely on the screen, remembering the distance moved in (DeltaX, % DeltaY), for repositioning the mouse later. Set up the canvas. Send % out a MapMenuEvent with a delay, so that we can supress the mapping % if we receive the events that complete the selection right away. % (This is mouse-ahead display suppression.) (Submenus have a shorter % delay than parentless menus, because if you mouse quickly into a % submenu, then wait, you're more immediatly interested in seeing the % submenu than the parent.) Finally, reset the menu value, and % activate the menu event manager. /showat { % event => - PaintedValue null ne MenuCanvas null ne and MenuWidth null ne and { MenuGSave PaintedValue PaintSlice grestore } if /PaintedValue null store MenuEventMgr null ne {MenuEventMgr waitprocess pop} if MenuWidth null eq { /layout self send MenuCanvas null ne {/reshape self send} if } if MenuCanvas null eq { /MenuCanvas ParentCanvas newcanvas def MenuCanvas /Retained RetainCanvas? put /reshape self send } if gsave framebuffer setcanvas dup type /eventtype eq { begin XLocation YLocation end } if PieRadius sub MouseYDelta add /MenuY exch def PieRadius sub MouseXDelta add /MenuX exch def clippath pathbbox /DeltaY exch def /DeltaX exch def pop pop /DeltaY MenuY MenuHeight add dup DeltaY ge { DeltaY exch sub } { dup MenuHeight lt { MenuHeight exch sub } { pop 0 } ifelse } ifelse def /DeltaX MenuX MenuWidth add dup DeltaX ge { DeltaX exch sub } { dup MenuWidth lt { MenuWidth exch sub } { pop 0 } ifelse } ifelse def /MenuX MenuX DeltaX add store /MenuY MenuY DeltaY add store MenuCanvas savebehindcanvas MenuCanvas setcanvas MenuX MenuY movecanvas MenuCanvas canvastotop grestore % Defer the mapping till events already in the input queue % have been processed. MapMenuEvent null ne { MapMenuEvent recallevent } if /MapMenuEvent createevent begin /Name /MapMenu def % So active submenu pops up before already choosen parent! /TimeStamp currenttime ParentMenu null eq {MapLongDelay} {MapShortDelay} ifelse add def /Canvas MenuCanvas def currentdict end def MapMenuEvent sendevent /MenuValue null def /GotDown false def /activate self send } def /paint { MenuGSave PaintMenuFrame PaintMenuItems grestore } def /PaintMenuFrame { MenuGSave MenuFillColor fillcanvas PieRadius dup translate newpath 0 0 PieRadius 0 360 arc closepath 0 0 PieRadius Border sub 0 360 arc closepath % 0 0 NumbRadius 0 360 arc closepath MenuBorderColor setcolor eofill grestore } def /PaintMenuItems { MenuGSave false setprintermatch PieRadius dup translate MenuItems { % item begin MenuTextColor setcolor /Key load X Y ShowThing % There seems to be a NeWS line clipping bug with lines with one % endpoint the right of the hole in the center of the menu ... 2 setlinequality % Solves SOME of the line glitches ... MenuLineWidth setlinewidth MenuLineCap setlinecap SliceWedges { gsave newpath ang PieSliceWidth 2 div sub rotate NumbRadius 0 moveto LabelRadius Gap sub 0 lineto MenuBorderColor setcolor stroke grestore } if SliceArrows { gsave MenuArrowWidth setlinewidth MenuArrowCap setlinecap newpath ang rotate NumbRadius 0 moveto LabelRadius .5 mul 0 lineto currentpoint LabelRadius .4 mul LabelRadius .04 mul lineto moveto LabelRadius .4 mul LabelRadius -.04 mul lineto MenuBorderColor setcolor stroke grestore } if end } forall grestore } def % Handle drag events. If there's not a child menu up, then track the % mouse movement, updating the menu value according the the event % location; if it has changed, then update the highlighting. /DragProc { ChildMenu null eq { MenuGSave PieRadius dup translate CurrentEvent begin XLocation DeltaX add YLocation DeltaY add end SetMenuValue MenuValue PaintedValue ne { PaintMenuValue } if grestore } if } def % Handle enter canvas events. Just call DragProc to keep the menu % value updated. /EnterProc { DragProc } def % Handle exit canvas events. Same as above. Here we keep tracking even % when you're off the menu edge (due to expressing interest in events % on the null canvas). But if it really turns you on, going off the % edge could mean no selection (like when you're within the numb % radius - look at SetMenuValue), or select the slice, or pop up a % submenu, or drag the menu around, or give more info about the slice, % or whatever. /ExitProc { DragProc } def % Pop back to the center of the menu. /KerProc { MenuGSave DragProc framebuffer setcanvas MenuX PieRadius add MouseXDelta sub MenuY PieRadius add MouseYDelta sub setcursorlocation grestore } def % Pop back to the previous menu, if we're in this menu's center. /ChunkProc { MenuGSave DragProc MenuValue null eq { popdown } if grestore } def % Map the menu on the screen. This is invoked when we get a /MapMenu % event, so that we can interrupt the display of the menu (by % recalling the event) if the events that would complete the selection % are already in the input queue. /MapMenu { gsave DeltaX 0 ne DeltaY 0 ne or { framebuffer setcanvas currentcursorlocation exch DeltaX add exch DeltaY add setcursorlocation /DeltaX 0 def /DeltaY 0 def } if MenuCanvas mapcanvas /MapMenuEvent null def grestore } def /popdown { MapMenuEvent null ne { MapMenuEvent recallevent /MapMenuEvent null def } if MenuCanvas null ne {MenuCanvas unmapcanvas} if % spin needs this?? RetainCanvas? not { /MenuCanvas null store /MenuInterests null store % /MenuWidth null store } if % framebuffer setcanvas? ChildMenu null ne { /popdown ChildMenu send } if ParentMenu null ne { ParentMenu /ChildMenu null put /ParentMenu null store } if MenuEventMgr null ne { MenuEventMgr /MenuEventMgr null store killprocess } if } def % Calculate and set the menu value from the cursor x y location. % Updates /PieDistance and /PieDirection instance variables. /SetMenuValue { % x y => - (Sets /MenuValue) /PieDistance 2 index cvr dup mul 2 index cvr dup mul add sqrt def exch atan /PieDirection exch def /MenuValue PieDistance NumbRadius le % It could be that when the cursor is out past the menu radius, % nothing is selected. But I don't do it that way, because it wins % to be able to get arbitrarily more precision by moving out further. % PieDistance PieRadius gt or { null } { PieSliceWidth 2 div PieInitialAngle Clockwise { add PieDirection sub } { sub PieDirection add } ifelse NormalAngle PieSliceWidth idiv } ifelse def } def % Update the highlighted slice to show the current menu value. /PaintMenuValue { % - => - (Hilite current item, un-hilite prev one.) PaintedValue PaintSlice MenuValue PaintSlice /PaintedValue MenuValue store } def % Paint highlighting on a menu slice. If it's null, then do nothing. % Draw an arrow, and a box around the key. /PaintSlice { % key => - dup null ne { % key MenuGSave PieRadius dup translate % Draw an arrow pointing out in the direction of the slice. MenuItems exch get begin % overlayerase MenuBorderColor setcolor 5 setrasteropcode HiLiteWithArrow? { gsave ang rotate newpath NumbRadius 0 moveto LabelRadius Gap sub % r dup .6 mul dup PieSliceWidth 3 div sin mul lineto dup .9 mul 0 lineto .6 mul dup PieSliceWidth -3 div sin mul lineto % closepath StrokeSelection {stroke} {fill} ifelse grestore } if % Highlight the key Thing. -4 2 X Y w h insetrrect rrectpath StrokeSelection {stroke} {fill} ifelse end grestore } {pop} ifelse % } def % Handle button up events. If we have children, then let the leaf % child menu handle the button up event. Otherwise, we handle it: If % it's a menu dictionary, then make it the child menu and show it. % Otherwise, execute the associated menu action, and send a /popdown % message to the root parent menu. /UpProc { DragProc MenuValue getmenuaction dup type /dicttype eq { /DeltaX 0 def /DeltaY 0 def % selection already made -- don't warp! /ChildMenu exch def ChildMenu /ParentMenu self put CurrentEvent /showat ChildMenu send } { pop % Ignore first mouse up if we're still in center of first menu ParentMenu null ne MenuValue null ne GotDown or or { /DeltaX 0 def /DeltaY 0 def % don't warp! { % Find the parent menu self { dup /ParentMenu get dup null eq { pop exit } { exch pop } ifelse } loop % ^?^? (toodles [tm]!) /popdown exch send domenu } fork waitprocess % doesn't return } { % If we are still in menu center then map immediatly! MapMenuEvent null ne { MapMenuEvent recallevent /MapMenuEvent null def MapMenu } if } ifelse } ifelse } def % Handle menu button down events. /DownProc { /GotDown true store DragProc } def % Handle damage events. Gotta make sure the highlighted slice is % re-highlighted. /DamageProc { MenuGSave damagepath clipcanvas /paint self send PaintedValue PaintSlice newpath clipcanvas grestore } def % Construct menu event interests. Use exclusivity so only the % top-most menu sees the events. /makeinterests { /MenuInterests [ MenuButton /UpProc UpTransition null eventmgrinterest dup /Exclusivity true put dup /Priority 5 put MenuButton /DownProc DownTransition null eventmgrinterest dup /Exclusivity true put MouseDragged /DragProc null null eventmgrinterest dup /Exclusivity true put /EnterEvent /EnterProc null MenuCanvas eventmgrinterest dup /Exclusivity true put /ExitEvent /ExitProc null MenuCanvas eventmgrinterest dup /Exclusivity true put /Damaged /DamageProc null MenuCanvas eventmgrinterest dup /Exclusivity true put dup /Priority -5 put AdjustButton /KerProc DownTransition null eventmgrinterest dup /Exclusivity true put AdjustButton /ChunkProc UpTransition null eventmgrinterest dup /Exclusivity true put % Kludge to refresh messed up retained menu canvases. Ssssh! Don't tell anyone. PointButton {} DownTransition null eventmgrinterest PointButton /DamageProc UpTransition MenuCanvas eventmgrinterest /MapMenu /MapMenu null MenuCanvas eventmgrinterest dup /Priority -5 put ] def } def /getmenuaction { % index => action dup null ne { MenuActions 1 index MenuActions length 1 sub min get % Execute actions that are names! (This is so we can have references % to submenus (executable names) as actions, as opposed to having the % submenu object dict itsself!) dup type /nametype eq { exec } if } {nullproc} ifelse exch pop } def classend def /PieMenu SimplePieMenu def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% /LayeredPieMenu SimplePieMenu dictbegin /MenuArgs [] def /MenuArg null def /PaintedArg null def dictend classbegin % Need to make flipstyle a no-op because /new takes a different number % of args, and actions might depend on MenuArg! /flipstyle {currentdict} def /new { % args keys actions => menu % -or- args keys/actions (one array) => menu /new super send begin /MenuArgs exch def currentdict end } def /showat { /showat super send /MenuArg null def } def /DragProc { ChildMenu null eq { MenuGSave PieRadius dup translate CurrentEvent begin XLocation DeltaX add YLocation DeltaY add end SetMenuValue MenuValue PaintedValue ne { PaintMenuValue } if MenuArg PaintedArg ne { PaintMenuArg } if grestore } if } def /PaintMenuArg { PaintedArg PaintArg MenuArg PaintArg /PaintedArg MenuArg store } def /PaintArg { dup null ne { MenuGSave PieRadius dup translate MenuBorderColor setcolor 5 setrasteropcode 100 string cvs dup stringbbox points2rect -.5 mul exch -.5 mul exch moveto pop pop show grestore } if } def /SetMenuValue { % x y => - /SetMenuValue super send /MenuArg MenuValue null eq MenuArgs length 0 eq or { null } { PieDistance PieRadius 1 sub min NumbRadius sub PieRadius NumbRadius sub div MenuArgs length mul floor MenuArgs exch get } ifelse def } def /getmenuarg { MenuArg } def classend def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% /setdefaultmenu { % class => - /DefaultMenu exch store /rootmenu /flipstyle rootmenu send store } def systemdict /DontSetDefaultMenu known not { % Death to pulldown menus! PieMenu setdefaultmenu } if end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From don@brillig.umd.edu Sun Aug 28 10:29:00 1988 Date: Sun, 28 Aug 88 10:29:00 EDT To: NeWS-makers@brillig.umd.edu Subject: sgipie.ps (file 2 of 5) From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % PieMenu class for 4Sight 1.1, using the SGI Iris 4D overlay plane. % Copyright (C) 1988 by Don Hopkins. % % This is for 4Sight 1.1, Silicon Graphic's implementation of NeWS 1.1. % It should be loaded in just after piemenu.ps. % Don't load this unless you're running 4Sight. % % This program is provided free for unrestricted use and redistribution, % provided that the headers remain intact. No author or distributor % accepts any responsibility for any problems with this software. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% systemdict begin % compat.ps was stripped! /mapcanvas { /Mapped true put } def /unmapcanvas { /Mapped false put } def /savebehindcanvas { /SaveBehind true put } def /SGIPieMenu SimplePieMenu dictbegin /RetainCanvas? false def /SupressParent? true def /CellHorizGap 0 def % Toolboxes use this? (/MenuLine...) /CellWidth 0 def % Toolboxes use this? (/MenuLine...) /CenterItems? false def % Toolboxes use this? (/MenuLine...) dictend classbegin /MapMenu { SupressParent? ChildMenu null ne and not { /MapMenu super send self { % What a bitch! dup null eq {pop exit} if % wtf did all that junk on the stack come from? {MenuCanvas /DamageProc 2 index send} fork waitprocess pop /ChildMenu get } loop } if } def /showat { % event => - InteractionLock { % sgi systemdict /MenuBusy 1 put % sgi UI_private /AttachMode /softattached put % sgi PaintedValue null ne MenuCanvas null ne and MenuWidth null ne and { /MenuValue null store PaintMenuValue } if /PaintedValue null store MenuEventMgr null ne {MenuEventMgr waitprocess pop} if MenuWidth null eq { /layout self send MenuCanvas null ne {/reshape self send} if } if MenuCanvas null eq { /MenuCanvas ParentCanvas newcanvas def %MenuCanvas /Retained RetainCanvas? put /reshape self send MenuCanvas dup canvastotop /Transparent true put % sgi /MenuPaintCanvas MenuCanvas createoverlay def % sgi MenuPaintCanvas /Retained RetainCanvas? put % sgi } if gsave framebuffer setcanvas dup type /eventtype eq { begin XLocation YLocation end } if PieRadius sub MouseYDelta add /MenuY exch def PieRadius sub MouseXDelta add /MenuX exch def clippath pathbbox /DeltaY exch def /DeltaX exch def pop pop /DeltaY MenuY MenuHeight add dup DeltaY ge { DeltaY exch sub } { dup MenuHeight lt { MenuHeight exch sub } { pop 0 } ifelse } ifelse def /DeltaX MenuX MenuWidth add dup DeltaX ge { DeltaX exch sub } { dup MenuWidth lt { MenuWidth exch sub } { pop 0 } ifelse } ifelse def /MenuX MenuX DeltaX add store /MenuY MenuY DeltaY add store MenuCanvas savebehindcanvas MenuCanvas setcanvas MenuX MenuY movecanvas MenuCanvas canvastotop grestore % Defer the mapping till events already in the input queue % have been processed. MapMenuEvent null ne { MapMenuEvent recallevent } if /MapMenuEvent createevent begin /Name /MapMenu def % So active submenu pops up before already choosen parent! /TimeStamp currenttime ParentMenu null eq {MapLongDelay} {MapShortDelay} ifelse add def /Canvas MenuCanvas def currentdict end def MapMenuEvent sendevent /MenuValue null def /GotDown false def /activate self send } monitor % sgi } def /popdown { MapMenuEvent null ne { MapMenuEvent recallevent /MapMenuEvent null def } if MenuPaintCanvas /Mapped false put MenuCanvas null ne {MenuCanvas unmapcanvas} if % spin needs this?? ParentMenu null ne { ParentMenu /MenuCanvas get /DamageProc ParentMenu send pop } if RetainCanvas? not { /MenuCanvas null store /MenuInterests null store % /MenuWidth null store } if % framebuffer setcanvas? ChildMenu null ne { ChildMenu /ParentMenu null put /popdown ChildMenu send /ChildMenu null store } if ParentMenu null ne { ParentMenu /ChildMenu null put /ParentMenu null store } if RetainCanvas? not { /MenuCanvas null store /MenuPaintCanvas null store /MenuInterests null store % /MenuWidth null store } if % framebuffer setcanvas? MenuEventMgr null ne { MenuEventMgr /MenuEventMgr null store killprocess } if } def /makeinterests { /MenuInterests [ MenuButton /UpProc UpTransition null eventmgrinterest dup /Exclusivity true put dup /Priority 5 put MenuButton /DownProc DownTransition null eventmgrinterest dup /Exclusivity true put MouseDragged /DragProc null null eventmgrinterest dup /Exclusivity true put /EnterEvent /EnterProc null MenuCanvas eventmgrinterest dup /Exclusivity true put /ExitEvent /ExitProc null MenuCanvas eventmgrinterest dup /Exclusivity true put % /Damaged /DamageProc null MenuCanvas eventmgrinterest /Damaged /paint null MenuCanvas eventmgrinterest dup /Exclusivity true put dup /Priority -5 put AdjustButton /KerProc DownTransition null eventmgrinterest dup /Exclusivity true put AdjustButton /ChunkProc UpTransition null eventmgrinterest dup /Exclusivity true put % Kludge to refresh messed up retained menu canvases. Ssssh! Don't tell anyone. PointButton {} DownTransition null eventmgrinterest % PointButton /DamageProc UpTransition MenuCanvas eventmgrinterest PointButton /MapMenu UpTransition MenuCanvas eventmgrinterest /MapMenu /MapMenu null MenuCanvas eventmgrinterest dup /Priority -5 put ] def } def /DrawMenuLine {pop} def /domenu { systemdict /MenuBusy 0 put MenuValue getmenuaction dup type /dicttype eq {pop} {cvx exec} ifelse } def /DamageProc { SupressParent? ChildMenu null ne and not { /damaged currentcanvas def dup getcanvaslocation 2 index setcanvas clipcanvaspath neg neg translate damaged setcanvas clipcanvas ParentMenu null ne {/DamageProc ParentMenu send} {pop} ifelse /paint self send true PaintedValue PaintSlice newpath clipcanvas } if } def % Pop back to the previous menu, if we're in this menu's center. /ChunkProc { MenuGSave DragProc MenuValue null eq { SupressParent? ParentMenu null ne and { % { popdown /paint ParentMenu send } fork pop { ParentMenu dup /ChildMenu null put /ParentMenu null def {popdown} fork waitprocess { {MapMenu} errored {paint} if } exch send } fork pop } { popdown } ifelse } if grestore } def /MenuGSave { gsave MenuFont setfont initmatrix MenuPaintCanvas setcanvas } def /reshape { %MenuGSave % sgi gsave % sgi framebuffer setcanvas newpath PieRadius dup dup 0 360 arc closepath NumbHole { PieRadius dup NumbRadius 1 sub 360 0 arcn closepath } if SplatFactor { 6 { PieRadius dup add random mul } repeat curveto } repeat MenuCanvas eoreshapecanvas /beye /beye_m MenuCanvas setstandardcursor % So retained canvases don't have their old image upon popup: RetainCanvas? { MenuCanvas setcanvas MenuFillColor fillcanvas } if grestore } def % Update the highlighted slice to show the current menu value. /PaintMenuValue { % - => - (Hilite current item, un-hilite prev one.) false PaintedValue PaintSlice true MenuValue PaintSlice /PaintedValue MenuValue store } def % Paint highlighting on a menu slice. If it's null, then do nothing. % Draw an arrow, and a box around the key. /PaintSlice { % draw key => - dup null ne { % key MenuGSave exch { % keyNumber draw /bgcolor MenuTextColor def /fgcolor MenuFillColor def } { /bgcolor MenuFillColor def /fgcolor MenuTextColor def } ifelse bgcolor setcolor PieRadius dup translate MenuItems exch get begin % Draw an arrow pointing out in the direction of the slice. HiLiteWithArrow? { gsave ang rotate newpath NumbRadius 0 moveto LabelRadius Gap sub % r dup .6 mul dup PieSliceWidth 3 div sin mul lineto dup .9 mul 0 lineto .6 mul dup PieSliceWidth -3 div sin mul lineto % closepath StrokeSelection {stroke} {fill} ifelse grestore } if % Highlight the key Thing. -4 2 X Y w h insetrrect rrectpath StrokeSelection { stroke } { fill fgcolor setcolor /Key load X Y ShowThing } ifelse end grestore } {pop pop} ifelse % } def /settitle {pop} def classend def /PieMenu SGIPieMenu def /LayeredPieMenu SGIPieMenu dictbegin /MenuArgs [] def /MenuArg null def /PaintedArg null def dictend classbegin % Need to make flipstype a no-op because /new takes a different number % of args, and actions might depend on MenuArg! /flipstyle {currentdict} def /new { % args keys actions => menu % -or- args keys/actions (one array) => menu /new super send begin /MenuArgs exch def currentdict end } def /showat { /showat super send /MenuArg null def } def /DragProc { ChildMenu null eq { MenuGSave PieRadius dup translate CurrentEvent begin XLocation DeltaX add YLocation DeltaY add end SetMenuValue MenuValue PaintedValue ne { PaintMenuValue } if MenuArg PaintedArg ne { PaintMenuArg } if grestore } if } def /PaintMenuArg { PaintedArg PaintArg MenuArg PaintArg /PaintedArg MenuArg store } def /PaintArg { dup null ne { /obsolete dbgbreak MenuGSave PieRadius dup translate MenuBorderColor setcolor 5 setrasteropcode 100 string cvs dup stringbbox points2rect -.5 mul exch -.5 mul exch moveto pop pop show grestore } if } def /SetMenuValue { % x y => - /SetMenuValue super send /MenuArg MenuValue null eq MenuArgs length 0 eq or { null } { PieDistance PieRadius 1 sub min NumbRadius sub PieRadius NumbRadius sub div MenuArgs length mul floor MenuArgs exch get } ifelse def } def /getmenuarg { MenuArg } def classend def systemdict /DontSetDefaultMenu known not { PieMenu setdefaultmenu } if end % systemdict From don@brillig.umd.edu Sun Aug 28 10:29:16 1988 Date: Sun, 28 Aug 88 10:29:16 EDT To: NeWS-makers@brillig.umd.edu Subject: pullout.ps (file 3 of 5) From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Class PulloutPieMenu % Copyright (C) 1988 by Don Hopkins (don@brillig.umd.edu) % % This program is provided free for unrestricted use and redistribution, % provided that the headers remain intact. No author or distributor % accepts any responsibility for any problems with this software. % % PulloutPieMenu is a subclass of PieMenu that uses cursor distance % from the menu center to specify an argument to the menu selection. % Each menu key has an array of possible arguments, from which the % cursor distance selects the argument value. The values in the % arrays are "Things" (cf. litemenu.ps & colordemo) that are painted % in the menu center as feedback. The /new method of class % PulloutPieMenu takes the same arguments that regular menus do, plus % an additional array of argument arrays. Each argument array % corresponds to a menu key. If you give just one argument array, it % is used for all the keys, the same as with the array of actions. % You can use getmenuarg and getmenuargindex in your menu actions to % retrieve the argument displayed when the key was selected. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% systemdict begin % ------------------------------------ % % PulloutPieMenu /PulloutPieMenu PieMenu dictbegin /SliceWedges false def /HiLiteWithArrow? false def /PrinterMatch? false def /ArgBorder 2 def /EraseArgs? true def /MenuArgs null def /MenuArg null def /MenuArgIndex null def /PaintedArg null def dictend classbegin % [[args...]...] [keys...] [actions...] => menu /new { /new super send begin dup length MenuKeys length lt { [ exch aload pop % pad out args w/ last arg counttomark MenuKeys length exch sub {dup} repeat ] } if /MenuArgs exch def currentdict end } def % Need to make flipstype a no-op because /new takes a different number % of args! /flipstyle {currentdict} def /MenuGSave { /MenuGSave super send PrinterMatch? setprintermatch } def /DragProc { ChildMenu null eq { MenuGSave PieRadius dup translate CurrentEvent begin XLocation DeltaX add YLocation DeltaY add end SetMenuValue MenuValue PaintedValue ne { PaintMenuValue } if getmenuarg /PaintedArg load ne { PaintMenuArg } if grestore } if } def framebuffer /GLCanvas known { % SGI 4Sight? % Paint menus on the overlay plane /DamageProc { /damaged currentcanvas def dup getcanvaslocation 2 index setcanvas clipcanvaspath neg neg translate damaged setcanvas clipcanvas ParentMenu null ne {/DamageProc ParentMenu send} {pop} ifelse /paint self send true PaintedValue PaintSlice /PaintedArg load /PaintArg self send } def } { /DamageProc { MenuGSave damagepath clipcanvas /paint self send PaintedValue PaintSlice /PaintedArg load PaintArg newpath clipcanvas grestore } def } ifelse /PaintMenuArg { getmenuarg dup null eq /PaintedArg load null eq EraseArgs? or or { /PaintedArg load EraseArg } if dup PaintArg /PaintedArg exch store } def /EraseArg { % thing => - MenuGSave dup null eq { pop PieRadius dup translate MenuFillColor setcolor 0 0 LabelRadius Gap sub 3 sub 0 360 arc fill } { PieRadius dup translate MenuFillColor setcolor ThingSize 2 copy -.5 mul exch -.5 mul exch 4 -2 roll ArgBorder neg 5 1 roll insetrect % Some extra padding... rectpath fill } ifelse grestore } def /PaintArg { % thing => - MenuGSave dup null eq { pop PieRadius dup translate MenuBorderColor setcolor MenuLineWidth setlinewidth MenuLineCap setlinecap MenuItems { begin gsave newpath ang PieSliceWidth 2 div sub rotate NumbRadius 0 moveto LabelRadius Gap sub 4 sub 0 lineto MenuBorderColor setcolor stroke grestore end } forall } { PieRadius dup translate MenuTextColor setcolor dup ThingSize -.5 mul exch -.5 mul exch ShowThing } ifelse grestore } def /showat { PaintedArg null ne PaintedValue null ne and MenuCanvas null ne and MenuWidth null ne and { MenuGSave /PaintedArg load EraseArg /PaintedArg null store null PaintArg grestore } if /MenuArg null def /MenuArgIndex null def /showat super send } def /SetMenuValue { % x y => - /SetMenuValue super send /MenuArg MenuValue null eq {null true} {MenuArgs MenuValue get dup length 0 eq} ifelse { pop null /MenuArgIndex null def } { PieDistance PieRadius 1 sub min NumbRadius sub PieRadius NumbRadius sub div 1 index length mul floor /MenuArgIndex 1 index def get } ifelse def } def /getmenuargindex { % - => index MenuArgIndex } def /getmenuarg { % - => Thing /MenuArg load } def classend def end % systemdict From don@brillig.umd.edu Sun Aug 28 10:29:35 1988 Date: Sun, 28 Aug 88 10:29:35 EDT To: NeWS-makers@brillig.umd.edu Subject: neatwin.ps (file 4 of 5) From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % @(#)neatwin.ps % % NeatWindow Class pie menu based window manager % Copyright (C) 1988. % By Don Hopkins. % All rights reserved. % % This program is provided for UNRESTRICTED use provided that this % copyright message is preserved on all copies and derivative works. % This is provided without any warranty. No author or distributor % accepts any responsibility whatsoever to any person or any entity % with respect to any loss or damage caused or alleged to be caused % directly or indirectly by this program. This includes, but is not % limited to, any interruption of service, loss of business, loss of % information, loss of anticipated profits, core dumps, abuses of the % virtual memory system, or any consequential or incidental damages % resulting from the use of this program. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % August 28, 1988 Don Hopkins % Made the menus shared by all instances of the class. % Put in a kludge to keep "spin" from trashing everybody's frame menu. % (If you want to learn how to write good NeWS code, don't look at spin.) % Added the DontSetDefaultWindow flag. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% systemdict begin systemdict /PieMenu known not { (NeWS/piemenu.ps) LoadFile pop } if /NeatWindow LiteWindow [] classbegin /stretchtopright { FrameX FrameY BBoxFromUser reshape non-iconic } def /stretchtopleft { FrameX FrameWidth add FrameY BBoxFromUser reshape non-iconic } def /stretchbottomright { FrameX FrameY FrameHeight add BBoxFromUser reshape non-iconic } def /stretchbottomleft { FrameX FrameWidth add FrameY FrameHeight add BBoxFromUser reshape non-iconic } def /stretchtop { /GA_value FrameX def /GA_constraint 0 def FrameX FrameWidth add FrameY BBoxFromUser reshape non-iconic } def /stretchbottom { /GA_value FrameX def /GA_constraint 0 def FrameX FrameWidth add FrameY FrameHeight add BBoxFromUser reshape non-iconic } def /stretchleft { /GA_value FrameY def /GA_constraint 1 def FrameX FrameWidth add FrameY FrameHeight add BBoxFromUser reshape non-iconic } def /stretchright { /GA_value FrameY def /GA_constraint 1 def FrameX FrameY FrameHeight add BBoxFromUser reshape non-iconic } def /movevertical { /GA_constraint 0 def slide } def /movehorizontal { /GA_constraint 1 def slide } def /flipmove { gsave framebuffer setcanvas /unmap self send /Iconic? Iconic? not def CurrentEvent begin XLocation YLocation end Iconic? { exch IconWidth 2 div sub exch IconHeight 2 div sub } { exch FrameWidth 2 div sub exch FrameHeight 2 div sub } ifelse move map slide grestore } def /non-iconic { Iconic? { flipiconic } if } def /reshapefromuser-open { reshapefromuser non-iconic } def /CreateFrameMenu { % - => - (Create frame menu) % Note: Store menu in class to share menus, especially if retained. /FrameMenu ClassFrameMenu def } def /CreateIconMenu { % - => - (Create icon menu) % Note: Store menu in class to share menus, especially if retained. /IconMenu ClassIconMenu def } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % The menus shared by all instances of the class: /FrameZapMenu [ /nuke {/destroy ThisWindow send} (No!) {} (No!) {} (No!) {} ] /new PieMenu send def FrameZapMenu /MenuFont /Times-BoldItalic findfont 24 scalefont put FrameZapMenu /flipstyle {currentdict} put /FrameMoveMenu [ /move_v {/movevertical ThisWindow send} /move {/slide ThisWindow send} /eye3 {/flipmove ThisWindow send} /move_h {/movehorizontal ThisWindow send} ] /new PieMenu send def FrameMoveMenu /flipstyle {currentdict} put /IconMoveMenu [ /move_v {/movevertical ThisWindow send} /move {/slide ThisWindow send} /eye {/flipmove ThisWindow send} /move_h {/movehorizontal ThisWindow send} ] /new PieMenu send def IconMoveMenu /flipstyle {currentdict} put /FrameStretchMenu [ /stretch_h {/stretchtop ThisWindow send} /stretchNE {/stretchtopright ThisWindow send} [/stretch_v 4 0] {/stretchright ThisWindow send} /stretchSE {/stretchbottomright ThisWindow send} /stretch_h {/stretchbottom ThisWindow send} /stretchSW {/stretchbottomleft ThisWindow send} [/stretch_v 4 0] {/stretchleft ThisWindow send} /stretchNW {/stretchtopleft ThisWindow send} ] /new PieMenu send def FrameStretchMenu /flipstyle {currentdict} put /ClassFrameMenu [ [(\255) /Symbol findfont 18 scalefont] {/totop ThisWindow send} /painting_hand {/paint ThisWindow send} (Move\274) FrameMoveMenu (Zap?) FrameZapMenu [(\257) /Symbol findfont 18 scalefont] {/tobottom ThisWindow send} (Reshape!) {/reshapefromuser-open ThisWindow send} (Stretch\274) FrameStretchMenu /eye3 {/flipiconic ThisWindow send} ] /new PieMenu send def ClassFrameMenu /MenuFont /Times-Roman findfont 18 scalefont put /ClassIconMenu [ [(\255) /Symbol findfont 18 scalefont] {/totop ThisWindow send} /painting_hand {/paint ThisWindow send} (Move\274) IconMoveMenu (Zap?) FrameZapMenu [(\257) /Symbol findfont 18 scalefont] {/tobottom ThisWindow send} (Reshape!) {/reshapefromuser-open ThisWindow send} (Stretch\274) FrameStretchMenu /eye {/flipiconic ThisWindow send} ] /new PieMenu send def ClassIconMenu /MenuFont /Times-Roman findfont 18 scalefont put % Make a copy of ourselves if somebody tries to change us! % (Yes this is a hack, but otherwise "spin" messes up everybody % else's frame menu, and if you mess with the frame menu you're % asking for trouble anyway.) { /clone&forward { % /msg => - /flipstyle self send ThisWindow dup null eq {pop win} if % Foo on spin... /FrameMenu 2 index put send } def /insertitem { /insertitem clone&forward } def /deleteitem { /deleteitem clone&forward } def /changeitem { /changeitem clone&forward } def } dup ClassFrameMenu send ClassIconMenu send classend def systemdict /DontSetDefaultWindow known not { /DefaultWindow NeatWindow def % Hack to make ScrollWindow a subclass of NeatWindow. (gross) /ScrollWindow load type /arraytype eq { 10 dict begin /LiteWindow NeatWindow def ScrollWindow pop end } if } if end % systemdict From don@brillig.umd.edu Sun Aug 28 10:29:56 1988 Date: Sun, 28 Aug 88 10:29:56 EDT To: NeWS-makers@brillig.umd.edu Subject: visualize.ps (file 5 of 5) From: Don Hopkins Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % The NeWS Pseudo-Scientific Visualizer % -- the class browser for the other half of your brain. % Copyright (C) 1988 by Don Hopkins (don@brillig.umd.edu) % % You are free to redistribute this program. Please leave the comments % intact, add your own views and hallucinations, and pass it on to % friends! The author is not responsible for any time or brain cells % wasted with this software. (Has anybody ever actually gotten sued for % that?) % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % We've got to have the classes PieMenu and PulloutPieMenu are defined. systemdict /PieMenu known not { (NeWS/piemenu.ps) LoadFile not { currentcursorlocation [(Need) (piemenu.ps)] popmsg pop currentprocess killprocess } if } if systemdict /PulloutPieMenu known not { (NeWS/pullout.ps) LoadFile not { currentcursorlocation [(Need) (pullout.ps)] popmsg pop currentprocess killprocess } if } if /PSVisualizerWindow DefaultWindow dictbegin /hfrob .3 def /sfrob .5 def /bfrob .3 def /procs 1 def /maxprocs 10 def /maxdepth 0 def /thing rootmenu def /highmark 10 def /pp null def /FrameLabel (The NeWS Pseudo-Scientific Visualizer!) def /IconLabel (PS Visualizer) def /IconImage /eye def dictend classbegin /new { /new super send begin /maxdepth countdictstack 5 add def currentdict end } def /destroy { % clean up drain pp type /processtype eq { pp killprocessgroup /pp null def /thing null def } if /destroy super send } def /drain { maxdepth /maxdepth 0 def 50 { pause procs 0 eq {exit} if } repeat /maxdepth exch def } def /PaintClient { { clear newprocessgroup drain pp null ne { pp killprocessgroup % why doesn't this kill all of 'em??? } if /pp currentprocess def erasepage random random sqrt random sqrt sethsbcolor /highmark countdictstack def /procs 1 def clippath pathbbox scale pop pop .5 .5 translate .05 .05 scale {/thing load visualize} fork waitprocess pop } fork pop } def /ignorekeys 20 dict def ignorekeys begin /TopCanvas dup def /BottomCanvas dup def /CanvasAbove dup def /Parent dup def /FrameMenu dup def /IconMenu dup def /ParentDict dup def /ParentDictArray dup def end /cvfixed { 16384 mul floor cvi -14 bitshift } def /wrap { dup floor sub cvfixed } def % This is useful for finding core leaks ... (Really!) /context-string { % => (string) () currentprocess /DictionaryStack get dup length 2 sub 2 exch getinterval { dup /obj known { begin i obj 3 -1 roll (%/%:%) sprintf end } {pop} ifelse } forall 1 index exch (% = %) sprintf } def /visualize { % obj => - % count 5 gt {/foo dbgbreak} if pause countdictstack maxdepth ge { countdictstack highmark gt { % Uncomment this to hunt for core leaks. % context-string (High water: %\n) [3 -1 roll] dbgprintf /highmark countdictstack store } if pop } { { gsave currenthsbcolor 3 -1 roll random hfrob mul add wrap 3 -1 roll random sfrob mul add wrap sqrt % Crank up the saturation! 3 -1 roll random bfrob mul add wrap sqrt % Crank up the brightness! sethsbcolor dup type { % /canvastype /dicttype { newpath 0 0 1 0 360 arc closepath 0 0 .9 0 360 arc closepath 0 0 .2 0 360 arc closepath eofill 10 dict begin /obj exch cvlit def /pieces obj length def pieces 0 ne { /step 360 pieces div def obj { pause countdictstack maxdepth ge {pop pop exit} if /thing exch cvlit def /i exch cvlit def gsave 2.5 0 translate .6 .6 scale i visualize 2.5 0 translate ignorekeys i known not { thing } { /triangle } ifelse visualize grestore step rotate } forall } if end } /arraytype { newpath 0 0 1 0 360 arc closepath 0 0 .9 0 360 arc closepath eofill 10 dict begin /obj exch cvlit def /pieces obj length def pieces 0 ne { /step 360 pieces div def /i -1 def obj { pause countdictstack maxdepth ge {pop exit} if /thing exch cvlit def /i i 1 add def gsave 2.5 0 translate .6 .6 scale thing visualize grestore step rotate } forall } if end } /stringtype { length 1 add newpath -.5 -.1 % x y 3 -1 roll 5 div .5 add .2 % x y w h rectpath fill } /realtype /integertype { dup 100 div wrap 1 index 10 div wrap 3 -1 roll wrap setrgbcolor -.4 -.4 .8 .8 rectpath fill } /eventtype { pop -.8 -.8 1.6 1.6 rectpath -.8 .8 moveto 0 0 lineto -.8 -.8 lineto stroke } /nulltype { pop gsave -90 rotate -1 -.3 translate 2 2 scale newpath % Nick Turner's finger .2 0 moveto 0 .3 lineto .1 .5 lineto .2 .5 lineto .2 .55 lineto .3 .6 lineto .4 .55 lineto .4 .95 lineto .5 1 lineto .6 .95 lineto .6 .55 lineto .7 .6 lineto .8 .55 lineto .8 .5 lineto .9 .55 lineto 1 .5 lineto 1 .3 lineto .8 0 lineto closepath fill grestore } /operatortype { pop -.2 -.2 .4 .4 rectpath 0 0 .5 0 360 arc eofill } /processtype { pop newpath -.5 -.5 moveto 1 -.4 lineto 1 -.2 lineto .8 -.2 lineto 1 .4 lineto 1 1 lineto .5 .3 lineto -.5 .5 lineto closepath eofill } % /canvastype { % -.5 -.5 translate % imagecanvas % } /Default { pop newpath % -.5 -.5 1 1 rectpath 0 -.5 moveto 1 0 lineto 0 .5 lineto closepath % stroke % -.4 -.4 .8 .8 rectpath eofill } } case grestore } % A verb, Senator Kennedy, we need a verb! random .6 lt procs maxprocs lt and { /procs procs 1 add store { exec /procs procs 1 sub store } fork pop pop pop } { exec } ifelse % mumble frotz ... } ifelse } def % Menu definitions /ColorFrobMenu [ [(0.0) (0.02) (0.05) (0.1) (0.2) (0.3) (0.4) (0.5) (0.6) (0.7) (0.8) (0.9) (1.0) (99)] ] [ (HueFrob) { ThisWindow /hfrob getmenuarg cvr put } (BrightnessFrob) { ThisWindow /bfrob getmenuarg cvr put } (SaturationFrob) { ThisWindow /sfrob getmenuarg cvr put } ] /new PulloutPieMenu send def /ThingMenu [ (SendContexts) { ThisWindow /thing currentprocess /SendContexts get put } (UI_private) { ThisWindow /thing UI_private put } (foo) { ThisWindow /thing /foo load put } (rootmenu) { ThisWindow /thing rootmenu put } (DefaultMenu) { ThisWindow /thing DefaultMenu put } (userdict) { ThisWindow /thing userdict put } (bar) { ThisWindow /thing /bar load put } (Item) { ThisWindow /thing Item put } ] /new PieMenu send def /ClientMenu [ [] [(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (9999)] [] [(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20)] ] [ (Thing...) ThingMenu (MaxDepth) { getmenuarg cvi { countdictstack add /maxdepth exch def } ThisWindow send } (ColorFrob...) ColorFrobMenu (MaxProcs) { ThisWindow /maxprocs getmenuarg cvi put } ] /new PulloutPieMenu send def % Hurray for you -- you're reading the source code! % You can run a psh, and change foo and bar in systemdict to whatever % you want to look at! (warning: systemdict gets "unregistered" errors!) % To find core leaks, visualize objects in your application's userdict, % and look for the infinite regression of circular references. systemdict /foo ClientMenu put systemdict /bar UserProfile put classend def /win framebuffer /new PSVisualizerWindow send def { reshapefromuser map ClientCanvas /Retained true put } win send