From don Wed Nov 29 04:21:43 1989 Date: Wed, 29 Nov 89 04:21:43 -0500 To: NeWS-makers@brillig.umd.edu Subject: BTOL 1.1 From: korp@tripoli.ees.anl.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Wow!!! I got quite a few more responses than I expected. I have tried to mail BTOL to all those who asked for it. Also because of the volume of responses I have decided to post BTOL 1.1 to NeWS-makers. Since it seems that quite a few of you are interested in BTOL, I would like to encourage your comments on how to improve it, what bugs to fix, etc.. Thanks to all that sent responses! To Fred Larsen in Norway, your return addresses both bounced back to me. I hope you get the copy off of NeWS-makers. PS: BTOL will be available from the news-tape located on tumtum.cs.umd.edu (128.8.128.49) in the utilities subdirectory at some later date. From don Wed Nov 29 04:24:21 1989 Date: Wed, 29 Nov 89 04:24:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: This is BTOL 1.1 From: korp@tripoli.ees.anl.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% BTOL -- VERSION 1.1 %%% (Better Than Op*n L**k) %%% %%% %%% Version 1.1: %%% Now includes support for tear off menus! There is also a %%% minor programming change. After making the appropriate calls to %%% Make*Control, one must now call MoveFrameControls explicitly. %%% %%% Version 1.0: %%% This work was originaly generated to improve on the standard %%% lite window and menu implementations. Besides, we were all getting %%% tired of following those crazy pullright menus 4-5 levels deep. %%% %%% This is Version 1.0 of the BTOL window package %%% Feel free to use this code as you like, provided this header is %%% left intact. If you come up with neat new features, questions, bugs, %%% ideas or whatever let us know, it would be greatly appreciated. %%% %%% %%% Peter A. Korp %%% Argonne National Laboratory %%% Visual Interfaces Section %%% korp@athens.ees.anl.gov %%% %%% David C. Mak %%% Argonne National Laboratory %%% Visual Interfaces Section %%% mak@athens.ees.anl.gov %%% %%% David G. Zawada %%% Argonne National Laboratory %%% Visual Interfaces Section %%% zawada@athens.ees.anl.gov %%% %%% %%% %%% %%% BTOL provides NeWS application programmers with 5 new classes that %%% allow for writing more visually appealing software. These classes %%% implement new: %%% %%% 1) Buttons %%% 2) Menu Buttons %%% 3) Base Windows %%% 4) Menus %%% 5) Application Windows %%% %%% In Developing BTOL, we were aware of the standard lite API and %%% attempted to adhere to it in general, but did not feel BTOL had %%% to made 100% lite compatible. We feel it would require little %%% time to actually make it compatible and will do this if there is %%% enough user interest. %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolButton %%% %%% Purpose: To create a new button that conformed to our interface %%% %%% Useful methods: %%% %%% /new % label => instance %%% - creates a new instance of BtolButton %%% /resetcolors % - => - %%% - reset button colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /Activate % - => - %%% - allows button notify proc notification %%% /DeActivate % - => - %%% - Grays out button and disallow notification %%% /HiLite % - => - %%% - HiLite the button %%% /DeHiLite % - => - %%% - DeHilite the button %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolMenuButton %%% %%% Purpose: Create a button that can have a submenu off of it %%% %%% Useful methods: %%% %%% /new % Pullright label notifyproc ParentMenu width height => instance %%% - creates a new instance of BtolMenuButton %%% /movesubmenu % - => - %%% - moves the buttons submenu to its current x and y by mapping it %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolWindow %%% %%% Purpose: Create a window that has an array available for items that %%% will go into window as well as eventmgr. The items are %%% disposed of correctly when you destory the window %%% %%% Useful methods: %%% %%% /new % parentcanvas => instance %%% - creates a new instance of BtolWindow %%% /resetcolors % - => - %%% - reset button colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /hide % - => - %%% - If used from a BtolAppwin, allows the AppWin to hide all of %%% its children when it is deselected %%% /unhide % - => - %%% - If used from a BtolAppwin, allows the AppWin to show all of %%% its children when it is selected %%% /HiLiteFrame % - => - %%% - HiLite the window %%% /DeHiLiteFrame % - => - %%% - DeHilite the window %%% /CreateZapControl % - => - %%% - Creates a control in upper right of window to zap window %%% /CreateCloseControl % - => - %%% - Creates a control in upper left of window to close windows %%% /CreateResizeControl % - => - %%% - Creates resize controls at bottom of screen %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolMenu %%% %%% Purpose: Create a menu that has walking submenus and conforms to BTOL %%% UI %%% %%% Useful methods: %%% %%% /new % [menuitem names] [actions] => instance %%% - creates a new instance of BtolMenu %%% /resetcolors % - => - %%% - reset menu colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for menu %%% /dragmenu % - => - %%% - if this menu is a submenu it moves to parents right %%% /detach % - => - %%% - unmaps all submenus %%% /getcmi % - => BtolMenuButton %%% - get current menu item (Button that has its submenu showing) %%% /flipcmi % BtolMenuButton => - %%% - flip the state of current menu item %%% /setcmi % BtolMenuButton => - %%% - set the current menu item %%% /AutoSize % - => - %%% - after all the items are put in a menu run AutoSize to make %%% all the menu items and label fit nice. (Run before mapping) %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolAppWin %%% %%% Purpose: Create an application window with BTOL look and feel %%% %%% Useful methods: %%% %%% /new % Framelabel => instance -or- canvas => instance %%% - creates a new instance of BtolAppWindow %%% /newsubwin % Framelabel => subwindow %%% - create a subwindow for this application. It will automatically %%% open and close correctly, with the main AppWin %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /getappwin % - => BtolAppWin %%% - return the AppWindow whose menu is currently showing %%% /setappwin % BtolAppWin => - %%% - set the current AppWindow to be this AppWin %%% /destroychild % subwindow => - %%% - destroys a child subwindow %%% /destroychildren % [subwindows] => - %%% - destroys several child subwindows %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class structure of BTOL %%% ----------------------- %%% %%% ------------ ------------- %%% |LiteWindow| |LabeledItem| %%% ------------ ------------- %%% | | %%% ------v----- -----v------ %%% |BtolWindow| |BtolButton| %%% ------------ ------------ %%% | | %%% _________|__________ | %%% | | | %%% -------v------- ---v------ ------v--------- %%% |BtolAppWindow| |BtolMenu|<-----|BtolMenuButton| %%% --------------- ---------- ---------------- %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Example -1- %%% %%% A trivial BTOL program. We let the Btol code do all the work. %%% /win framebuffer /new BtolAppWin send def %%% { %%% /PaintClient %%% { %%% 0 fillcanvas %%% 0 1 random 100 mul { random mul random 144 mul random random random setrgbcolor %%% moveto 240 100 lineto stroke } for %%% } def %%% reshapefromuser %%% totop %%% map %%% } win send %%% %%% psh Example -1- again and watch how the menus interact %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Example -2- %%% %%% A simple sample application written for BTOL %%% %%% /AppFont /Courier findfont def %%% /AppFontSize 18 def %%% %%% /changefontsize % dsize => - %%% { %%% /AppFontSize AppFontSize 3 -1 roll add 8 max store %%% %%% AppFont AppFontSize scalefont %%% /paint win send %%% } def %%% %%% %%% /changefont % fontname => - %%% { %%% /AppFont exch findfont store %%% 0 changefontsize %%% } def %%% %%% %%% /colormenu %%% [() dup dup dup dup dup dup dup dup dup] %%% [ {Hue /sethue /getappwin BtolAppWin send send} 9 { dup } repeat ] %%% /new BtolMenu send %%% dup /MenuItems get 0 1 9 %%% { dup 10 div /sethue 3 index 4 -1 roll get send } for pop %%% def %%% %%% /sizemenu %%% [(Enlarge by 2) (Enlarge by 10) (Reduce by 2) (Reduce by 10)] %%% [ { 2 changefontsize } { 10 changefontsize } { -2 changefontsize } { -10 changefontsize } ] /new BtolMenu send def %%% %%% /fontmenu %%% [ %%% (Courier) (Helvetica) (Times-Roman) %%% ] %%% [ { ItemLabel changefont } 2 index length 1 sub { dup } repeat ] /new BtolMenu send def %%% %%% /changefontmenu %%% [ (Font) (Size) ] %%% [ fontmenu sizemenu ] /new BtolMenu send def %%% %%% colormenu %%% /sethue %%% { %%% /Hue exch def %%% /HiLiteColor Hue 0.3 1 hsbcolor def %%% /ShadowColor Hue 1 0.45 hsbcolor def %%% /FaceColor Hue 0.4 .9 hsbcolor def %%% %%% HiLiteFrame %%% paint %%% } %%% put %%% %%% /mainmenu %%% [(Window Color) (Change Font) (Hide) (Quit)] %%% [ %%% colormenu %%% changefontmenu %%% { /flipiconic /getappwin BtolAppWin send send } %%% { /ZapNotify /getappwin BtolAppWin send send } %%% ] /new BtolMenu send def %%% %%% { %%% /FrameLabel (Example #2) def %%% AutoSize %%% } mainmenu send %%% %%% %%% /win framebuffer /new BtolAppWin send def %%% { %%% CreateCloseControl %%% CreateResizeControl %%% /FrameMenu mainmenu def %%% /FrameLabel (A BTOL window! Example #2) def %%% /IconLabel (Example #2) def %%% /PaintClient %%% { %%% gsave %%% 0 fillcanvas %%% 0 1 random 100 mul %%% { %%% random mul random 144 mul %%% random random random setrgbcolor %%% moveto 240 100 lineto stroke %%% } for %%% AppFont AppFontSize scalefont setfont %%% 50 50 moveto (BTOL - it just looks better!) show %%% grestore %%% } def %%% reshapefromuser %%% ClientCanvas /Retained true put %%% totop %%% map %%% } win send %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Have fun with the sample code and please let us know how you like %%% the product. %%% - Dave, Dave and Peter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% systemdict /LabeledItem known not { ($NEWSHOME/lib/NeWS/liteitem.ps) run } if systemdict begin % ============================= Btol Button Item ============================= /BtolButton LabeledItem dictbegin /Activated? true def /Hue 0 def /ShadowColor .1 .1 .1 rgbcolor def /HiLiteColor .9 .9 .9 rgbcolor def /FaceColor .7 .7 .7 rgbcolor def /CurrentTextColor ShadowColor def dictend classbegin /new % label notifyproc parentcanvas => instance { % fake a labeled item. dup type /canvastype eq {() /Center 4 2 roll} {() /Center 6 2 roll} ifelse /new super send begin /ItemRadius 0 def /ItemFrame 2 def /ItemBorder null def % /ItemID 0 def %%%DZpatch -- used in dock currentdict end } def /resetcolors { /ShadowColor .1 .1 .1 rgbcolor store /HiLiteColor .9 .9 .9 rgbcolor store /FaceColor .7 .7 .7 rgbcolor store } def /sethue % hue { /Hue exch def /HiLiteColor Hue 0.3 1 hsbcolor def /ShadowColor Hue 1 0.45 hsbcolor def /FaceColor Hue 0.4 .9 hsbcolor def } def /sethsb % color -> - { /FaceColor exch def } def /reshape % x y w h => - { /ItemHeight exch def /ItemWidth exch def LabelSize /LabelHeight exch def /LabelWidth exch def ItemBorder null eq {/ItemBorder ItemFrame def} if /ItemWidth ItemWidth ItemBorder ItemGap add 2 mul LabelWidth add max def /ItemHeight ItemHeight ItemBorder ItemGap add 2 mul LabelHeight add max def /LabelX ItemWidth LabelWidth sub 2 div LabelX add def /LabelY ItemHeight LabelHeight sub 2 div LabelY add def ItemLabel type /stringtype eq { % adjust for descenders /LabelY LabelY ItemLabelFont fontdescent 2 div sub ItemBorder max def } if ItemRadius 0 gt ItemRadius .5 le and { /ItemRadius ItemWidth ItemHeight min ItemRadius mul def } if ItemWidth ItemHeight /reshape super send } def /PaintItem { ItemValue true eq {HiLightButton} {PaintButton} ifelse } def /SetButtonValue % bool => - { /ItemValue exch store ItemValue ItemPaintedValue ne {/paint self send} if } def /ClientDown { Activated? {true SetButtonValue} if } def /ClientUp { Activated? { ItemValue {NotifyUser} if false SetButtonValue StopItem } if } def /ClientEnter {Activated? {true SetButtonValue} if} def /ClientExit {Activated? {false SetButtonValue} if } def /Activate { /CurrentTextColor ShadowColor store /Activated? true def paint } def /DeActivate { gsave /CurrentTextColor FaceColor setcolor currenthsbcolor .2 sub hsbcolor def /Activated? false def paint grestore } def /HiLite { /State true store paint } def /DeHiLite { /State false store paint } def /HiLightButton { gsave HiLiteColor setcolor 0 0 ItemWidth ItemHeight rectpath fill HiLiteColor PaintShadow ShadowColor PaintHiLite HiLiteColor PaintFace ItemFrame dup neg translate PaintLabel grestore } def /PaintButton { gsave FaceColor setcolor 0 0 ItemWidth ItemHeight rectpath fill ShadowColor PaintShadow HiLiteColor PaintHiLite FaceColor PaintFace PaintLabel grestore } def /PaintFace % FaceColor => - { setcolor ItemFrame 0 0 ItemWidth ItemHeight insetrect rectpath fill } def /PaintShadow % ShadowColor => - { setcolor 0 0 moveto ItemFrame ItemFrame rlineto ItemWidth ItemFrame 2 mul sub 0 rlineto 0 ItemHeight ItemFrame 2 mul sub rlineto ItemFrame ItemFrame rlineto 0 ItemHeight neg rlineto fill } def /PaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 ItemHeight rlineto ItemWidth 0 rlineto ItemFrame neg dup rlineto ItemWidth ItemFrame 2 mul sub neg 0 rlineto 0 ItemHeight ItemFrame 2 mul sub neg rlineto fill } def /PaintLabel { CurrentTextColor setcolor ItemLabelFont setfont ItemWidth 2 div ItemHeight ItemLabelFont fontheight ItemLabelFont fontdescent sub sub 2 div moveto ItemLabel cshow } def classend def pause pause % =============================BtolMenuButton Item============================= /BtolMenuButton BtolButton dictbegin /State false def /ParentMenu null def /PullRight? false def /ArrowSize 0 def /SubMenu null def dictend classbegin /new % Pullright label notifyproc ParentMenu width height => instance { 2 index /ClientCanvas get 3 1 roll 4 -1 roll 7 1 roll /new super send begin /ItemValue false def /ArrowSize ItemLabelFont fontheight 2 mul 3 div def /PullRight? exch def /ParentMenu exch def 0 0 move PullRight? { /ItemWidth ItemWidth ArrowSize 1.5 mul add def 0 0 ItemWidth ItemHeight reshape } if currentdict end } def /movesubmenu { SubMenu null ne ItemValue true eq and { /map SubMenu send } if } def /resetcolors { /resetcolors super send paint PullRight? { /resetcolors SubMenu send } if } def /sethue % hue => - { dup /sethue super send paint PullRight? { /sethue SubMenu send } { pop } ifelse } def /unmap { SubMenu null ne { /unmap SubMenu send } if } def /ZapNotify { SubMenu null ne { /ZapNotify SubMenu send } if } def /destroy { ZapNotify } def /PaintItem { %State true eq PullRight? and { /paint SubMenu send } if ItemValue true eq State true eq or {HiLightButton} {PaintButton} ifelse gsave PullRight? { ItemValue true eq State true eq or { ItemFrame dup neg translate } if ShadowColor setcolor ItemWidth ArrowSize 1.5 mul sub ItemHeight 2 div translate 0 ArrowSize 2 div neg moveto 0 ArrowSize 2 div lineto .866 ArrowSize mul 0 lineto stroke HiLiteColor setcolor .866 ArrowSize mul 0 moveto 0 ArrowSize 2 div neg lineto stroke } if grestore } def /PaintLabel { CurrentTextColor setcolor 10 ItemHeight ItemLabelFont fontheight ItemLabelFont fontdescent sub sub 2 div moveto ItemLabel show } def classend def pause pause /BtolWindow LiteWindow dictbegin /items null def /itemmgr null def /IsUp? false def /ControlInterests null def /ControlMgr null def /FrameTextColor 0 0 0 rgbcolor def /MenuLabel () def /BorderWidth 0 def /BorderLeft 1 def /BorderBottom 1 def /BorderRight 1 def /BorderTop 0 def /ControlSize 0 def /ControlFrame 2 def /IconFrame 2 def /ShadowColor .1 .1 .1 rgbcolor def /HiLiteColor .9 .9 .9 rgbcolor def /FaceColor .7 .7 .7 rgbcolor def /Resizable? false def /Closable? false def /Zappable? false def dictend classbegin /new % parentcanvas => window { /new super send begin /ClientMenu null def /ControlInterests 15 dict store /FrameFillColor FaceColor def /FrameTextColor ShadowColor def /FrameFont /Times-Roman findfont 18 scalefont def /BorderTop FrameFont fontheight 1.5 mul store /ControlSize FrameFont fontheight store /IconFont /Helvetica findfont 10 scalefont def currentdict end } def /map { /IsUp? true def /map super send } def /unmap { /IsUp? false def /unmap super send } def /unhide { IsUp? { /map super send } if } def /hide { IsUp? { /unmap super send } if } def /resetcolors { /ShadowColor .1 .1 .1 rgbcolor store /HiLiteColor .9 .9 .9 rgbcolor store /FaceColor .7 .7 .7 rgbcolor store } def /sethue % hue { /Hue exch def /HiLiteColor Hue 0.3 1 hsbcolor def /ShadowColor Hue 1 0.45 hsbcolor def /FaceColor Hue 0.4 .9 hsbcolor def /FrameFillColor FaceColor def /FrameTextColor ShadowColor def } def /ZapNotify { ClientCanvas /Retained false put FrameCanvas /Retained false put ClientCanvas 0 0 0 0 rectpath reshapecanvas FrameCanvas 0 0 0 0 rectpath reshapecanvas FrameEventMgr null ne { FrameEventMgr killprocess } if itemmgr null ne {itemmgr killprocess} if ControlMgr null ne { ControlMgr killprocess } if currentdict /ZapControl undef currentdict /CloseControl undef currentdict /LeftStretchControl undef currentdict /MiddleStretchControl undef currentdict /RightStretchControl undef currentdict /ControlMgr undef currentdict /FrameEventMgr undef currentdict /ClientCanvas undef currentdict /FrameCanvas undef currentdict /ControlInterests undef currentdict /FrameInterests undef currentdict /items undef } def /CloseNotify { flipiconic } def /destroy { ZapNotify } def /PaintFrame % { PaintFrameBorder 0 FrameHeight BorderTop sub 1 add FrameWidth 1 sub BorderTop 1 sub rectpath gsave FrameFillColor setcolor fill grestore FrameTextColor setcolor stroke PaintFrameControls PaintFrameLabel } def /HiLiteFrame { /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def paintframe } def /DeHiLiteFrame { /FrameFillColor FaceColor def /FrameTextColor ShadowColor def paintframe } def /IconPaintFace % FaceColor => - { setcolor IconFrame 0 0 IconWidth IconHeight insetrect rectpath fill } def /IconPaintShadow % ShadowColor => - { setcolor 0 0 moveto IconFrame dup rlineto IconWidth IconFrame 2 mul sub 0 rlineto 0 IconHeight IconFrame 2 mul sub rlineto IconFrame dup rlineto 0 IconHeight neg rlineto fill pause } def /IconPaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 IconHeight rlineto IconWidth 0 rlineto IconFrame neg dup rlineto IconWidth IconFrame 2 mul sub neg 0 rlineto 0 IconHeight IconFrame 2 mul sub neg rlineto fill pause } def /PaintIconLabel { IconFont setfont 0 IconHeight IconFont fontheight 1.5 mul sub IconWidth IconFont fontheight 1.5 mul rectpath ShadowColor setcolor fill HiLiteColor setcolor IconWidth 2 div IconHeight IconFont fontheight sub moveto IconLabel cshow pause } def /PaintIcon { gsave IconCanvas setcanvas FaceColor fillcanvas IconImage null ne { 0 0 moveto IconImage showicon } if IconLabel null ne { PaintIconLabel } if HiLiteColor IconPaintHiLite ShadowColor IconPaintShadow grestore } def /CreateFrameInterests % - => - (Create frame control interests) { FrameInterests begin /FrameTopEvent PointButton /totop DownTransition FrameCanvas eventmgrinterest def /FrameMoveEvent AdjustButton /slide DownTransition FrameCanvas eventmgrinterest def /FrameMenuEvent MenuButton {} DownTransition FrameCanvas eventmgrinterest def /FrameDamageEvent /Damaged /FixFrame null FrameCanvas eventmgrinterest def /FrameEnterEvent /EnterEvent /EnterFrame [0 2] FrameCanvas eventmgrinterest def /FrameExitEvent /ExitEvent /ExitFrame [0 2] FrameCanvas eventmgrinterest def /FrameDoItEvent /DoItEvent {gsave /ClientData get cvx exec grestore} /Window null eventmgrinterest def /FrameIconicFcnKeyEvent /WindowFunction /flipiconic /FlipIconic FrameCanvas eventmgrinterest def /FrameFrontFcnKeyEvent /WindowFunction /totop /FlipFront FrameCanvas eventmgrinterest def /IconMenuEvent {} def end } def pause /CreateCloseControl { gsave FrameCanvas setcanvas /CloseControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /Closable? true def ControlInterests begin /FrameCloseEvent PointButton /CloseNotify DownTransition CloseControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 ControlSize dup rectpath CloseControl reshapecanvas grestore } def /CreateZapControl { gsave FrameCanvas setcanvas /ZapControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /Zappable? true def ControlInterests begin /FrameZapEvent PointButton /destroy DownTransition ZapControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 ControlSize dup rectpath ZapControl reshapecanvas grestore } def /CreateResizeControl { gsave /Resizable? true def /BorderBottom FrameFont fontheight 2 div 10 max def FrameCanvas setcanvas ShapeClientCanvas /LeftStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /MiddleStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /RightStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def ControlInterests begin /FrameLeftStretchEvent PointButton {totop stretchcorner} DownTransition LeftStretchControl eventmgrinterest def /FrameMiddleStretchEvent PointButton {totop stretchwindowedge} DownTransition MiddleStretchControl eventmgrinterest def /FrameRightStretchEvent PointButton {totop stretchcorner} DownTransition RightStretchControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 15 BorderBottom rectpath LeftStretchControl reshapecanvas 0 0 FrameWidth 30 sub BorderBottom rectpath MiddleStretchControl reshapecanvas 0 0 15 BorderBottom rectpath RightStretchControl reshapecanvas grestore } def /CreateIconInterests % - => - (Create icon control interests) { FrameInterests begin /IconOpenEvent PointButton /flipiconic DownTransition IconCanvas eventmgrinterest def /IconMoveEvent AdjustButton /slide DownTransition IconCanvas eventmgrinterest def /IconMenuEvent {} def /IconDamageEvent /Damaged /FixIcon null IconCanvas eventmgrinterest def /IconIconicFcnKeyEvent /WindowFunction /flipiconic /FlipIconic IconCanvas eventmgrinterest def /IconFrontFcnKeyEvent /WindowFunction /totop /FlipFront IconCanvas eventmgrinterest def end } def /CreateFrameControls % - => - (Create frame control canvases/items) { } def /CreateFrameCanvas % - => - (Create empty frame canvas) { /FrameCanvas ParentCanvas newcanvas def /ptr /ptr_m FrameCanvas setstandardcursor } def /CreateFrameMenu { } def /CreateIconMenu { } def /MoveFrameControls % - => - ([Re]set frame control shapes) { gsave Closable? { CloseControl setcanvas ControlFrame FrameHeight BorderTop sub BorderTop ControlSize sub 2 div add movecanvas } if Zappable? { ZapControl setcanvas FrameWidth ControlSize ControlFrame add sub FrameHeight BorderTop sub BorderTop ControlSize sub 2 div add movecanvas } if Resizable? { LeftStretchControl setcanvas 0 0 movecanvas MiddleStretchControl setcanvas 0 0 FrameWidth 30 sub BorderBottom rectpath MiddleStretchControl reshapecanvas 15 0 movecanvas RightStretchControl setcanvas FrameWidth 15 sub 0 movecanvas } if grestore } def /PaintFrameBorder { % - => - (Paint frame border areas) ShadowColor strokecanvas } def /PaintFocus { } def /PaintFrameLabel { gsave FrameTextColor setcolor FrameFont setfont FrameWidth 2 div FrameHeight FrameFont fontheight sub moveto FrameLabel cshow grestore } def /ControlPaintFace % FaceColor => - { setcolor ControlFrame 0 0 ControlSize dup insetrect rectpath fill } def /ControlPaintShadow % ShadowColor => - { setcolor 0 0 moveto ControlFrame dup rlineto ControlSize ControlFrame 2 mul sub 0 rlineto 0 ControlSize ControlFrame 2 mul sub rlineto ControlFrame dup rlineto 0 ControlSize neg rlineto fill } def pause /ControlPaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 ControlSize rlineto ControlSize 0 rlineto ControlFrame neg dup rlineto ControlSize ControlFrame 2 mul sub neg 0 rlineto 0 ControlSize ControlFrame 2 mul sub neg rlineto fill } def /PaintFrameControls { gsave Closable? { CloseControl setcanvas FaceColor setcolor clippath fill ShadowColor ControlPaintShadow HiLiteColor ControlPaintHiLite FaceColor ControlPaintFace ShadowColor setcolor ControlFrame dup 2 div add 0 0 ControlSize dup insetrect rectpath fill FaceColor setcolor ControlFrame dup add 0 0 ControlSize dup ControlFrame sub insetrect rectpath fill } if Zappable? { ZapControl setcanvas FaceColor setcolor clippath fill ShadowColor ControlPaintShadow HiLiteColor ControlPaintHiLite FaceColor ControlPaintFace ShadowColor setcolor 2 { ControlFrame dup add dup moveto ControlSize ControlFrame dup add sub dup lineto ControlFrame dup add ControlSize ControlFrame dup add sub moveto ControlSize ControlFrame dup add sub ControlFrame dup add lineto stroke -1 0 translate } repeat } if Resizable? { LeftStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas MiddleStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas RightStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas } if grestore } def /reshape { /reshape super send MoveFrameControls } def classend def pause pause /BtolMenu BtolWindow dictbegin /CMI null def /MenuActions null def /MenuChoices null def /MenuItemFont /Helvetica findfont 14 scalefont def /MenuLabelFont /Helvetica-Bold findfont 14 scalefont def /MenuItems [] def /MenuItemsEM null def /ParentMenu null def /Pinned? false def dictend classbegin /new % [menu items names] [actions] => window { framebuffer /new super send begin /MenuActions exch store /MenuChoices exch store /FrameFont MenuLabelFont def /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def /BorderWidth 0 def /BorderLeft 0 def /BorderRight 0 def /BorderBottom 0 def /BorderTop MenuLabelFont fontheight 10 add def 0 100 1 1 reshape CreateZapControl 0 0 1 1 rectpath ZapControl reshapecanvas ClientCanvas /Retained true put MakeMenuItems currentdict end } def /dragmenu { ParentMenu null ne { gsave framebuffer setcanvas ParentMenu /FrameCanvas get getcanvaslocation ParentMenu begin FrameHeight add exch FrameWidth add exch end FrameHeight sub move grestore } if } def /move { /move super send CMI null ne { pause /dragmenu CMI /SubMenu get send } if } def /slide { { GetCanvas setcanvas InteractionLock { 20 dict begin /absmove { gsave %Canvas setcanvas [1 0 0 1 0 0] setmatrix yo add exch xo add exch move grestore pause } def gsave [1 0 0 1 0 0] setmatrix % initmatrix /Canvas currentcanvas def currentcursorlocation /yo exch neg def /xo exch neg def clippath pathbbox /height exch def /width exch def pop pop Canvas parentcanvas createoverlay setcanvas 0 0 { absmove newpath } getanimated waitprocess aload pop absmove grestore end } monitor ParentMenu null ne Pinned? not and {detach} if } fork pop } def /map { MenuItems { /SubMenu get dup null ne { {Pinned? {map} if } exch send } { pop } ifelse } forall CMI null ne { /map CMI /SubMenu get send } if /map super send } def /unmap { /unmap super send CMI null ne { /unmap CMI /SubMenu get send } if MenuItems { /SubMenu get dup null ne { {Pinned? {unmap} if } exch send } { pop } ifelse } forall } def /totop { MenuItems { /SubMenu get dup null ne { {Pinned? {totop} if } exch send } { pop } ifelse } forall CMI null ne { /totop CMI /SubMenu get send } if /totop super send } def /unmapsubmenus % - => - { CMI null ne { /unmapsubmenus CMI /SubMenu get send } if unmap } def /resetcolors { /resetcolors super send HiLiteFrame MenuItems { /resetcolors exch send } forall } def /sethue % hue { dup /sethue super send HiLiteFrame MenuItems { 1 index /sethue 3 -1 roll send } forall pop } def /flipcmi % BtolMenuButton => - { dup CMI eq { dup /State get { pop null setcmi } { setcmi } ifelse } { setcmi } ifelse } def /setcmi % BtolMenuButton => - %%% cmi(Current Menu Item) { CMI null ne { /DeHiLite CMI send /unmapsubmenus CMI /SubMenu get send } if /CMI exch store CMI null ne { CMI /SubMenu get /Pinned? get { /CMI null store } { /HiLite CMI send {AutoSize totop dragmenu map} CMI /SubMenu get send } ifelse } if } def /getcmi % - => BtolMenuButton { CMI } def /detach { Pinned? not { /Pinned? true store 0 0 ControlSize dup rectpath ZapControl reshapecanvas MoveFrameControls PaintFrameControls } if {CMI null ne {/DeHiLite CMI send /CMI null def} if} ParentMenu send } def /ReshapeMenuItems % - => - { /tmp MenuItems 0 get /ItemHeight get def 0 1 MenuItems length 1 sub { 1 FrameHeight BorderTop sub tmp 1 add 3 index 1 add mul sub FrameWidth 2 sub tmp /reshape MenuItems 7 -1 roll get send } for } def /AutoSize % called after any change to the frame label or font { gsave FrameFont setfont /FrameWidth FrameLabel ( ) append stringwidth pop ControlSize 2 add dup add add def grestore MenuItems { /FrameWidth exch /ItemWidth get FrameWidth max store pause } forall /FrameWidth FrameWidth 2 add def /FrameHeight MenuItems length MenuItems 0 get /ItemHeight get 1 add mul BorderTop add def FrameX FrameY FrameWidth FrameHeight reshape ReshapeMenuItems } def /MakeMenuItems % - => - { /MenuItems [ 0 1 MenuChoices length 1 sub { MenuActions 1 index get type /dicttype eq { MenuChoices self MenuActions 3 index get begin /ParentMenu exch def /FrameLabel exch 2 index get def end true MenuChoices 2 index get { self /flipcmi ParentMenu send } self 0 0 /new BtolMenuButton send dup begin /SubMenu MenuActions 4 -1 roll get def /ItemLabelFont MenuItemFont def end } { false MenuChoices 2 index get MenuActions 4 -1 roll get self 0 0 /new BtolMenuButton send dup begin /ItemLabelFont MenuItemFont def end } ifelse 0 0 /move 3 index send pause } for ] def /MenuItemsEM MenuItems forkitems def AutoSize } def /PaintClient { MenuItems paintitems } def /CreateFrameInterests { % - => - (Create frame control interests) FrameInterests begin /FrameTopEvent PointButton /totop DownTransition FrameCanvas eventmgrinterest def /FrameMoveEvent AdjustButton /slide DownTransition FrameCanvas eventmgrinterest def /FrameDamageEvent /Damaged /FixFrame null FrameCanvas eventmgrinterest def end } def /ZapNotify { MenuItems {/ZapNotify exch send} forall MenuItemsEM null ne { MenuItemsEM killprocess } if /ZapNotify super send currentdict /MenuItems undef currentdict /ParentMenu undef currentdict /CMI undef } def /destroy { Pinned? { unmap 0 0 1 1 rectpath ZapControl reshapecanvas /Pinned? false store } { ZapNotify } ifelse } def /CreateFrameMenu {} def /flipiconic {} def classend def pause pause /BtolAppWin BtolWindow dictbegin /Childern null def dictend classbegin /AppWindow null def /TmpAppWin null def /new % label => instance { dup type /stringtype eq {framebuffer} {() exch} ifelse /new super send begin /FrameLabel exch def /IconLabel FrameLabel def /FrameMenu [(Info ...) (Hide) (Quit)] [ {} { /flipiconic /getappwin BtolAppWin send send } { /ZapNotify /getappwin BtolAppWin send send } ] /new BtolMenu send def FrameMenu /FrameLabel FrameLabel put /AutoSize FrameMenu send /PaintClient { FaceColor fillcanvas } def FrameX FrameY 1 1 reshape CreateZapControl currentdict AppWindow null ne { /totop AppWindow send } if /Children [] def end } def /newsubwin { framebuffer /new BtolWindow send dup dup /Children Children dup length 1 add 4 -1 roll arrayinsert def self exch begin /ParentApp exch def /FrameLabel 3 -1 roll def ParentApp begin ShadowColor FaceColor HiLiteColor end /HiLiteColor exch def /FaceColor exch def /ShadowColor exch def /IconLabel FrameLabel def /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def /PaintClient { FaceColor fillcanvas } def /totop { ParentApp /FrameMenu get /FrameCanvas get /CanvasAbove get null ne ParentApp /FrameMenu get /FrameCanvas get /CanvasBelow get FrameCanvas ne or { ParentApp /setappwin ParentApp send /totop super send /totop ParentApp /FrameMenu get send } if } def /destroy { /unmap self send } def FrameX FrameY 1 1 reshape end } def /flipiconic { /unmap self send /Iconic? Iconic? not def IconX null eq { FrameX FrameY FrameHeight add IconHeight sub /move self send } if ZoomProc /map self send Iconic? not { self setappwin /totop FrameMenu send /map FrameMenu send } { /unmap FrameMenu send } ifelse } def /map { Iconic? not { Children { /unhide exch send } forall } if /map super send } def /unmap { Iconic? not { Children { /hide exch send } forall } if /unmap super send } def /paint % { AppWindow self eq %FrameMenu /FrameCanvas get /Mapped get { /paint FrameMenu send } if /paint super send } def /totop % - => - { self setappwin FrameMenu /FrameCanvas get /CanvasAbove get null ne FrameMenu /FrameCanvas get /CanvasBelow get FrameCanvas ne or { /totop super send /totop FrameMenu send } if } def /resetcolors { /resetcolors super send FrameMenu null ne { /resetcolors FrameMenu send /paint FrameMenu send } if } def /sethue % hue => - { dup /sethue super send FrameMenu null ne { /sethue FrameMenu send } { pop } ifelse AppWindow self eq { HiLiteFrame painticon } if } def /getappwin % - => CurrentAppWindow { AppWindow } def /setappwin % BtolAppWin => - { /TmpAppWin exch store AppWindow TmpAppWin ne { AppWindow null ne { { /unmap FrameMenu send DeHiLiteFrame } AppWindow send } if /AppWindow TmpAppWin store AppWindow null ne { { /map FrameMenu send HiLiteFrame } AppWindow send } if } if } def /setmenu % BtolMenu => - { } def /ZapNotify { /ZapNotify FrameMenu send Children { /ZapNotify exch send } forall self getappwin eq {/AppWindow null store} if /ZapNotify super send } def /destroy { ZapNotify } def /arrayindex % array value => index true | false { 2 dict begin /i 0 def /v exch def false exch { /v load eq {pop i true exit} {/i i 1 add def} ifelse } forall currentdict /v undef currentdict /i undef end } def /destroychild % BtolWin => - { dup Children exch arrayindex { /Children Children 3 -1 roll arraydelete store /ZapNotify exch send } { pop console (Not a child of win\n) [] fprintf } ifelse } def /destroychildren % [BtolWin] => - { { dup Children exch arrayindex { /Children Children 3 -1 roll arraydelete store /ZapNotify exch send } { pop console (Not a child of win\n) [] fprintf } ifelse } forall } def /DeHiLiteFrame { Children { /DeHiLiteFrame exch send } forall /DeHiLiteFrame super send } def /HiLiteFrame { Children { /HiLiteFrame exch send } forall /HiLiteFrame super send } def classend def pause pause end From don Wed Nov 29 04:24:57 1989 Date: Wed, 29 Nov 89 04:24:57 -0500 To: NeWS-makers@brillig.umd.edu Subject: Request for program -- Thanks From: xylogics!world!bzs@CS.BU.EDU (Barry Shein) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I want to give a group thanks for all the program examples I received in response to my request for Sun/Expert. A lot of them were amusing, some even did what I wanted :-) All were quite good. I ended up picking the first one, in time order, which seemed to do exactly what I wanted to illustrate (no more, no less.) Again, thanks to everyone. I'll be back, we'll get your name in lights :-) -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs From don Wed Nov 29 04:25:11 1989 Date: Wed, 29 Nov 89 04:25:11 -0500 To: NeWS-makers@brillig.umd.edu Subject: Modifing Transparent field of NeWS 1.1 canvases From: mips!prls!philabs!ppgbms!pablo@apple.com (Pablo Gonzalez) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I currently have a situation where some of the child canvases that I create have their /Transparent field set to true(by NeWS). NeWS 1.1 does not seem to allow me to change this field to false! When I print out the value of this field( after setting /Transparent false store), it shows that it is still true. When/how can I modify this field? I was under the assumption that a child canvas inherits the field values of it' parent canvas. If the parent canvas has /Transparent = false, then the child canvas should have /Transparent=false when it is created. How does NeWS 1.1 determine what to set the Transparent field of canvases created by 'newcanvas'? Thanks, Pablo Gonzalez One Campus Drive Pleasantville, N.Y. 10570 (914) 741-4626 path ppgbms!moe!pablo@philabs.phillips.com From don Wed Nov 29 12:09:19 1989 Date: Wed, 29 Nov 89 12:09:19 -0500 To: NeWS-makers@brillig.umd.edu Subject: NeWS SIG at SUG From: Henry B. J. Krempel (ESS ISV Consultant) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) SPECIAL INTEREST GROUP ANNOUNCEMENT X11/NeWS BOF at Sun User's Group Anaheim Ca Room: Capistrano A&B Date: Thursday, December 7, 1989 Time: 5:15 to 6:15 p.m. Session Code: T50 This will include a presentations on "Using the NeWS side of X11/NeWS" by Henry Krempel (Sun Microsystems) and "Porting NeWSdraw to X11/NeWS" by Bruce Schwartz (Sun Microsystems) There is no charge and live demos will (electronic gods willing) be included. On the SUG schedule, this will be listed as: SIG-NeWS Toolkit, but will include more than just the NeWS toolkit. From don Fri Dec 1 13:20:30 1989 Date: Fri, 1 Dec 89 13:20:30 -0500 To: NeWS-makers@brillig.umd.edu Subject: info requested on 3179 terminal emulators for Sun 4 From: tekbspa!carol@lll-winken.llnl.gov (Carol Hausmann) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We are currently doing research on IBM-3169 terminal emulators running on a Sun 4 platform. We have reviewed Sun's CG3270 product which supports a superset of 3179 Model G features. This product runs with the News server. We would prefer an X11 version of this software (or even an X11/News version). Information on other products would be very useful. Any replies sent directly to me would be gratefully appreciated. Thanks. From don Sun Dec 3 03:52:31 1989 Date: Sun, 3 Dec 89 03:52:31 -0500 To: NeWS-makers@brillig.umd.edu Subject: Looking for Tips on Using Sun's NSE From: nsc!pyramid!unify!dgh@decwrl.dec.com (David Harrington) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We are in the process of installing Sun/3 workstations in our engineering group, connected to our ethernet. I am interested in using Sun's NSE because of all the "neat" and useful features it seems to have (in the 2 demo's I have seen :-). Has anybody out there in net.land had experience using NSE? I have heard that it may be early in the product's life to get too attached to it (a little like tar baby, perhaps :-?), at least on the 386i. Anyway, please e-mail responses; I'll post a summary. Thanks in advance. David Harrington Unify Corp. dgh@unify.UUCP or ... !{csusac,pyramid}!unify!dgh From don Thu Dec 7 18:53:40 1989 Date: Thu, 7 Dec 89 18:53:40 -0500 To: NeWS-makers@brillig.umd.edu Subject: NeWS (any flavor) on a DECstation? From: mwm@violet.Berkeley.EDU (Mike (With friends like these, who needs hallucinations) Meyer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anyone have NeWS running on a DECstation (aka PMAX)? If so, I'd like to know about it. paul@ppgbms (Paul Evan Matz) writes: > Was wondering if anyone out there has had a problem with application > light weight processes being hung at exit time if "bindkey" was used to > bind a piece of NeWS code to a particular key? ... > Looking at the UI.ps code, it appears that the lwp, created to be interested > in the key, is created with a different lwp group: > > /bound_keys_proc { > newprocessgroup > createevent dup begin > /Name bound_keys def > /Action /DownTransition def > /Exclusivity true def > /Priority 3 def > end expressinterest > { awaitevent } loop > } fork def Of course it is impossible to tell what is going on without looking at your code. Nevertheless, here's a guess: The first time you bind a key, the proc you quote above gets started. Unfortunately, when it runs with a copy of the invoker's user dictionary and stack contents. If there is anything in your stack or userdict that you need garbage-collected at termination, you will be out of luck. The "newprocessgroup" is bindkey's protection against your termination. Unfortunately, you have no protection against bindkey's non-termination. If this is your problem, try this: /safebindkey { % key [proc|str] => -- { % fork countdictstack 1 sub { end } repeat % clear dict stack count 2 roll count 2 sub { pop } repeat % clear oper stack bindkey null } fork waitprocess pop } def Ideally, bindkey would have done this internally, saving you the trouble. Stan Switzer sjs@bellcore.com From don Thu Dec 7 18:56:38 1989 Date: Thu, 7 Dec 89 18:56:38 -0500 To: NeWS-makers@brillig.umd.edu Subject: Where can I get card stock? From: philmtl!philabs!ppgbms!pablo@uunet.uu.net (Pablo Gonzalez) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I recently got Don Hopkins PSIBER Space Deck. It includes a file that can generate a NeWS 2.0 Reference Card (doc.ps) on a laser printer by loading it into "card stock" before printing. Where can I get card stock? ============================================================================ Pablo Gonzalez | One Campus Drive | path ppgbms!moe!pablo@philabs.philips.com Pleasantville, N.Y. 10570 | (914) 741-4626 | ============================================================================ From don Thu Dec 7 18:56:59 1989 Date: Thu, 7 Dec 89 18:56:59 -0500 To: NeWS-makers@brillig.umd.edu Subject: cgsix segment driver with Sun xnews From: David Lau-Kee Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anyone know what the cgsix segment driver kernel patches supplied with Sun X11/NeWS FCS do? I can find no reference to this in the docs, and I can see no difference in either performance or well-behaviour from my pre- and post- patch versions. (I was hoping for a 5-fold speed increase on the NeWS side, but I guess they're saving it for 2.1.) -- David ------------- David Lau-Kee Canon Research Centre Europe, 19/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, ARPA: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360 From don Thu Dec 7 18:59:42 1989 Date: Thu, 7 Dec 89 18:59:42 -0500 To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS Availability From: rogern@Sun.COM (Roger Nolan) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Rick, The status of OpenWindows (and the X11/NeWS merge) was until recently "on hold." The production problems that we had been facing have been solved and the full OpenWindows product is now shipping. You may experience some delays because we now have a large backlog of orders for this product, but it is shipping. Most developers who have OpenWindows at this point are working with beta copies of the software. That is probably what you are seeing at the company you consult with. You should order OpenWindows through your local sales rep. Full media and documentation costs $295. The RTU is free with every Sun system sold. The OpenWindows announcement included the following; o Merged X11/NeWS window server (included new scalable font technology) o XView toolkit. This has a similar API to SunView and implements an OPEN LOOK look&feel on X Windows. o the NeWS "experimental" toolkit. This is not an officially announced or supported product. The experimental toolkit is there for developers to try and comment on. o OpenWindows Deskset. This included OPEN LOOK implementations of desktop applications such as: a graphical file manager, text editor, mail tool, clock, performance meter, snapshot tool, icon editor, binder and wastebasket. At the same time we announced OpenWindows, we also announced OpenWindows Developers Guide. This is a graphical and interractive user interface builder. It will allow a developer to lay out an XView OPEN LOOK user interface by dragging and dropping user interface objects. OpenWindows Developers Guide is expected to ship in March and has been priced at $250. Please feel free to contact us if you have any other questions. Roger Nolan Product Marketing Manager Sun Microsystems ----- Begin Included Message ----- >From NeWS-makers-request@cs.UMD.EDU Mon Nov 20 12:42:13 1989 Subject: getting NeWS/X11 for universities Ok, we've been had. According to our local sales rep news/x11 merge is "on hold", but clearly other people in this newsgroup seem to have it. What is the trick? I have access to the stuff through a local company I consult with, but would like to arrange access for the university. Who do I call and what will it cost? What other goodies are available, eg OpenLook, interface builders, etc? Rick Spanbauer State U of NY/Stony Brook ----- End Included Message ----- From don Thu Dec 7 19:10:33 1989 Date: Thu, 7 Dec 89 19:10:33 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: X11/NeWS Availability From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) You should order OpenWindows through your local sales rep. We tried, and our sales rep told us we couldn't get it yet. We could come by the sales office and try it out, but that's all right now. We could order it, but it couldn't be shipped yet. He said they don't have enough support personnel to have more than a certain number of copies sold, and I guess his quota had been exceeded. Nobody at MIT has the product yet, and I guess nobody will for a while ... From don Mon Dec 11 10:15:48 1989 Date: Mon, 11 Dec 89 10:15:48 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: X11/NeWS Availability From: Isaac Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >You should order OpenWindows through your local sales rep. >We tried, and our sales rep told us we couldn't get it yet. We could come by >the sales office and try it out, but that's all right now. We could order it, >but it couldn't be shipped yet. He said they don't have enough support >personnel to have more than a certain number of copies sold, and I guess his >quota had been exceeded. Nobody at MIT has the product yet, and I guess nobody >will for a while ... you're sales rep has no clue! i've been running OpenWindows 1.0 for about 2 months now (sparc version). talk to one of the SE's, you may have better luck. that's basically the route i took. i borrowed the tape from sun and copied it. the right to use liscense is part of sunos (i.e., it's free), so there's no reason that you shouldn't be able to copy it from someone. but don't quote me on that! :-) but hey, it exists, and it's good stuff!! -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * Internet : salzman@rand.org / | | * UUCP : !uunet!rand.org!salzman | | | From don Mon Dec 11 10:16:02 1989 Date: Mon, 11 Dec 89 10:16:02 -0500 To: NeWS-makers@brillig.umd.edu Subject: NeWS on a CG8-9 From: David Lau-Kee Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Sun X11/NeWS doesn't run on a CG8 or CG9 24-bit framebuffer. (Not that the X side could do much with 24-bits anyway!) Does anyone know of a version of NeWS which will support this hardware? Apparently Sun "currently have no plans" to support CG8-9 in XNeWS... is anyone else considering a port? ------------- David Lau-Kee Canon Research Centre Europe, 19/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, ARPA: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360 From don Mon Dec 11 10:16:21 1989 Date: Mon, 11 Dec 89 10:16:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS font addition problem From: Robin Faichney Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I have a problem in adding a font to xnews. It is an X11 .bdf format, converted to X11/NeWS .fb using convertfont. I then ran bldfamily, which produced a .ff file, but complained about an unknown encoding. Seems that a map file is needed in such cases, which I obviously do not have. I put the .ff and .fb files in the font directory anyway, just in case, but xlsfonts doesn't recognise them and the prog concerned fails to load them. Can anyone suggest a way round this? I suppose it might be relevant that the prog is xtrek, the font xtrek, the machine a SPARCstation 1 and the OS 4.0.3c. Robin Faichney, Canon Research Centre Europe, NRS: rjf@uk.co.canon 19/21 Frederick Sanger Road, ARPA: rjf@canon.co.uk Surrey Research Park, Guildford. GU2 5YD UUCP: rjf@canon.uucp Tel (+44)||(0) 483 574325 Fax (+44)||(0) 483 574360 From don Mon Dec 11 10:16:28 1989 Date: Mon, 11 Dec 89 10:16:28 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Where can I get card stock? From: lorelei!lemay@sun.com (Laura Lemay) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <22108@ppgbms.UUCP> pablo@ppgbms (Pablo Gonzalez) writes: > Where can I get card stock? Well, as a co-worker here at sun suggested: ----------------------------Bob------------------------------------- >Where can I get card stock? Take a large apple box and cut it into manageable pieces. Fill a 12 quart stock pot with water Add apple box pieces, a quartered onion, two whole carrots and some celery Boil for 2 hours. Strain card stock can be frozen or poured into your laser writer while still hot. Bob stockanswersareaspecialty -------------------------end of Bob---------------------------------- :-) -Laura Lemay lemay@eng.sun.com Redhead. Drummer. Geek. From don Mon Dec 11 10:17:36 1989 Date: Mon, 11 Dec 89 10:17:36 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: X11/NeWS Availability From: cs.utexas.edu!jarvis.csri.toronto.edu!csri.toronto.edu!moraes@tut.cis.ohio-state.edu (Mark Moraes) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) rogern@SUN.COM (Roger Nolan) writes: >The status of OpenWindows (and the X11/NeWS merge) was until recently >"on hold." How recently did it stop being "on hold"? One site at UofT has an OpenWindows FCS tape for the Sun3. (it arrived last week when someone from Sun gave us a talk on X11/NeWS) At the talk, they said that it was a developers release: one had to send them a letter stating reasons for ordering X11/NeWS (we're kinky, ok? we like to buy window systems so we can use up more disk space...) and that had to be approved by "higher-ups". A small quota was also mentioned, "for support reasons". None of this is mentioned in the glossies... About this RTU: Is it legal if we make copies of X11/NeWS for all Suns on campus from the one site that has the tape? (Well, make that all Suns that want it -- that server is *BIG*) For all Suns not on campus -- say at neighbouring Universities etc? If so, maybe Sun could allow someone to stuff the thing on the SEXtape or SUGtape? Or a set of binaries for anonymous ftp? Think of the netnews volume in "Has anyone seen X11/NeWS" requests this would save? Much of the documentation consists of books that one can get from a local bookstore -- the books on X been in our lab for several months now, and the red/blue PostScript books for several years... Oh well -- we'll just wait for X.V11R4 release, promised "this yearish". All I want is a fast Sun colour X server; I suspect I'm not alone in that desire. (monochrome X11 has been running on our Sun3/[56]0s for well over a year and a half as the de facto standard windowing system -- our users seem to like it) From don Mon Dec 11 10:31:44 1989 Date: Mon, 11 Dec 89 10:31:44 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Not that the X side could do much with 24-bits anyway! What kind of garbage is this? The X protocol supports up to 32 bits per pixel. There are several vendors shipping X on deep framebuffers. From don Mon Dec 11 20:32:51 1989 Date: Mon, 11 Dec 89 20:32:51 -0500 To: NeWS-makers@brillig.umd.edu From: hoptoad!hugh (Hugh Daniel) Subject: A tidbit, how to do a rsh from NeWS Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Here is a piece of NeWS postscript code that I use for starting unix processes. This sets the NEWSSERVER and the DISPLAY varaibles that NeWS and X programs look at to find the display you are sitting at. This is usefull in that any command (NeWS or X) typed in the terminal will be able to find the disyplay you are at. ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 1996 Hayes St. San Francisco CA94117 % I use this for all commands going to unix. The /dev/null stuff % at the end of the csh line frees up both ends of the rsh, thus % freeing two processes. % Some SystemV's dont set the HOST variable, so we trash it so that % your (possibly superuser) X windows dont come up on on the target % machine. % To do I/O redirection use a subshell () % Beware, your command is interped by the local shell first... % I need a better sh/ksh line. % Replaceing rsh with something better is a great need. % Example: (/usr/NeWS/bin/gterm)(localhost) rshcommand /rshcommand { % command'string host'string => - (HOST)(*nO=bLuDy+host|thanks!att$$) ?getenv (%:0) sprintf exch (NEWSSERVER) getenv exch % csh users... (/usr/ucb/rsh -n % 'setenv NEWSSERVER "%"; setenv DISPLAY %; exec' % '>\& /dev/null < /dev/null') % sh users... This leaves a in.rsh arround. %(/usr/ucb/rsh -n % 'NEWSSERVER="%" DISPLAY=%' exec % ) sprintf forkunix } def /termwindowto { % host'string -> (/usr/NeWS/bin/gterm -bg -ls -t psterm-fast) exch rshcommand } def From don Mon Dec 11 21:31:31 1989 Date: Mon, 11 Dec 89 21:31:31 -0500 To: NeWS-makers@brillig.umd.edu Subject: BIG OOPS!!!! [Re: X11/NeWS Availability] From: Isaac Salzman Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >you're sales rep has no clue! i've been running OpenWindows 1.0 for about >2 months now (sparc version). talk to one of the SE's, you may have >better luck. that's basically the route i took. i borrowed the tape from >sun and copied it. the right to use liscense is part of sunos (i.e., it's >free), so there's no reason that you shouldn't be able to copy it from >someone. but don't quote me on that! :-) but hey, it exists, and it's good >stuff!! big time apology here. i was wrong - we are not running OpenWindows 1.0, we are still running pre-FCS. we signed up for a pre-release "special", which is the only reason we have OpenWindows. i was under the false impression that the post-beta2 version i received was the release version, but i'm wrong. so don't go calling your SE's bugging them about a tape. from the SUG conference I found out that OpenWindows is not what they call an "FCS" product, but a "developers release". i don't know what that means. you'll have to talk to your sales rep to find out the details. sorry for the confusion. i hope i didn't cause anyone too much heartache. even if i'm not running 1.0, it's still good stuff!! -isaac (salzman@rand.org) From don Sat Dec 16 08:22:09 1989 Date: Sat, 16 Dec 89 08:22:09 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: cgsix segment driver with Sun xnews From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Does anyone know what the cgsix segment driver kernel patches supplied with Sun X11/NeWS FCS do? I would like to know too! Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| From don Sat Dec 16 08:22:25 1989 Date: Sat, 16 Dec 89 08:22:25 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is it possible that the NeWS side of XNeWS could would run in 24bits pretty much as-is, whereas the X side would require a little bit more work, or is it the case that the port would be as difficult for both sides (or is there effectively only one thing to port)? I don't really know how X11/NeWS is implemented internally. I thought both halves were built on top of a common graphic library, in which the X side wouldn't take much additional work. From don Sat Dec 16 08:22:33 1989 Date: Sat, 16 Dec 89 08:22:33 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: laukee%canon.uucp@NSFnet-Relay.AC.UK Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > > >> Not that the X side could do much with 24-bits anyway! > >What kind of garbage is this? The X protocol supports up to 32 bits per >pixel. There are several vendors shipping X on deep framebuffers. > Woah, sore spot there? Let me be precise: for "X side" substitute "X side of merged server as implemented in Sun OpenWindows 1.0" I'm talking about XNeWS here. Are Sun shipping XNeWS for deep framebuffers?? I think not, (but maybe that's garbage too :^]). Is it possible that the NeWS side of XNeWS could would run in 24bits pretty much as-is, whereas the X side would require a little bit more work, or is it the case that the port would be as difficult for both sides (or is there effectively only one thing to port)? Information from a contact at Sun indicated that the NeWS side would be easy compared with the X side. Maybe you know different! -- David Lau-Kee From don Sat Dec 16 08:22:39 1989 Date: Sat, 16 Dec 89 08:22:39 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS (any flavor) on a DECstation? From: steve@umiacs.UMD.EDU Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've got a NeWS 1.1 port that mostly works on a DECstation. The mono code is right except for an off-by-one in the line code and a shift-one-to-the-left on the mouse. The color code still needs a lot more work. If you want it, and are willing to live with the bugs, and can show me a NeWS 1.1 educational license, it's yours. Other bugs may exist; I don't use NeWS myself, so I haven't banged hard on the code. -Steve Spoken: Steve Miller Domain: steve@umiacs.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742 From don Sat Dec 16 11:21:26 1989 Date: Sat, 16 Dec 89 11:21:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: hoptoad!gnu (John Gilmore) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <5fLz02oD72dj01@amdahl.uts.amdahl.com> aksegu@uts.amdahl.com (Ashok Kumar A. Segu) writes: > I was going thru the SPARCserver family specifications (technical > brochure) ans saw that the WINDOW SYSTEM that SUN supports is > OpenWindows. This was also reiterated by Mr. Scott McNealy and Mr. Eric > Schmidt at the introduction of SPACRCserver 1 and 490 on Dec.6th. > > Guess what folks, the SYSTEM SOFTWARE does not include OpenWindows, > but includes SunView. rogern@sun.com (Roger Nolan, Product Marketing Manager--Windows) wrote: > This sounds like a misunderstanding. The OpenWindows Developers Release > 1.0 is supported and shipping on SPARC systems. No, this sounds like deliberate evasion. All the Sun press releases and speeches and brochures and stuff talk about Open Windows as if it was real, but Sun still ships the old SunView stuff and doesn't ship Open Windows *with the system*. Calling it a "Developers Release, SPARC Only" would be fine -- just stop telling the press and the customers that Sun is 100% behind Open Windows, leaving them with an ugly surprise when the system arrives. Also, I thought the Intel and Motorola ports would be out in October: > From: rprobst@SUN.COM (Richard Probst) > Newsgroups: comp.windows.x > Subject: Sun ships OpenWindows > Message-ID: <8909270029.AA26500@paba.sun.com> > Date: 27 Sep 89 00:29:27 GMT > > Sun is now shipping OpenWindows 1.0 on SPARC machines. Sun-3 and Sun386i > versions will start shipping in 30 days. > > OWN-1.0-4-4-5 SPARC -- Doc and Media $ 295 ND ** 9/25/89 > OWN-1.0-4-3-5 Sun-3 -- Doc and Media 295 ND ** 10/25/89 > OWN-1.0-4-R-5 386i -- Doc and Media 295 ND ** 10/25/89 (Note the dates in the last column.) > This means that you can buy one copy of the media and > documentation and run it on as many Sun workstations as you like. Oh, really? Can I upload it to uunet and let anybody FTP it or uucp it from there? Can I put it on the Sun User Group tape? Can I send it to the guy in Europe who is getting a runaround from his sales office but keeps seeing postings from other people who have it? If so, why didn't Sun just do all this stuff? Or simply put it on the next &%^$ Unix release! > At the current time, OpenWindows is a Developers Release. We are not > recommending it to the general end user community at this time. As a > result, SunView is still bundled with all of our systems and is the > default window system for Sun workstations. And with this policy, it sure will stay that way. Imagine you are a software developer. Let's say you port your first Sun product to Open Windows. The customers start to buy it. You ship them copies. Then: "What do you mean I can't run it? I have to buy Open Windows from Sun? You've ordered things from Sun before, it will take weeks just to get my sales rep to return a call, since I only bought three workstations. Howabout I just send back your software?" Will OpenWindows be bundled in SunOS 4.1, or will we have the same story for another whole year? -- John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com Just say *yes* to drugs. Use your *no*s for government bullshit. From don Sat Dec 16 11:34:26 1989 Date: Sat, 16 Dec 89 11:34:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: BIG OOPS!!!! [Re: X11/NeWS Availability] From: crdgw1!montnaro@uunet.uu.net (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8912112136.AA23707@iris.rand.org> salzman%iris@RAND.ORG (Isaac Salzman) writes: so don't go calling your SE's bugging them about a tape. I disagree. Check with your local SE. Our office has OpenWindows now. Yours should be able to get it. -- Skip (montanaro@crdgw1.ge.com) From don Sat Dec 16 11:34:42 1989 Date: Sat, 16 Dec 89 11:34:42 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: hoptoad!hugh@uunet.uu.net (Hugh Daniel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) How many folks are in need of XNeWS running on CG8's and CG9's? ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 210 Clayton ST San Francisco CA94117 From don Sat Dec 16 11:34:55 1989 Date: Sat, 16 Dec 89 11:34:55 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: X11/NeWS Availability From: laukee%canon.uucp@NSFnet-Relay.AC.UK Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >>sun and copied it. the right to use liscense is part of sunos (i.e., it's >>free), so there's no reason that you shouldn't be able to copy it from Maybe this will be the case when OpenWindows starts shipping as a part of SunOS... the licence we got with our FCS/developer's release/whatever explicitly says that we can run it on the "Designated Equipment" which "means an equipment configuration comprising a single Sun central processing unit and associated equipment". Then again, if it is meant as a developer's release are we really expected to have a team of people all "developing" on the same cpu? I guess they just want to cover their backs (fair enough), maybe they wouldn't worry too much about inter-group "backups" and "testing" on other cpus... but perhaps a SUG tape might be stretching it a bit! Also, a contact at Solbourne indicates that they haven't (and won't) be licensing the merge, so no running it on their cpus! Anyone from Sun care to comment? >>someone. but don't quote me on that! :-) but hey, it exists, and it's good >>stuff!! Yes it does exist, there are a few bugs, some nasty, some just silly, but it's basically sound, and the documentation is streets ahead of previous Sun stuff. The NeWS side can be a little pedestrian, but the X side fairly flies (even in colour). As for accessibility, what you do is put in a big order, say a couple of 4/390s and a dozen or so 4/60s, make the order dependent upon receipt of the merge, and presto! -- David -------- Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, ARPA: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360 From don Sat Dec 16 11:36:27 1989 Date: Sat, 16 Dec 89 11:36:27 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: cgsix segment driver with Sun xnews From: laukee%canon.uucp@NSFnet-Relay.AC.UK Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >>Does anyone know what the cgsix segment driver kernel patches supplied >>with Sun X11/NeWS FCS do? Several people have asked me to let them know about replies. I only had one which contained information, and it says that the segment driver allows the context of the cg6 to be preserved so that multiple applications can use it, e.g. XNeWS and maybe SunCore. Opinion seems to confirm that the patches don't affect performance. -------- Canon Research Centre Europe, 17/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, ARPA: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcsun!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360 From don Sat Dec 16 11:37:23 1989 Date: Sat, 16 Dec 89 11:37:23 -0500 To: NeWS-makers@brillig.umd.edu Subject: IETF Activities From: Craig Partridge Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi folks: This note is being sent around to let you know that the Internet Engineering Task Force plans to start work within the next week on developing Internet standards for network graphics and distributed file systems. People interested in participating in or monitoring these activities should join the IETF mailing list (ietf-request@isi.edu). I should hasten to emphasize that we currently *expect* that this process will be a matter of reviewing the various current candidate protocols and recommending which ones are suitable for Internet-wide use. (Of course if none of the protocols are deemed suitable, then development work may be required.) Craig Partridge IETF Area Director, Host-Based and User Services PS: For those of you not familiar with the IETF: The IETF is charged with near-term engineering of the Internet. This activity includes advising the Internet Activities Board of protocols that might be suitable for standardization in the TCP-IP protocol suite. From don Sat Dec 16 11:37:43 1989 Date: Sat, 16 Dec 89 11:37:43 -0500 To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS font addition problem From: Dave Lemke Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > From uunet!tut.cis.ohio-state.edu!ucbvax!canon.UUCP!rjf Tue Dec 12 09:57:06 PST 1989 > > > I have a problem in adding a font to xnews. It is an X11 .bdf format, converted > to X11/NeWS .fb using convertfont. I then ran bldfamily, which produced a .ff > file, but complained about an unknown encoding. Seems that a map file is needed > in such cases, which I obviously do not have. I put the .ff and .fb files in > the font directory anyway, just in case, but xlsfonts doesn't recognise them and > the prog concerned fails to load them. Can anyone suggest a way round this? > > I suppose it might be relevant that the prog is xtrek, the font xtrek, the > machine a SPARCstation 1 and the OS 4.0.3c. > > Robin Faichney, Canon Research Centre Europe, NRS: rjf@uk.co.canon > 19/21 Frederick Sanger Road, ARPA: rjf@canon.co.uk > Surrey Research Park, Guildford. GU2 5YD UUCP: rjf@canon.uucp > Tel (+44)||(0) 483 574325 Fax (+44)||(0) 483 574360 > ignore the warning -- its just convertfont being overly noisy. it sounds like the step your missing is that bldfamily does more than make the .ff -- it also updates the master list for the font directory (Families.list), so you need probably want to run bldfamily again in your font directory. Dave Lemke ARPA: lemke@ncd.com Network Computing Devices, Inc. UUCP: uunet!ncd!lemke From don Sat Dec 16 11:37:55 1989 Date: Sat, 16 Dec 89 11:37:55 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Re: X11/NeWS Availability From: shemesh!ittai@nyu.edu (Ittai Hershman) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) OpenWindows 1.0 is shipping. Delays are due to concern about support; they are quite sensibly staggering shipments based on the support they are able to give. They also seem to be working with the local SE's to prioritize shipment to customers who are known quantities support-wise. There seems to be a lot of mis-information, so I typed in the following from the "READ THIS FIRST" document: Even though OpenWindows 1.0 is very stable, this release is positioned as a developer's release to send the message that OpenWindows is not yet suitable as a SunView replacement for all current Sun customers. Some users, particularly those with large-memory machines (more than 8Mb), may be happy with OpenWindows 1.0 performance. Other users, such as those with eight megabytes of memory, may not be happy with OpenWindows 1.0 if they expect the same level of responsiveness as they are now used to with SunView. OpenWindows 1.0 is not recommended at all for configurations with less than 8mb. Existing performance problems in limited memory machines are well understood and will be addressed in an upcoming release. There is no further discussion of performance later in this document. The OpenWindows Developer's Release can be ordered for all three architectures. We recommend SPARC platforms for the performance required by a network-based window system. -Ittai From don Sun Dec 17 21:04:29 1989 Date: Sun, 17 Dec 89 21:04:29 -0500 To: NeWS-makers@brillig.umd.edu Subject: CHI '90 tutorials From: bnrgate!bnr-fos!bmers58!bmers11.uucp!armstron@uunet.uu.net (Steve Armstrong) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) CHI '90 (the seventh annual Conference on Human Factors and Computing Systems) will be held in Seattle, Washington, from April 1st to 5th, 1990. The theme of CHI '90 is Empowering People: facilitating their work and communications, improving their effectiveness and productivity. The conference will have technical papers, panel sessions, tutorials, interactive posters, interactive performances, workshops, videos, laboratory reviews, formal and hands-on demonstrations, and exhibits. A key feature of the annual CHI conference is the tutorials program, which has been expanded for the 1990 conference in response to requests from applications developers. "The CHI '90 tutorials program boasts a new set of tutorials designed specifically for developers working on direct manipulation and the new windowing systems," says Dr. Wendy Kellogg, Tutorials Program Chair for CHI '90. "Successful application of these technologies requires an understanding of human factors issues underlying user interactions." A brief description of each tutorial is included below. To receive an advance program, which provides full details on each tutorial and conference registration, please contact the conference executive administrator, Toni MacHaffie, by: EMAIL: machaffie.chi@xerox.com MAIL: CHI '90, P.O. Box 5847, Beaverton, OR 97006-5847 PHONE: (503) 591-1981 FAX: (503) 642-3934 Advance programs will be mailed on January 1st, 1990 CHI'90 TUTORIALS PROGRAM ----------------------------------------------------------------------- Tutorial #1 (Full day, Sunday, April 1, 1990) User-Computer Interface Design John L. Sibert and James D. Foley The George Washington University This course presents a top-down design methodology for user-computer interfaces, including requirements definition, conceptual design, functional design, and dialogue design. The emphasis is on graphically- oriented dialogue styles: matters such as screen layout, use of icons, and graphical interaction devices, techniques, and feedback are discussed. ------------------------------------------------------------------------ Tutorial #2 (Full day, Sunday, April 1, 1990) Advanced Methods for User Interface Design: Applications, Tools, and Survival Techniques Tyler Blake Intuitive Software and Interactive Systems, Inc. and California State University, Northridge This course investigates state-of-the-art techniques for producing quality user interface designs in each of three major areas: conceptual design, technical implmentation and organization support. A series of methodologies for increasing the precision, productivity, creativity, and practicality of the user interface design process is examined. ---------------------------------------------------------------------- Tutorial #3 (Full day, Sunday, April 1, 1990) Graphical Invention for User Interfaces Bill Verplank ID TWO Product Design Consultants Introduces new strategies for graphical invention with principles, processes, examples and short exercises. Topics addressed include visual brainstorming, idea sketching, conceptual models and mental maps (imageability), graphic facilitation, and uses of metaphor in interface design. ------------------------------------------------------------------------ Tutorial #4 (Full day, Sunday, April 1, 1990) The Use of Non-Speech Audio at the Interface Bill Buxton, University of Toronto Bill Gaver, Rank Xerox Cambridge EuroPARC Sara Bly, Xerox PARC Human-computer interaction can be significantly enhanced through better use of the audio channel. The focus of this course is on an especially neglected aspect of sound: the use of non-speech audio to communicate information from the computer to the user. The course will provide the historical, theoretical, and practical background that will enable participants to "tool up" to undertake such work. ------------------------------------------------------------------------- Tutorial #5 (Full day, Sunday, April 1, 1990) Concepts of Object Oriented Programming Dave N. Smith, IBM Watson Research Center This course introduces object-oriented programming to those familiar with procedural languages, starting with the simplest possible objects and adding concepts one by one, illustrating each step with examples from one object-oriented language (Smalltalk). Content covers what an object is, sending messages to objects, methods, introduction to Smalltalk, kinds of message sends, classes, instances, class methods, hierarchy of classes, self and super, and abstract classes. ------------------------------------------------------------------------- Tutorial #6 (Full day, Sunday, April 1, 1990) Direct Manipulation Design Studio Eliot Tarlin, Digital Equipment Corporation The most complex design problem within a direct manipulation style interface is consistently the dialog box. This course provides an in-depth review of a case study of converting a command line interface to a direct manipulation interface, and engages students in collaborative design exercises and a studio critique to reveal and address issues and tradeoffs confronted within dialog box design. ----------------------------------------------------------------------- Tutorial #7 (Full day, Sunday, April 1, 1990) How to Run Computer-Supported Meetings John Whiteside, Digital Equipment Corporation This course is a training program in running computer-facilitated meetings. Its focus is on providing attendees with concrete skills, information, and tools that can immediately be used in implementing and conducting computer-enhanced meetings in their organizations and groups. ------------------------------------------------------------------------- Tutorial #8 (Full day, Sunday, April 1, 1990) Designing Phone-Based Interfaces Richard Halstead-Nussloch, IBM Corporation Michael DiAngelo, IBM Corporation James Kondziela, NYNEX, Inc. Phones are potentially convenient workstations to a wide range of computer services, but turning this potential into a reality represents a challenging opportunity for user interface designers. This course will cover PBI technology, identify opportunities for applying PBIs, choosing appropriate PBI dialogue flow, and elements of PBI design. In a design studio portion of the course, participants will design and critique a PBI. ------------------------------------------------------------------------ Tutorial #9 (Half day, Sunday Morning, April 1, 1990) Introduction to Hypertext and Hypermedia Jakob Nielsen, Technical University of Denmark This introductory course defines and surveys existing hypertext and hypermedia systems. User interface issues, problems in navigating large information spaces, and empirical tests of the usability of hypermedia systems and documents are discussed. ------------------------------------------------------------------------- Tutorial #10 (Half day, Sunday Morning, April 1, 1990) Designing Minimalist instruction for practical computer skill John M. Carroll and Mary Beth Rosson IBM Watson Research Center Designers of instruction for practical skills must address the paradox of sensemaking: people need to make sense of a situation in order to learn from it, but at the same time need to learn about new situations before they can make sense of them. This course describes the Minimalist instructional model, developed to address the paradox of sensemaking and the failures of traditional approaches to user training. Design objectives for writing Minimalist instruction and a review of several examples will be given. ------------------------------------------------------------------------ Tutorial #11 (Half day, Sunday Morning, April 1, 1990) Applications Programming with the X Toolkit Douglas Young, Hewlett-Packard Laboratories This course introduces the X toolkit, a standard high-level toolkit for writing applications with the X windows system. Content includes the architecture of the Xt intrinsics, how to structure and write X-based applications, and examples of creating user interfaces with user interface components known as widgets. ------------------------------------------------------------------------- Tutorial #12 (Half day, Sunday Morning, April 1, 1990) Questionnaire Design Studio Marilyn Mantei, University of Toronto Questionnaires do not automatically obtain the data its distributors expect to get. This course details how to develop valid and reliable questionnaires for user evaluation studies, user acceptance studies, and assessments of work practices and user attitudes. Content includes avoiding common biases built into questions, judging the trustworthiness of data from other questionnaires, and practice generating questions. ---------------------------------------------------------------------- Tutorial #13 (Half day, Sunday Morning, April 1, 1990) Copyright Protection for Software and User Interfaces Pamela Samuelson, Emory University Intellectual property issues have become important for software developers with the increase in decided and pending cases. In this tutorial, copyright issues affecting user interface design and other aspects of software will be addressed. Content includes reviews of copyright law, its specific application to software, decided cases, and issues and arguments of pending cases. --------------------------------------------------------------------- Tutorial #14 (Half day, Sunday Afternoon, April 1, 1990) Patent and Unfair Competition Protection for Software and User Interfaces Pamela Samuelson, Emory University This tutorial focuses on patent law developments affecting user interface design and software in general, and introduces concepts of unfair competition law as it might affect software developers. Content includes an overview of the patent system, a review of recent software user interface patents, discussions of the patentability of software innovations, design patent law, and the law of unfair competition, trademark, and trade dress protection. -------------------------------------------------------------------- Tutorial #15 (Half day, Sunday Afternoon, April 1, 1990) Software Design as Commuication Design Paul Heckel, QuickView Systems Heckel presents a unique perspective of software design as a communications craft. The course details the implications of viewing software as a communication medium like writing, film, or theatre, emphasizing ways of thinking and communication techniques that transcend specific media. Over thirty communication techniques are described, each with examples in software. -------------------------------------------------------------------- Tutorial #16 (Half day, Sunday Afternoon, April 1, 1990 OSF/Motif: Features and Functionality Ellis Cohen, Open Software Foundation This course describes OSF/Motif, including the Motif toolkit, user interface language, window manager, and style guide. A knowledge of X11 and the Xt intrinsics is helpful, but not necessary or required. ------------------------------------------------------------------------- Tutorial #17 (Half day, Sunday Afternoon, April 1, 1990) Desktop Computer Animation Patricia Harrison and Daniel Sadowski Harrison Sadowski and Associates Creating rich, animated visuals is no longer limited to those with access to high-end workstations. This course explains animation techniques and surveys currently available desktop animation products. Extensive examples are shown, and the complete process of developing an animation sequence will be demonstrated. ------------------------------------------------------------------------- Tutorial #18 (Half day, Sunday Afternoon, April 1, 1990) Turning Text into Hypertext Robert J. Glushko, Search Technology, Inc. An intermediate course which introduces methods for analyzing and converting existing documents into hypertext documents. User interface and implementation implications of hypertext components are reviewed and a case study illustrating design issues is discussed. Participants will analyze several real documents for their "hypertextability" in order to recognize what makes documents easy or challenging candidates for hypertext. ------------------------------------------------------------------------- Tutorial #19 (Full day, Monday, April 2, 1990) Managing the Design of the User Interface: A Practical Course for Software Managers and Developers Deborah J. Mayhew, Deborah J. Mayhew and Associates Organized around a traditional project life cycle, this course presents practical methods and techniques for managing the design of high-quality user interfaces through the application of human factors. Methods and techniques presented include interface design and evaluation techniques as well as organizational and managerial strategies. --------------------------------------------------------------------- Tutorial #20 (Full day, Monday, April 2, 1990) Graphical Human-computer Interface Design for Window Management Systems Aaron Marcus, Aaron Marcus and Associates This course introduces terminology, principles, guidelines, and heuristics for successfully using graphics in human-computer interfaces. Topics covered include the design of icons, control panels, dialog boxes, and navigational devices, that are not sufficiently prescribed by window management systems. The course addresses perceptual, cognitive, and communication issues. ----------------------------------------------------------------------- Tutorial #21 (Full day, Monday, April 2, 1990) Usability Engineering: Using Contextual Inquiry John Bennett, IBM Almaden Research Center Karen Holtzblatt, Digital Equipment Corporation Sandra Jones, Digital Equipment Corporation Dennis Wixon, Digital Equipment Corporation A practical introduction to the use of contextual inquiry as a step toward achieving computer system usability. The focus is on how to do contextual inquiry as a way to understand user requirements and to set user-related design objectives. ----------------------------------------------------------------------- Tutorial #22 (Full day, Monday, April 2, 1990) Issues in the Design and Application of Hypermedia Systems Frank G. Halasz, Xerox PARC Jeff Conklin, MCC An advanced tutorial for those intending to design or implement hypermedia systems. The course will review several existing hypermedia systems, focusing on critical issues for creating state-of-the-art systems. The application of hypermedia technology to the management of semi-structured information and outstanding research issues will be discussed. ------------------------------------------------------------------------- Tutorial #23 (Full day, Monday, April 2, 1990) Introduction to Visual Programming Environments Ephraim P. Glinert, Rensselaer Polytechnic Institute Marc H. Brown, DEC Systems Research Center Brad A. Myers, Carnegie Mellon University Visual programming refers to the use of graphics to define or help define programs; program visualization is the use of graphics to make programs and their executions understandable. This course defines and classifies visual environments, surveys visual representations for programs and visual programming systems, and outlines the concepts underlying the design and implementation of visual systems. Successes of the visual approach, unresolved issues, and future applications are discussed. ------------------------------------------------------------------------- Tutorial #24 (Full day, Monday, April 2, 1990) New Interaction Media Robert J.K. Jacob, Naval Research Laboratory Walter Bender, MIT Media Laboratory Jim Davis, MIT Media Laboratory Scott S. Fisher, NASA Ames Research Center This course describes some techniques for human-computer interaction that will become available in the near future, specifically, speech, new display technology, stereoscopic graphics, spatial input, and eye-tracking. For each, the underlying theories of operation of the devices will be explored, and examples of current research and "products" detailed. The course will discuss the merits, limitations, and range of suitable applications for these media, and offer practical advice toward using these technologies at the interface. ------------------------------------------------------------------------- Tutorial #25 (Full day, Monday, April 2, 1990) Designing User Interfaces for Children Allison Druin, Tell Tale Technologies Kate Withey, Willow Design Creating innovative and successful user interfaces for children holds special challenges, but understanding and meeting these challenges is relevant to all user interface design. The first part of this course describes existing and emerging interfaces for children, and prototyping techniques for such interfaces. In the second part, schoolchildren will join participants in design teams to prototype and critique an interface. ------------------------------------------------------------------------ Tutorial #26 (Half day, Monday Morning, April 2, 1990) The Pragmatics of Haptic Input Bill Buxton, University of Toronto This course examines some of the bases upon which the designer can make appropriate decisions in matching input technologies and techniques to applications and users. Input devices are discussed in terms of properties that augment their ability to support certain transactions but inhibit their ability to support others. Content includes methods for making comparative evaluations, a taxonomy of input devices and tasks, and a discussion of how phrasing techniques can be used to support the attainment of skilled performance. ------------------------------------------------------------------------- Tutorial #27 (Half day, Monday Morning, April 2, 1990) Video Ultrasimulation: Creating the Experience of Skilled Performance David Hon, IXION Hon designs and builds computer-based training systems utilizing a range of novel forms of user input and video output, with the goal of creating a context where learners can experience the feel of skilled performance, which he calls "ultrasimulation." The course will differentiate and show examples of different types and uses of video simulation, and discuss interface design issues and aspects of the design process which are critical for the success of these highly interactive systems. ----------------------------------------------------------------------- Tutorial #28 (Half day, Monday Morning, April 2, 1990) The Development of Seductive Interfaces Timothy C. Skelly and David D. Thiel Incredible Technologies Designing interfaces that can draw users in and motivate them to further learning and use has long been a goal and challenge faced by video games designers. This course explores the properties and mechanisms of successful self-teaching interfaces drawing on examples of video and computer games, and discusses effective composition of interfaces combining graphics, sound, and user input. ------------------------------------------------------------------------ Tutorial #29 (Half day, Monday Morning, April 2, 1990) The OPEN LOOK Graphical User Interface: Design, Philosophy, and Use Lin Brown and Scott Ritchie Sun Microsystems This course will familiarize attendees with the OPEN LOOK graphical user interface, and the design concepts and philosopies on which it is based. Interactive demonstrations of several applications and techniques for designing applications user interfaces in the OPEN LOOK environment will be presented. ------------------------------------------------------------------------- Tutorial #30 (Half day, Monday Morning, April 2, 1990) A Practical Introduction to Experimental Design for CHI Research Richard Dillon and Jo Tombaugh Carleton University This course introduces the use of experimental and quasi-experimental designs in applied research. Participants will learn how to critically evaluate the appropriateness and usefulness of formal experiments reported in the literature, and how to design experiments that will have impact in HCI research. ------------------------------------------------------------------------- Tutorial #31 (Half day, Monday Morning, April 2, 1990) MacApp*TM*: An Object-Oriented User Interface Toolkit Kurt J. Schmucker, Apple Computer, Inc. User interface toolkits, constructed with the techniques of object-oriented programming, are one means of reducing the cost of producing applications with sophisticated, iconic user interfaces. This course presents a detailed examination of these toolkits, their structure, and their use, with all examples in MacApp in both Object Pascal and C++. Several small applications designed with MacApp will be demonstrated and decomposed to show their implementation. ------------------------------------------------------------------------- Tutorial #32 (Half day, Monday Afternoon, April 2, 1990) AI and Education Elliot Soloway, University of Michigan This course discusses four types of AI systems for improving teaching (the intelligent lab workbench, articulate expert, expert diagnostician, and intelligent tutor). Several large teaching systems will be described as case studies in how to design, build, and test an AI-based training system. ------------------------------------------------------------------------- Tutorial #33 (Half day, Monday Afternoon, April 2, 1990) Storyboards and Sketch Prototypes for Rapid Interface Visualization Gayle Curtis, Rehabilitation R&D Center Laurie Vertelney, Apple Computer, Inc. The inventive leap to effective new user interfaces often requires visualization of applications and user scenarios long before the final technology is available. This course describes how storyboards and sketch prototypes can be powerful tools for exploring alternative design ideas and having early feedback on their usability. --------------------------------------------------------------------- Tutorial #34 (Half day, Monday Afternoon, April 2, 1990) Computer Supported Cooperative Work and Groupware Jonathan Grudin, MCC/Aarhus University Steven E. Poltrock, Boeing Advanced Technology Center This course introduces attendees to the opportunities and challenges posed by computer supported cooperative work (CSCW) and groupware, providing the background needed to evaluate existing groupware and design more effective applications. The focus will be on functionality and user interface requirements rather than underlying architectural support issues. ------------------------------------------------------------------------- Tutorial #35 (Half day, Monday Afternoon, April 2, 1990) Interface Builder and Object-Oriented Design on the NeXT Computer Michael K. Mahoney, California State University, Long Beach This course provides an overview of the process of developing a NeXT application, showing how the NeXT Interface Builder enables graphical definition of user interfaces in an object-oriented language. User interfaces to several small applications will be built and tested, and other useful tools for application program development will be demonstrated. ------------------------------------------------------------------------- Tutorial #36 (Half day, Monday Afternoon, April 2, 1990) Human-Computer Interaction Standards: Developments and Prospects John Karat, IBM Watson Research Center International user interface standards may well be a reality within the next two years. This course will provide attendees with an understanding of standardization efforts by describing current standards committee activities and their potential impact on current systems. Ways in which attendees can participate in and influence current standardization efforts will be discussed. --------------------------------------------------------------------- Tutorial #37 (Half day, Monday Afternoon, April 2, 1990) The Psychology of Software Development Bill Curtis, MCC This course covers results of recent research on the psychological aspects of programming and their implications for software development technology and environments. Content includes cognitive models of programming knowledge that underlie individual differences in programming, and team and organizational issues in software development environments. ------------------------------------------------------------------------- From don Sun Dec 17 21:04:35 1989 Date: Sun, 17 Dec 89 21:04:35 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <9236@hoptoad.uucp>, gnu@hoptoad (John Gilmore) writes: >Will OpenWindows be bundled in SunOS 4.1, or will we have the same >story for another whole year? Well, from what I hear, the alpha/beta test time for SunOS is HUGE! By separating window stuff from SunOS, we might see new releases of SunView and OpenLook before we see SunOS 4.1. Sure enough, I just got the following message: ------------------------------------------------------------------------------- SUN INTRODUCES NEW EASY-TO-USE TOOLS FOR DESKSET SunFLASH Vol 12 #1 December 1989 ------------------------------------------------------------------------------- Free Right-To-Use License Included With All Sun Workstations MOUNTAIN VIEW, Calif. --December 5, 1989-- Sun Microsystems today introduced an enhanced release of the DeskSet(TM) environment, a suite of easy-to-use, window-based tools built around the OPEN LOOK(TM) graphical user interface. Four new tools bring the DeskSet 1.0 total to 12 making this the most extensive set of tools available on workstations today. Sun also announced that a free right-to-use license for DeskSet 1.0 is now included with all Sun workstations. These "essential" tools such as a file manager and mail tool make the UNIX(R) operating system simpler, replacing the keying in of commands with the point and click of a mouse. Additionally, the tools can be run in a 2-D or 3-D mode. DeskSet 1.0 will be of particular interest to independent software developers who use the SunView(TM) window system, since the new release enables them to add "drag and drop" functionality to their SunView applications. Until now, DeskSet has only been available for X-based applications. DeskSet was first released in April as a part of the OpenWindows(TM) application environment, built on the X11/NeWS(TM) window system. The new release includes four new tools: a calendar manager, print tool, tape tool and calculator, in addition to the original tools: file manager, mail tool, text editor, binder, icon editor, snapshot tool, performance meters and clock. All 12 tools utilize the "drag and drop" method of directly manipulating visual objects with a mouse, making work very fast and intuitive. The New Tools: Calendar manager simplifies appointment and resource scheduling, notifying the user of scheduled one-time or ongoing meetings, visually or via sound; Print tool enables users to simply "drag and drop" an icon with a mouse to print documents or mail messages; Tape tool provides an easy way to read, write or list data from a local or remote tape drive; Calculator is programmable for algebraic, scientific and logic mathematical functions. Availability The DeskSet 1.0 tool suite will be available during the first quarter of 1990. A right-to-use license is free with every Sun workstation shipped; tape and documentation are $295. The suite is available on all Sun platforms and requires only 4 megabytes of memory. Sun Microsystems, Inc., headquartered in Mountain View, Calif., is a leading worldwide supplier of network-based distributed computing systems, including professional workstations, servers and UNIX operating system and productivity software. ### OpenWindows, SunView and DeskSet are trademarks of Sun Microsystems, Inc. UNIX is a registered trademark and OPEN LOOK is a trademark of AT&T. All other products or services mentioned in this document are identified by the trademarks or service marks of their respective companies or organizations. For reader inquiries, telephone 1-800-821-4643 outside California. Inside California, call 1-800-821-4642. Press Contact: Cathy Garfield (415) 336-6536 -- Bruce G. Barnett uunet!crdgw1!barnett From don Sun Dec 17 21:04:52 1989 Date: Sun, 17 Dec 89 21:04:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: Here Menu! From: crdgw1!montnaro@uunet.uu.net (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Open Look allows you to pin menus to the screen. Unfortunately, they become just other windows, and are subject to being covered up. Consequently, pinned menus sometimes (for me, often) get covered up, so there's little use pinning them in the first place. I'd like to see a "Here Menu!" function that would cause any pinned menus to float to the top of the stack. Given the existing mouse semantics, I suspect it might best be tied to a PointButton double-click over the root window. Some might prefer to have pinnable menus that won't let themselves get covered up, thus preserving current mouse semantics. Any comments? -- Skip (montanaro@crdgw1.ge.com) From don Sun Dec 17 21:05:29 1989 Date: Sun, 17 Dec 89 21:05:29 -0500 To: NeWS-makers@brillig.umd.edu Subject: Here Menu! From: crdgw1!montnaro@uunet.uu.net (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Open Look allows you to pin menus to the screen. Unfortunately, they become just other windows, and are subject to being covered up. Consequently, pinned menus sometimes (for me, often) get covered up, so there's little use pinning them in the first place. I'd like to see a "Here Menu!" function that would cause any pinned menus to float to the top of the stack. Given the existing mouse semantics, I suspect it might best be tied to a PointButton double-click over the root window. Some might prefer to have pinnable menus that won't let themselves get covered up, thus preserving current mouse semantics. Any comments? -- Skip (montanaro@crdgw1.ge.com) From don Sun Dec 17 21:05:52 1989 Date: Sun, 17 Dec 89 21:05:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Here Menu! From: intercon!amanda%mermaid.intercon.com@uunet.uu.net (Amanda Walker) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article , montnaro@spyder.crd.ge.com (Skip Montanaro) writes: > I'd like to see a "Here Menu!" function that would cause any pinned menus to > float to the top of the stack. Given the existing mouse semantics, I suspect > it might best be tied to a PointButton double-click over the root window. > Some might prefer to have pinnable menus that won't let themselves get > covered up, thus preserving current mouse semantics. Well, the idea of pinned menus being windows that "float" on top of everything except other pinned menus seems to work pretty well on the Mac. It seems a little odd for about the first 5 minutes, and then your brain figures out what's going on and it becomes quite nice. This does, however, involve redoing parts of the window manager, which could range from easy to impossible, depending on how pinned menus are actually implemented. My first guess would be that under X11/NeWS, it wouldn't be too bad, but on a vanilla X11 server it would be pretty difficult. Amanda Walker InterCon Systems Corporation -- From don Sun Dec 17 21:06:10 1989 Date: Sun, 17 Dec 89 21:06:10 -0500 To: NeWS-makers@brillig.umd.edu Subject: Testing NeWS applications. From: mcsun!hp4nl!phigate!nlgvax!harry@uunet.uu.net (Harry Wiggers) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I am looking for possible tools which can be used to test complex interactive applications using NeWS as the user interface. Ideally, the tool should automatically simulate user actions like dragging objects, selecting menu items, editing fields etc. If you have experience of developing such tools or know of any existing test tools which can be used, please let me know. How do you test your NeWS applications? Harry Wiggers. received 731 b 2 secs From don Sun Dec 17 22:40:46 1989 Date: Sun, 17 Dec 89 22:40:46 -0500 To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS server not using BIND ? From: dftsrv!palantir!schuler@ames.arc.nasa.gov (Larry Schuler - RMS) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I recently received the X11/NeWS server from Sun. (OpenWindows, if you prefer.) But I am having problems starting the combined server. It complains that it is "Unable to resolve host: localhost". My guess is that because our Sun's use the modified libraries that provide BIND access, the X11/NeWS server's attempts at obtaining an address for localhost fail, since no search of the local hostfile is being performed. Can anyone confirm this ? Is there any way around this short of removing the BIND supporting libraries from the system ? I can get the server to work in X11ONLY mode by using the standard X11 DISPLAY environment variable, but apparently the NeWS portion of the server requires this localhost link, and I would really like to run the server in dual mode. -- -Larry "Fair is fair, Larry. ... We're out of food, we drew straws - schuler@palantir.gsfc.nasa.gov - you lost." - G. Larson From don Sun Dec 17 22:41:17 1989 Date: Sun, 17 Dec 89 22:41:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Testing NeWS applications. From: voder!pyramid!unify!dgh@ucbvax.Berkeley.EDU (David Harrington) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <547@nlgvax.UUCP> harry@nlgvax.UUCP (Harry Wiggers) writes: > >I am looking for possible tools which can be used to test complex interactive >applications using NeWS as the user interface. Ideally, the tool should >automatically simulate user actions like dragging objects, selecting menu >items, editing fields etc. > >If you have experience of developing such tools or know of any existing test >tools which can be used, please let me know. > >How do you test your NeWS applications? > >Harry Wiggers. I am also very interested in test strategies/tools for testing GUI applications (in our case, a 4GL/Application Generator under Open Look). E-mail or post, please, if you have any info. TIA, -- David Harrington internet: dgh@unify.UUCP Unify Corporation ...!{csusac,pyramid}!unify!dgh 3870 Rosin Court voice: (916) 920-9092 Sacramento, CA 95834 fax: (916) 921-5340 From don Mon Dec 18 07:35:52 1989 Date: Mon, 18 Dec 89 07:35:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: crltrx!max.crl.dec.com!jg@decwrl.dec.com (Jim Gettys) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) X runs just fine on deep frame buffers. My company, among others, has been shipping X servers running on deep frame buffers for a long time (way over a year, in the case of the VS8000). If the X11/NeWS server won't run on deep frame buffers, that's its fault, not X or the X protocol. Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory From don Mon Dec 18 07:37:29 1989 Date: Mon, 18 Dec 89 07:37:29 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: Isaac Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >No, this sounds like deliberate evasion. All the Sun press releases >and speeches and brochures and stuff talk about Open Windows as if it >was real, but Sun still ships the old SunView stuff and doesn't ship >Open Windows *with the system*. yup! all talk, no action. don't count on seeing OpenWindows shipped with SunOS until SVR4/SunOS, which is quite a ways off. >Calling it a "Developers Release, SPARC Only" would be fine -- just stop >telling the press and the customers that Sun is 100% behind Open >Windows, leaving them with an ugly surprise when the system arrives. >Also, I thought the Intel and Motorola ports would be out in October: >> Sun is now shipping OpenWindows 1.0 on SPARC machines. Sun-3 and Sun386i >> versions will start shipping in 30 days. >> >> OWN-1.0-4-4-5 SPARC -- Doc and Media $ 295 ND ** 9/25/89 >> OWN-1.0-4-3-5 Sun-3 -- Doc and Media 295 ND ** 10/25/89 >> OWN-1.0-4-R-5 386i -- Doc and Media 295 ND ** 10/25/89 >(Note the dates in the last column.) >> This means that you can buy one copy of the media and >> documentation and run it on as many Sun workstations as you like. hey, i thought the SPARC release would be out in SEPTEMBER!!! that announcement looks to me like a blatant lie. those dates are completely bogus. yes i know it's a developers release and that it's not an FCS product. but when you make announcements like that, please explain what a developers release is! the above announcement gives me the impression that i can place an order and expect it to arrive within a reasonable amount of time (with their s/w shipping record, that'll be about a month, which really isn't reasonable but....), and that's not the case. the case is, as i found out from the SUG conference - that they are (severly) limiting the number of copies shipped. >Oh, really? Can I upload it to uunet and let anybody FTP it or uucp it >from there? Can I put it on the Sun User Group tape? Can I send it to >the guy in Europe who is getting a runaround from his sales office but >keeps seeing postings from other people who have it? If so, why didn't >Sun just do all this stuff? Or simply put it on the next &%^$ Unix >release! according to their release notice, we should be able to get it via FTP or UUCP. the RTU is part of SunOS. yeah, right. the RTU is limited to some X-hundered of preferred customers. why? because they aren't ready to support it yet with 1-800-USA-4SUN. why can't they just make that fact explicit in the RTF and ship the thing already!!?? i can't think of one GOOD reason, can anyone else? >> At the current time, OpenWindows is a Developers Release. We are not >> recommending it to the general end user community at this time. As a >> result, SunView is still bundled with all of our systems and is the >> default window system for Sun workstations. >And with this policy, it sure will stay that way. no kidding! so far everything they've done has accomplished nothing but decrease the likelyhood of the products success. they are simply killing it. if they wait long enough, they won't have to ship it at all. they can just bury the tapes and it'll be done with! consider this. many people are interested in Open Windows because the MIT X11R3 server for color Sun's is pathetically slow. if you've got a machine with enough memory to run Open Windows, the color performance blows away MIT X11R3. these customers (and maybe there are only a few), will want Open Windows only for X11 and may have no interest in NeWS. but at least they'll have it in their hands, and maybe they'll try it, and maybe they'll like it! so there's some potential for turning more people on to NeWS. but hey, X11R4 is due out next month. and guess what, the Sun color server is (from all reports that i've heard), a LOT faster than the X11R3 server. so people getting X11R4 will be quite happy and won't have any interest in Open Windows. just keep holding those tapes back.... >Will OpenWindows be bundled in SunOS 4.1, or will we have the same >story for another whole year? it'll be the same old story.... and get this. sun announces their new DeskSet utilities - a (really nice) calendar tool, print tool and tape tool, to go along with the other DeskSet tools - the filemgr, etc. - that come with Open Windows. but these new DeskSet tools are not XView programs - they are not for Open Windows. they are SunView programs! someone please explain the rationale behind this brilliant move. these, along with SunWrite/SunPaint/SunDraw, should all be Open Windows tools (written with XView or The NeWS Toolkit). how are they supposed to promote Open Windows by providing new SunView tools??!!!! and these new tools are really nice. they implement Open Look with a 3D look - real slick. and Open Windows (for those few that have it) is still 2D only. i've been running Open Windows for quite some time now - because we were fortunate enough to get into their beta/special program. it's some pre-FCS release (well, there's no FCS release - so pre-developers release i guess). but i've used their current release at SUG, and they are quite similar, so for all i know it's the same thing they're shipping (in very limited quantity). but i can't know since i can't seem to get my hands on the "released" version. whatever version it is ... i like it A LOT. i'm sure that given the opportunity to run it, so will other people!!! keeping it under lock and key isn't going to do anyone any good. in a way, i see another Xerox happenning. you've got some brilliant people at Sun developing some brilliant products: Open Windows, which includes NeWS, XView, Open Look, and GUIDE as a separate future product (i tried this at SUG, it's GREAT). but their marketting people are killing it. they are being totally wishy-washy. introducing some new products under SunView, some under Open Windows. so if you really want to be up to speed you have to run both! i don't like SunView - because it's not a network based window system. i don't care about running SunView applications under Open Windows. i bet if they gutted the SunView compatibility it's performance would improve DRAMATICALLY!! most of Sun's SunView tools have XView equivalents. many commercial products (will) have X11 (and hopefully NeWS, but not at the rate Sun's going) versions. if you need SunView support, use something like overview or adjacentscreens, but take the overhead out of Open Windows. i also happen to like Open Look. but somehow Motif has taken hold. as far as i'm concerned, Motif is a joke. it may have a nice "look" (the 3D is real cute), but the feel sucks. Open Look goes out of its way to have a good feel and to be consistent (my opinion of course). i've tried a few versions of a Motif X11 window manager. the mouse actions that de-iconify a window on one version ended up killing the window on another version (because it brings up a menu with the default action of killing the window). lots of thought went into that i'm sure. why has Motif taken hold? who knows. XView, a freely available X11 toolkit which implements Open Look, has been out there for a while, but not long enough i guess. it's just very depressing to see what i (and i'm sure many readers of this list) consider to be superior technology end up in the dust because of poor management and marketting decisions. NeWS should've been made public (in the sense that NFS was) a *long* time ago. care to guess what would've happened? Open Windows should be made available to everyone and anyone that wants it. MIT doesn't have a 1-800-USA-4X11, they have xpert@expo.lcs.mit.edu. the people that want Open Windows *now* can support themselves! c'mon Sun, get it together. what good are Open Windows if they are covered by iron bars??!!! -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * Internet : salzman@rand.org / | | * UUCP : !uunet!rand.org!salzman | | | From don Mon Dec 18 07:38:24 1989 Date: Mon, 18 Dec 89 07:38:24 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Here Menu! From: zweig!stef@sun.com (Stephane Payrard) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1626@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: From: amanda@mermaid.intercon.com (Amanda Walker) Date: 13 Dec 89 21:54:18 GMT Sender: news@intercon.com In article , montnaro@spyder.crd.ge.com (Skip Montanaro) writes: > I'd like to see a "Here Menu!" function that would cause any pinned menus to > float to the top of the stack. Given the existing mouse semantics, I suspect > it might best be tied to a PointButton double-click over the root window. > Some might prefer to have pinnable menus that won't let themselves get > covered up, thus preserving current mouse semantics. Well, the idea of pinned menus being windows that "float" on top of everything except other pinned menus seems to work pretty well on the Mac. It seems a little odd for about the first 5 minutes, and then your brain figures out what's going on and it becomes quite nice. This does, however, involve redoing parts of the window manager, which could range from easy to impossible, depending on how pinned menus are actually implemented. My first guess would be that under X11/NeWS, it wouldn't be too bad, but on a vanilla X11 server it would be pretty difficult. Amanda Walker InterCon Systems Corporation -- More precisely, if you use pswm (the default window manager of Open-Windows 1.0) it is quite easy. You can even do it without exiting xnews!!!. If you use another wondow manager (I mean a X-based window manager) you don't deserve this improvement. ;-) The following code does exactly what Skip Montanaro proposes: a double click on the frame-buffer brings any pinned menus on top of the hierarchy of the sons of the framebuffer. Just execute the code and the trick is done. If you want to get it each time I guess you can add it to your .user.ps or .startup.ps. If you want to do it cleanly, read NeWS Programmers Guide p 102. If you want to make the modif avalaible to everyone on your site, edit $OPENWINHOME/etc/NeWS/desktop.ps. Keep a copy of the original in the case you make a mistake. A double click is a selection of Level 2. I have slightly edited the (already too long!) method `adjustto' to call in such a case my new method `pinnedmenustotop'. In case of overlapping pinned menus the top ones repaint many times. It seems that in that case (shuffling canvases) xnews is not smart enough to coalesce the Damage envents even if I parenthese `pinnedmenutotop' wih blockinputqueue and unblokinputqueue. I think we can avoid these unwanted repaints by shuffling more skillfully the pinned menus. Instead of calling canvastotop for each pinned menu top to bottom, we need to call canvastotop for the top menu and use insertcanvasbelow (or modifying the canvas key /CanvasBelow) to insert the remaining menu top to bottom. (left as an exercice) ;-) stef (stef@sun.com) DesktopSelectable begin /pinnedmenustotop { framebuffer /TopChild get dup null ne { null exch { dup null eq { exit }if dup isinstance? { /ClassName 1 index send /OpenLookMenuFrame eq { dup } if } if /CanvasBelow get } loop pop { dup null ne { canvastotop } { exit }ifelse } loop pop } if pop } def % Override % /adjustto { % event selection => - gsave dup /Level get 2 ge { /pinnedmenustotop self send } { begin framebuffer createoverlay setcanvas erasepage X null eq { dup ExtractCoords % } if Preview? { PaintSel }{ currentdict [ 3 -1 roll EventCoords X Y 4 2 roll % Here we massage the bounding box so that the % bounding boxes of the canvas' are included. % They are extended by one pixel on the bottom and % right. This adjustment ensures that the % definition of "inside" the bounding box includes % the edges. If this were not done you would not % be able to select canvases that were exactly on % the right or bottom edges of the framebuffer. % points2rect % x y w h exch 1 add exch % x y w+1 h 3 -1 roll 1 sub 3 1 roll % x y-1 w+1 h 1 add % x y-1 w+1 h+1 rect2points /children- framebuffer send { % x0 y0 x1 y1 can % Check whether the canvas is inside the % bounding box. dup /Mapped get { 5 copy true getbbox 7 index 4 index le % llx? 7 index 4 index le % llx? lly? 7 index 4 index ge % llx? lly? urx? 7 index 4 index ge % llx? lly? urx? ury? and and and [ 10 2 roll cleartomark % bool { 5 1 roll }{ pop } ifelse }{ pop } ifelse } forall pop pop pop pop ] /ToggleSelection SendToCanvases /X null def } ifelse end grestore } ifelse } def end % DesktopSelectable -- -- Stephane Payrard -- stef@sun.com -- (415) 336 3726 Sun Microsystems -- 2550 Garcia Avenue -- M/S 16-40 -- Mountain View CA 94043 From don Mon Dec 18 08:52:04 1989 Date: Mon, 18 Dec 89 08:52:04 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS (any flavor) on a DECstation? From: steve@umiacs.UMD.EDU Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Let me clarify something from the message I sent out recently: it now looks like there is only an Educational NeWS 1.0 license, and that NeWS 1.1 sources were shipped on the basis of that license. As such, if you've got a NeWS 1.0 license and no NeWS 1.1 license, and you want a copy of my hacks (and that's exactly what they are!) to put NeWS on a DECstation, drop me a line and we'll try to work something out. -Steve "I used to be a hacker, now I'm just a lawyer" Spoken: Steve Miller Domain: steve@umiacs.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742 From don Tue Dec 19 22:33:21 1989 Date: Tue, 19 Dec 89 22:33:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: SunView or OpenWindows? From: Kemp@DOCKMASTER.ARPA Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Isaac Salzman, in a long diatribe against Sun's marketing of OpenWindows, writes: > hey, i thought the SPARC release would be out in SEPTEMBER!!! that > announcement looks to me like a blatant lie. those dates are completely > bogus. The code for all three Sun architectures *was* available in September. I went back and checked my mail; on Sept 28 I got a note from my local Sun sales rep saying that the three tapes were available for copying. I stopped by and picked up the Sun-3 and Sun-4 versions the next day. > according to their release notice, we should be able to get it via FTP or > UUCP. the RTU is part of SunOS. yeah, right. the RTU is limited to some > X-hundered of preferred customers. why? because they aren't ready to support > it yet with 1-800-USA-4SUN. why can't they just make that fact explicit in > the RTF and ship the thing already!!?? i can't think of one GOOD reason, can > anyone else? One reason might be that most people don't even read the RTF, judging by some of the messages in Sun-spots and elsewhere. The other reason is that if you charge money for something, you have an obligation to support it. Sun has been *rightously* (and justifiably) criticised in the past for poor software support. If they are being more prudent now in ramping up OpenWindows, that's a good sign. If you are serious about being a "developer", i.e. you know enough to play with the software without needing handholding, then talk to your local Sun office. Perhaps they will let you run off a copy of the tape until your release kit arrives. I am not a developer, I'm an end user. I played with OpenWindows for two days, decided it was cute but too slow, and went back to SunView. When they get it tuned up, I'll look at it again. > and get this. sun announces their new DeskSet utilities - a (really nice) > calendar tool, print tool and tape tool, to go along with the other DeskSet > tools - the filemgr, etc. - that come with Open Windows. but these new > DeskSet tools are not XView programs - they are not for Open Windows. they > are SunView programs! someone please explain the rationale behind this > brilliant move. Simple. SunView is mature. OpenWindows is in development. Sure they could just stop all work on SunView and force everyone to migrate to OW, but those of us who use our Suns for engineering (or medicine, or publishing, or ...) wouldn't appreciate it. I'm glad there are lots of hungry grad students and people at places like RAND working on new technology, and some day I'll reap the benefits of that work. But, OpenWindows is not yet ready for prime time, and dropping SunView now would be premature. > i don't like SunView - because it's not a network based window system. i > don't care about running SunView applications under Open Windows. i bet if > they gutted the SunView compatibility it's performance would improve > DRAMATICALLY!! And I bet it wouldn't. So there. What makes you think SunView compatibility has much of anything to do with performance. If I had to guess (and that's all it would be), I'd say that's way down in the noise. Don't try to justify your prejudice with opinion. --------------------- Sun's position seems pretty clear to me. They are working towards SPARC/UNIX/OpenLook. They are ramping down Motorola and Intel as SPARC sales increase. I have no doubt that they will ramp down SunView as OpenWindows grows in maturity and installed base. Any other approach would be folly. Dave Kemp From don Tue Dec 19 22:34:01 1989 Date: Tue, 19 Dec 89 22:34:01 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: robin@Sun.COM (Robin Schaufler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) From NeWS-makers-request@cs.UMD.EDU Sat Dec 16 05:31:35 1989 To: NeWS-makers@brillig.umd.edu Subject: Re: NeWS on a CG8-9 From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Is it possible that the NeWS side of XNeWS could would run in 24bits pretty much as-is, whereas the X side would require a little bit more work, or is it the case that the port would be as difficult for both sides (or is there effectively only one thing to port)? > I don't really know how X11/NeWS is implemented internally. I thought both > halves were built on top of a common graphic library, in which the X side > wouldn't take much additional work. Yes, Bob is correct. You get 2 ports for the effort of one. However, since we didn't have any 24 bit hardware while xnews 1.0 was being developed, we don't know whether the X-specific server code is correct. -- Robin From don Tue Dec 19 22:35:10 1989 Date: Tue, 19 Dec 89 22:35:10 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8912162135.AA03025@iris.rand.org>, salzman%iris (Isaac) writes: > How are >they supposed to promote Open Windows by providing new SunView tools??!!!! >someone please explain the rationale behind this >brilliant move. Perhaps they are promoting OpenLook instead of Open Windows. OpenLook has nothing to do with operating systems or toolkits. You can have OpenLook on a PC, Mac, OS/2, Amiga, VMS system. The real goal is to have the same user interface on every computer, not just on Unix workstations running the X window system. Remember the analogy of dashboards - you can get inside any car and drive it away. No so with computers. Also - OpenLook does have some advantages over SunView with respect to user interfaces. I am also sure that a lot of people would love to have the file manager on their workstation and still have all of the advantages of SunView. >i bet if >they gutted the SunView compatibility it's performance would improve >DRAMATICALLY!! It might be true - as a lot of code is in the kernel. Removing 100K from the kernal would give you the equivalent to 1 Meg in user space, since you can page in the code you need. But I don't really understand your comment about "it's performance". what is "it"? The server? The application? The window manager? The real problem is that you may end up using three or more toolkits that are not sharing any code. SunView, XView, tNt, plus the other X toolkits. Each toolkit has it's advantages. But using all three at once does eat up a lot of memory. >most of Sun's SunView tools have XView equivalents. As of today, I doubt this. There are a LOT of SunView programs out there. Catalyst, etc. A year from now you may be right. -- Bruce G. Barnett uunet!crdgw1!barnett From don Tue Dec 19 22:35:27 1989 Date: Tue, 19 Dec 89 22:35:27 -0500 To: NeWS-makers@brillig.umd.edu Subject: X11/NeWS BIND resolution solution From: dftsrv!palantir!schuler@ames.arc.nasa.gov (Larry Schuler - RMS) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Thanks to all who replied to my original request for information. To summarize: I was having problems with the X11/NeWS server (OpenWindows) on our Sun workstations. The problem was actually in the way our BIND nameservers were configured. The server was doing a gethostbyname() call to resolve the hostname "localhost", which was undefined in our nameservers, thus causing the lookup to fail. The simple resolution was to add localhost to the nameserver database. Thanx again. -- -Larry "Fair is fair, Larry. ... We're out of food, we drew straws - schuler@palantir.gsfc.nasa.gov - you lost." - G. Larson From don Tue Dec 19 22:36:08 1989 Date: Tue, 19 Dec 89 22:36:08 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4290@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > You can have OpenLook on a PC, Mac, OS/2, Amiga, VMS system. > The real goal is to have the same user interface on every computer, > not just on Unix workstations running the X window system. How about the same programmer interface as well? One nice thing about C is that the stdio library gives you pretty much the same programmer interface to what are really quite sophisticated system functions on a wide variety of machines. Don't you think it's time to take a step back and look into this? Until it's there, having a standard *user* interface is a bit premature. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Tue Dec 19 22:37:55 1989 Date: Tue, 19 Dec 89 22:37:55 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!rpi!crdgw1!crdgw1.ge.com!barnett@tut.cis.ohio-state.edu (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <7352@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >How about the same programmer interface as well? >Don't you think it's time to take a step back and look into this? > >Until it's there, having a standard *user* interface is a bit premature. I don't agree. First of all, there would have to be a standard language. C++ and Lisp would be a good choice for an object oriented windowing system. And of course PostScript/NeWS. Perhaps the standard has already been defined - CLX. That's X windows on top of CLOS, which is the object oriented extension to common lisp. Does this solve your problem? Of course not. I would rather use an object oriented (O-O) language to support an O-O window system. If I couldn't have that, then I would want a package that would let me design the program interactively, without any programming. I certainly would not want to wait three years for a standards committee to define the stdio-windows library package. And if something does come out - it wouldn't have the ability to provide the features I need today. IMHO defining a standard binding is premature. People don't even know what toolkit to use! Standards are also restricting - they are great at telling people what they cannot do. Defining a standard programming too soon is a disaster. in <7344@ficc.uu.net> Peter says: >Personally, I think terminfo sucks. Case in point. terminfo is a standard package for ASCII terminals. It doesn't make it good. Also - as any novice software engineer will tell you, the first step in a project is the top level specifications. You DON'T write code before you know what it is that you want the code to do. This is the function of the Open Look style guide. I think it is obvious that the top level specifications should be done before any code is written. -- Bruce G. Barnett uunet!crdgw1!barnett From don Tue Dec 19 22:40:53 1989 Date: Tue, 19 Dec 89 22:40:53 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: stout.UCAR.EDU!thor@handies.ucar.edu (Rich Neitzel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > > The real goal is to have the same user interface on every computer, > not just on Unix workstations running the X window system. > > Remember the analogy of dashboards - you can get inside any car and > drive it away. No so with computers. > Sigh! I can't stand it any longer. This is a very bad analogy in my opinion. Yes, I can drive any car car intended for the U.S. market, but the level of commonality is no where near the level that as proposed by the "one user interface claim". I own two cars, made the same year by the same firm and here is a partial list of the differences in dashboard layout- 1> One has the dimmer switch on a lever on the steering column, the other has a foot switch. 2> One has the gear selection lever on the steering column, the other is floor mounted. 3> One has only simple idiot lights that turn red to indicate a problem, the other has analog gauges. 4> The fuel level gauges are on opposite sides of the speedometer. 5> One has a true toggle switch for the rear defroster, the other has a momentary button. Further, the toggle swicth lights up whle the defroster is on, the other has no indicator. 6> On one the heater speed controls are aligned horizontally and placed below and to the right of the temperature control. On the other the speed control is vertically aligned and to the left of the temperature control. I could go on with many more examples of how these two vehicles differ in their control interfaces, but I think the point is clear - despite all the overblown hype about consistent user interfaces and the claims that these are common outside of computing, the truth is quite the opposite. In few cases are there universal interfaces for functions that are even moderately complex. Further, it is rare for users to find this a limitation or barrier to their use of the item in question. When was the last time anyone heard a serious complaint that the dashboard of their Escort was not identical in layout and function to the dashboard in their Civic? I suspect that no reading this has any trouble using an elevator, but there are obviously no standards in their control design, not even in which direction the floor numbers soon run - highest at the bottom, lowest, etc. All this talk about commonality of "look & feel" is simply an attempt to evade the real issue in the design of user interfaces - does the interface for THIS application adequate suit the conditions of use, level of user skill and functionality required to perform the job? Common user interfsces simply make the life of developer easier by allowing one to put on any interface, cklaim that this is good because it is "standard" and walk away. No thought or concern about reality required! Don't force interface applications into a bed of Procrustes (sp?)! ------------------------------------------------------------------------------- Richard Neitzel National Center For Atmospheric Research Box 3000 Boulder, CO 80307-3000 303-497-2057 thor@thor.ucar.edu Torren med sitt skjegg Thor with the beard lokkar borni under sole-vegg calls the children to the sunny wall Gjo'i med sitt shinn Gjo with the pelts jagar borni inn. chases the children in. From don Tue Dec 19 22:44:28 1989 Date: Tue, 19 Dec 89 22:44:28 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: cs.utexas.edu!sun-barr!newstop!texsun!texbell!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Suggested that a standard user interface is premature, and urged consideration of the lack of a standard programmer interface. The analogy I used was with the UNIX system calls and the C stdio library... In article <4301@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > I don't agree. First of all, there would have to be a standard > language. Why? Let's go back to my analogy... what difference does it make whether the system call looks like: nread = read(fd, buf, nbytes); CALL READ(FD, BUF, NBYTES, NREAD) CALL C_READ(FD, @BUF, NBYTES, @NREAD); (setq nread (read fd buf nbytes)) nread := cread(fd, buf, nbytes); The semantics are the same. Similarly, let's look at a hypothetical window call: Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); CALL ADDWM(WINDOW, 'Frobitz', 'Fooble', MENU) CALL W_ADDWINDOWMENU(WINDOW, @('Frobitz',0), @('Fooble'), @MENU); (setq menu (AddWindowMenu Window 'Frobitz 'Fooble)) menu := AddWindowMenu(Window, 'Frobitz', 'Fooble'); > C++ and Lisp would be a good choice for an object oriented > windowing system. I don't think tying windowing into any particular metaphor is a good idea. A program is more than a user interface with a bit of work going on behind it. The main purpose for most programs is what they do, not what they look like. > Does this solve your problem? Of course not. I would rather use an > object oriented (O-O) language to support an O-O window system. I'd rather use the best language for the job the program is intended to do. Not the best language for the user interface. That's just putting the cart before the horse. What if you're working in Prolog? Or APL? Or you're working for the DoD in ADA? Or adding a GUI to MicroEmacs? > I certainly would not want to wait three years for a standards > committee to define the stdio-windows library package. But you're willing to wait three years for a standards committee to define the user interface? > IMHO defining a standard binding is premature. People don't > even know what toolkit to use! Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's way too low level for something like this. > Standards are also restricting - they are great at telling people what > they cannot do. Defining a standard programming too soon is a disaster. No more than defining a standard UI. > in <7344@ficc.uu.net> Peter says: > >Personally, I think terminfo sucks. > Case in point. terminfo is a standard package for ASCII terminals. > It doesn't make it good. Termcap is a standard package for ascii terminals too. It's a hell of a lot smaller, cleaner, and (as I said in the message you so ruthlessly cribbed that from) better. Besides, Termcap and terminfo are both far below the level I'm talking about here. Curses is a closer metaphor. > Also - as any novice software engineer will tell you, the first step > in a project is the top level specifications. You DON'T write code > before you know what it is that you want the code to do. Yeh, but is the code supposed to put up pretty pictures or do real work? > This is the function of the Open Look style guide. The style of the UI shouldn't even be *in* the program. The details involved in OpenLook or Motif are way too low level. they belong in the UI handler (whether it be a server process, a PostScript program, a shared library, or even a statically linked library). > I think it is obvious that the top level specifications should be > done before any code is written. Yeh, but what should we be specifying? "I want a window big enough to hold the following objects: a text pane containing this text, and a selector for YES and NO. Tell me when someone selects YES or NO, and don't bug me otherwise", or "Draw a rectangle here, now put these characters in this font here, and then draw these rectangles... (lots deleted) now tell me when anyone clicks in my window. Oh, OK, erase this rectangle and redraw it here, and blit this rectangle up by the size of this font, put these characters here, and tell me what you want me to do next..." ? -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Tue Dec 19 22:46:16 1989 Date: Tue, 19 Dec 89 22:46:16 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!rpi!crdgw1!crdgw1.ge.com!barnett@tut.cis.ohio-state.edu (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <5728@ncar.ucar.edu>, thor@stout (Rich Neitzel) writes: >Sigh! I can't stand it any longer. This is a very bad analogy in my >opinion. Yes, I can drive any car car intended for the U.S. market, but >the level of commonality is no where near the level that as proposed by >the "one user interface claim". It is only an analogy. But there is some truth to it. The first time I started up X windows I could get it to do NOTHING. Zip. No menus. mouse clicks did nothing. I tried every combination I could think of, and then gave up. I am someone who has used several window systems. But I could not "drive" the system I installed. >All this talk about commonality of "look & feel" is simply an attempt to >evade the real issue in the design of user interfaces - does the >interface for THIS application adequate suit the conditions of use, >level of user skill and functionality required to perform the job? >Common user interfsces simply make the life of developer easier by >allowing one to put on any interface, cklaim that this is good because >it is "standard" and walk away. No thought or concern about reality required! Well - first of all - the person who benefits most from a common user interface is the user. I would love to have all of tools on all of the window systems I use have the same user interface. It is true that all standards have limitations. I have not found one that was perfect yet. But your statement can be argued. Since this discussion started with Open Look, I can say that Sun has done a lot to address the issue you mention. They have tried to provide a standard look and feel that is an improvement on what else is out there. Did you ask for a copy of the preliminary style guide? Do you have a copy of the current one? Did you send in your criticisms? Did it meet your requirements for a "real" application? How did Sun evade the real issue? -- Bruce G. Barnett uunet!crdgw1!barnett From don Wed Dec 20 01:57:17 1989 Date: Wed, 20 Dec 89 01:57:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: SunView, Open Windows, Open Look [was Re: Is SUN a "PURE PLAYER"...] From: Isaac Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) >> Perhaps they are promoting OpenLook instead of Open Windows. oh they are definitely trying to promote OpenLook. but my understanding is that they are supposed to be promoting Open Windows as well. >> OpenLook has nothing to do with operating systems or toolkits. >> You can have OpenLook on a PC, Mac, OS/2, Amiga, VMS system. correct. and having a SunView implementation, along with an XView and tNt implementation is proof of that concept. that's good for Open Look's sake. but.... Sun talks about moving their windowing platform to X11/NeWS, which is supposed to be the windowing platform for AT&T SVR4 as well. i view it this way. *most* USERS (which excludes readers of this list) don't understand the benefits of a network based window system. they just want their terminal emulator, etc. they don't care about SunView vs. X11 vs. NeWS. developers do for technical reasons. marketting people love things like X11 because standards are a great way to sell a product these days. i don't see incentive for a lot of Sun installations to get the move on to Open Windows if they continue to create neet things like the calendar manager for SunView. i would've produced an X11/NeWS version first - or only, for that matter. it just doesn't make sense to me to keep building new tools for a system that's not going to be supported in the future. i'd love to see an X11/NeWS based sun write/paint/draw as well. when is sun going to COMMIT to windowing platform. Open Look is great. i think it should be promoted, even under SunView. but running Open Windows is more important to me. having a network based window system is more more important to me. i think it is to a lot of people. that has a greater impact on how i do my work than Open Look right now. there are a lot of X11 clients i use. at the same time, i want to get more into working with NeWS and doing interesting things with graphical user interfaces. >> The real goal is to have the same user interface on every computer, >> not just on Unix workstations running the X window system. >> >> Remember the analogy of dashboards - you can get inside any car and >> drive it away. No so with computers. >> a real STANDARD user interface for computers is a long time commin'. my personal belief is that it will never come. if it does, it's not going to be just Open Look or just Motif. forget that. a computer is too general of a tool to try and standardize the way you interact with it. you can come close. you can define some sort of standards for various classes of applications, but no one's going to come up with the one "look and feel" and the one toolkit that will allow someone to build ANY application with an appropriate user interface. i like the analogy of UI's versus cars. many others have used it and i've used it myself. they are like cars in that they are a form of transportation (in a wierd sort of way). they get you where you need to go - in your application. but like cars, everybody's got their own style and preference. some people like Porsche's, some like Camaro's, some like VW's. the approach people are taking with UI standardization is like forcing everyone to drive a VW. what is standardized about a car are the basic concepts of operation: a steering wheel, a brake pedal, gas pedal, a dash board, etc., not what they look like. with a UI, some of that has pretty much been settled. you've got buttons and pull down menus, etc. those things pretty much work the same in everyone's toolkit. there should be some flexibility in determining how these things look, to the degree that you know that what you're looking at is a button or a pull down menu. but to try and force the world to make all applications look the same is rediculous. one thing that Open Look addresses is how applications communicate with one and other. filemgr is great. you can drag a document from filemgr onto the textsw of textedit - and bingo, you're file appears. that's nice! i think standardization of UI's will really start to happen when i can drag a document from filemgr onto the text window of a Motif application and have the same thing happen. the concepts and the way in which communication happens - both between the human and computer and the applications to one and other, need to be defined. then we'll have standard UI's. i'm wondering why this hasn't happened yet. this stuff just isn't new anymore. i first used an Alto (roughly) 13 years ago..... >> >i bet if >> >they gutted the SunView compatibility it's performance would improve >> >DRAMATICALLY!! >> >> It might be true - as a lot of code is in the kernel. >> Removing 100K from the kernal would give you the equivalent to >> 1 Meg in user space, since you can page in the code you need. >> >> But I don't really understand your comment about "it's performance". >> what is "it"? The server? The application? The window manager? i mean the server's performance - "xnews". someone else commented that they didn't think it would make any difference. and i don't think memory utilization's the only issue. i'm running on a color (no lego) 16meg SS1. X10 on a color 8meg 4/110 is still faster - or as fast (from what i recollect). that may be a horrible example. i've talked to people that have seen NeWS 0.4 (or some pre-1.0 version). they said it ran faster than anything they'd used before, including SunView - on a 3/50. it was a pure NeWS server - no SunView support. but i gather marketting insisted on putting SunView support into NeWS - and that's when the performance dropped. maybe someone in Sun would care to comment on that? i have no empirical evidence of my own. but i get the feeling that removing SunView support and really tunning the server for the various frame buffers would make it run like a bat out of hell. >> The real problem is that you may end up using three or more toolkits >> that are not sharing any code. SunView, XView, tNt, plus the other X toolkits. >> >> Each toolkit has it's advantages. But using all three at once does eat >> up a lot of memory. again, i'm talking about the server. i've got lots of memory. X11 on our HP 350's (or whatever the model number is -- 68020 based machines with ~4meg) still performs better in terms of rendering and moving windows around. >> >most of Sun's SunView tools have XView equivalents. >> >> As of today, I doubt this. There are a LOT of SunView programs out >> there. Catalyst, etc. A year from now you may be right. i should've been more specific. i'm talking primarily about Sun's desktop applications. if you've got some special app, run it using overview (or something similar). encourage the catalyst vendors to switch over to Open Windows. but why should they do it if Sun hasn't even committed themselves to it?? [NOTE: these opinions are solely my own and do not in any way represent the opinions of the organization i am employed by] -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * Internet : salzman@rand.org / | | * UUCP : !uunet!rand.org!salzman | | | From don Thu Dec 21 03:42:16 1989 Date: Thu, 21 Dec 89 03:42:16 -0500 To: NeWS-makers@brillig.umd.edu Subject: Toolkits, toolkits, toolkits ... From: spectral!sjs@bellcore.com (Stan Switzer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Against my better judgement I jump into the fray ... In article <7363@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > ... of the lack of a standard programmer interface. The analogy I used was > with the UNIX system calls and the C stdio library... There is simply no use comparing something like stdio with a a graphical user interface. There are two "tricks" behind stdio: 1) let's imagine that files are just bytestreams and 2) the printf vararg hack. These are nice tricks to be sure, but are something of an overabstraction. How many times have you seen the query, "how do you read a single character from the terminal" in comp.lang.c? Is this REALLY such a crazy question? Hmmm. Let's see if we can find a simple abstraction for windowing... > nread = read(fd, buf, nbytes); No wait. That's too simple. > Similarly, let's look at a hypothetical window call: > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); Looking kinda like a widget call isn't it? I mean after we answer a few questions like where the window is to be placed relative to other windows, what kind of behaviors the window is to have, etc. > > C++ and Lisp would be a good choice for an object oriented > > windowing system. [That's Bruce talking.] Yes. Objective-C or PostScript with the object-oriented extensions and a powerful toolkit are pretty good too. Looked at tNt yet? > I'd rather use the best language for the job the program is intended to > do. Not the best language for the user interface. That's just putting the > cart before the horse. What if you're working in Prolog? Or APL? Or you're > working for the DoD in ADA? Or adding a GUI to MicroEmacs? Good points all. That is why I like to download all of my UI code into the server and interface to it using stubs crafted to the specific functionality of the interface. Looked at NeWS's "cps" yet? > > I certainly would not want to wait three years for a standards > > committee to define the stdio-windows library package. > > But you're willing to wait three years for a standards committee to > define the user interface? Why? I've got a job to do today. I have the technology to do it. I don't expect that it will last forever or that it won't take additional work to keep up with the technology rat-race. I expect someday that people will notice who's getting the job done and try to standardize based on the successful tools rather than trying to define success through the standards process. > Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's > way too low level for something like this. Mon ami, have you REALLY looked at the X widget interface? Nobody is suggesting you write an interface using Xlib. But back to the search for a simplifying windowing metaphor... > Besides, Termcap and terminfo are both far below the level I'm talking > about here. Curses is a closer metaphor. > ... > "I want a window big enough to hold the following > objects: a text pane containing this text, and a > selector for YES and NO. Tell me when someone selects > YES or NO, and don't bug me otherwise", Oh! Curses. There's an idea: a window is a screen region with text and maybe a few menu items at the top. > "Draw a rectangle here, now put these characters in > this font here, and then draw these rectangles... > (lots deleted) now tell me when anyone clicks in my > window. Oh, OK, erase this rectangle and redraw it > here, and blit this rectangle up by the size of this > font, put these characters here, and tell me what > you want me to do next..." Wait a minute here, now it's getting complicated. What's that? You want to implement a drawing tool? Sorry, we only blit rectangles. Circles? Polygons? Clipping? Filling, images, animation, sliders, scrollbars, menus? Oh stop! It's getting SO complicated! There is a minimum complexity to a windowing interface unless you accept that some of the inherent capabilities of the device will be unaccessable. Yes, simplifying models are quite useful, but they are not always appropriate to the task at hand. This is why an object-oriented interfacing approach is a Good Thing. You can define object classes which capture certain interfacing abstractions and present a simple interface to the user for that particular interfacing abstraction. But who knows what gadgets might be useful? I wrote and debugged a "graph" gadget for NeWS which allows you to grab points on the graph and adjust them visually in a few hours one evening after putting the baby to bed. Why should it be hard? In NeWS it isn't. Unfortunately, as a result my interface will forever be more complex than it was before. Every time I write a program I'll have to ask myself: "Self," I ask, "do you want to use a graph item, a slider, a scrollbar, or one of these other tools?" Now look what I've gone and done! But to pick some particular simplifying abstraction and to base an API on that abstraction is going to doom you to forever explaining to the poor user who asks "how do I let a user drag the control point of a spline with real-time visual feedback" that you had not anticipated his particular need and if he weren't so stupid he'd know that you can't read a single character from the terminal without doing non-portable hacks. As Yogi Berra said, "It's deja-vu all over again." Stan Switzer sjs@bellcore.com From don Thu Dec 21 03:42:46 1989 Date: Thu, 21 Dec 89 03:42:46 -0500 To: NeWS-makers@brillig.umd.edu Subject: Two guestions on xnews From: eru!luth!sunic!tut!ks@bloom-beacon.mit.edu (Syst{ Kari) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) 1) I've been using the X-version of FrameMaker with my X/NeWS server. Everything works fine, except search window. For some reason I cannot set the focus to search window. Does anybody know why ? Is there any way force the focus to that window. 2) How can I change the font of the mailtool ? In order to find some hints to this problem I check the binary of mailtool. The command "strings `which mailtool` | fgrep .mailt" prints: %s/.mailtool-init The man-page of mailtool does not mention .mailtool-init !. -- -- Yll{oleva on on minun mielipiteeni, ei TTKK:n. -- The above contains my opinions, not the ones of Tamp. Univ. of Technology. -- Samma p} svenska. Kari Systa ks@tut.fi (ks@tut.UUCP, ..!mcvax!tut!ks, ks@fintut.bitnet) Tampere Univ. Technology Telefax: Phone Software System Laboratory +358 31 162913 work: +358 31 162585 Po. Box. 527, SF-33101 Tampere, Finland home: +358 31 177412 From don Thu Dec 21 03:44:33 1989 Date: Thu, 21 Dec 89 03:44:33 -0500 To: NeWS-makers@brillig.umd.edu Subject: Rather 'Common' or 'Good'? (Was: Is SUN a "PURE PLAYER" ...) From: shlump.nac.dec.com!deccan.dec.com!nick@decuac.dec.com (Nick Tsivranidis) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Organization: Digital Equipment Corporation > >All this talk about commonality of "look & feel" is simply an attempt to > >evade the real issue in the design of user interfaces - does the > >interface for THIS application adequate suit the conditions of use, > >level of user skill and functionality required to perform the job? > >Common user interfsces simply make the life of developer easier by > >allowing one to put on any interface, cklaim that this is good because > >it is "standard" and walk away. No thought or concern about reality required! > > Well - first of all - the person who benefits most from a common user > interface is the user. I would love to have all of tools on all of the > window systems I use have the same user interface. > > -- > Bruce G. Barnett uunet!crdgw1!barnett I think that Rich's point is that the user doesn't benefit from a "common" user interface but from a "good" user interface. And this: If you look at the real world, there are many different user interfaces for different classes of products (cars vs TVs), and within the SAME class, you can still find a lot of differences (as Mr Neitzel illustrates with his Civic vs some other car example.) What it comes down to is a question of what level of commonality are we talking about. I don't think anybody wants a driving wheel on his TV, just like nobody wants to drive their car with a remote control (even though both are doable if I judge from some user interfaces I 've seen). There is only one golden rule of User Interface design (and the rest of life for that matter): Do what makes sense. Notice that when you follow this rule, all the responsibility falls on the designer's shoulders. No excuses ala 'Well the toolkit supports only remote controls as driving devices and I wanted to follow the standard'. Of course, you can ask the question: How does somebody go about designing a User Interface with no guidelines and no standards? One great example of how to do a User Interface is the real world. If your application doesn't have any real world analogies, the second thing you can do is to steal somebody else's ideas (that's how you get standards to evolve also). If that fails, use your imagination. After all, that's what the fun of User Interface design is all about (I mean stealing other people's ideas :) ). - Nick - From don Thu Dec 21 03:50:17 1989 Date: Thu, 21 Dec 89 03:50:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <7363@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Suggested that a standard user interface is premature, and urged consideration >of the lack of a standard programmer interface. The analogy I used was >with the UNIX system calls and the C stdio library... >In article <4301@crdgw1.crd.ge.com> I wrote: >> I don't agree. First of all, there would have to be a standard >> language. >Why? Let's go back to my analogy... what difference does it make whether >the system call looks like: > > nread = read(fd, buf, nbytes); > CALL READ(FD, BUF, NBYTES, NREAD) > CALL C_READ(FD, @BUF, NBYTES, @NREAD); > (setq nread (read fd buf nbytes)) > nread := cread(fd, buf, nbytes); >The semantics are the same. Creating simple windows is not really an issue. As I mentioned, if your window system allows you to prototype a simple window tool in 30 minutes, you wouldn't need a standard library. If the results used a toolkit that was available to everyone - you would have portable code. Sun has donated XView to the world. There's one portable library. Does this solve your problem? If not, I'd like to understand why. I, you see, don't think a common library would solve the REAL problem. Portability is not easy in the X world. You must worry about fonts to use. If you had a very high resolution display, you couldn't use the same font as a 640*480 display. The xfig program is a program that needs completely different layouts for 640*480 vs. 1000*1000 displays. I tried it on an X terminal and the window was too big. I couldn't use it. With the flexibility of .XDefaults, this is even more complex. Let's say Joe Programmer decides to use XView. Jill Hacker decides to use the HP or Motif toolkit. And Bill Consumer ends up confused because he used both programs at the same time and the scrollbars are completely different. I would love to have a single scrollbar that is used in every tool I use. I would also love to have a perfect scrollbar. There's no such thing as perfection. Therefore we will see an evolution in scrollbars as the years go by. The biggest advantage of the Mac is that most programs have the same user interface. I am not saying the interface is good, just uniform. When a Mac user gets a new program, he/she doesn't even read the manual before trying it out. It is not necessary. This is a good thing. Unix needs the same benefit if it is to be the heir to the throne. One of the most important features of a window systems package is extensibility. If it cannot be extended - it will not be successfull. You said: > Personally, I think terminfo sucks. >Termcap is a standard package for ascii terminals too. It's a hell of >a lot smaller, cleaner, and (as I said in the message you so ruthlessly >cribbed that from) better. I was being brief, not ruthless. One of the reasons termcap is better than terminfo is its extensibility. I also was pointing out that standards are not necessarily useful. ESPECIALLY if they are too low a level. >Similarly, let's look at a hypothetical window call: > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); > CALL ADDWM(WINDOW, 'Frobitz', 'Fooble', MENU) > CALL W_ADDWINDOWMENU(WINDOW, @('Frobitz',0), @('Fooble'), @MENU); > (setq menu (AddWindowMenu Window 'Frobitz 'Fooble)) > menu := AddWindowMenu(Window, 'Frobitz', 'Fooble'); > >> C++ and Lisp would be a good choice for an object oriented >> windowing system. > >I don't think tying windowing into any particular metaphor is a good idea. >A program is more than a user interface with a bit of work going on behind >it. The main purpose for most programs is what they do, not what they look >like. > >> Does this solve your problem? Of course not. I would rather use an >> object oriented (O-O) language to support an O-O window system. > >I'd rather use the best language for the job the program is intended to >do. Not the best language for the user interface. That's just putting the >cart before the horse. What if you're working in Prolog? Or APL? Or you're >working for the DoD in ADA? Or adding a GUI to MicroEmacs? I agree. Since I feel that a good window system should be extensible, how can this be done? One of the best methods is to use Object Oriented programming. You should be able to extend a scrollbar to improve on it. Example - you have an application with several windows with scrollbars. You want to redefine the scrollbar to pop up a menu and show you a special index into the window. In a few cases you may want it to be a list of C functions in a source file. So you would want to subclass the new scrollbar class and create several instances of it. Now suppose you wanted to add a new method to help you debug this extension. Or you want to change one of the methods to either create a hard copy of the menu in action, or perhaps a keep a histogram of the menus called. And you also want multiple inheritance. And of course you want to redefine/add these methods dynamically. My point is that this is difficult to do in Fortran, C or Pascal. Yet if you were limited to the C language, you would not be able to make use of the more powerful features that are really needed. It is true that there are a lot of applications that don't need O-O techniques to develop powerful programs for them. But others do. If you want a standard to be a subset of a powerful window system, fine. I don't want such a standard myself. I would rather search for the perfect user interface. I'm sorry for going on and on. I'll cut this short. > >Yeh, but what should we be specifying? > > "I want a window big enough to hold the following > objects: a text pane containing this text, and a > selector for YES and NO. Tell me when someone selects > YES or NO, and don't bug me otherwise", >or > "Draw a rectangle here, now put these characters in > this font here, and then draw these rectangles... > (lots deleted) now tell me when anyone clicks in my > window. Oh, OK, erase this rectangle and redraw it > here, and blit this rectangle up by the size of this > font, put these characters here, and tell me what > you want me to do next..." I guess I still don't follow your real complaint. If you want a portable program, use one of the toolkits. If you don't like the toolkit, extend it. If it can't be extended easily, pick a different toolkit. If you want an application to run on PC's, Mac's, Amiga's and Unix machines - I agree - this is a difficult problem. You can get X for Mac's and I think PC's. One vendor has a portable window package. It runs on PC and Unix machines. In either case, solutions exist now. To use your example, you could use the technique in the sources of xfig? Xfig started on sunview and was ported to X not using XView. There are a few routines that provide a common interface to drawing text, bitmaps, and lines. The "portable library" is just a few lines long. Why not just make up your own little routines to draw vectors and text, and build up your own primitives? Use xfig as a start. I, personally, would prefer to have a toolkit that let's me define classes of objects to be drawn, moved, rescaled, selected, grouped, deleted, etc. I would like to sub-class these objects so that I can draw a new thing, like a shaded box, and insert this new thing into my menu, so I can draw it again as easily as I can draw a circle. I would also like to be able to edit, move, refresh. etc. the entire diagram with no network traffic. This way I could use it over a 1200 baud modem with reasonable results. But then, I would just start with Bernard Yves's Illustrator program for NeWS, because it does all that. (In 5000 lines of code! Xfig is 17,000 lines.) In conclusion, I think a standard library would limit creativity, and slow down evolution towards a decent user interface. I agree with Padlipsky: "Standards should be discovered, not decreed" -- Bruce G. Barnett uunet!crdgw1!barnett From don Thu Dec 21 22:38:47 1989 Date: Thu, 21 Dec 89 22:38:47 -0500 To: NeWS-makers@brillig.umd.edu Subject: Anyone have NeWS on a DG AViiON 300? From: intercon!amanda%mermaid.intercon.com@uunet.uu.net (Amanda Walker) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There's this brand spanking new Data General AViiON 300 workstation in my office, and I think it would be very happy running NeWS :-). Does anyone know of a NeWS port for it, and if so, where one could purchase a copy? Thanks, Amanda Walker InterCon Systems Corporation amanda@intercon.com -- From don Thu Dec 21 22:39:04 1989 Date: Thu, 21 Dec 89 22:39:04 -0500 To: NeWS-makers@brillig.umd.edu Subject: Must I have SunOS 4.0.3 for OpenWindows ?? From: phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Can I get by with SunOS 4.0.1 ?? Any pointers appreciated. -- Eric Ho Princeton University eho@confidence.princeton.edu From don Thu Dec 21 22:39:42 1989 Date: Thu, 21 Dec 89 22:39:42 -0500 To: NeWS-makers@brillig.umd.edu Subject: BTOL 1.2 From: korp@tripoli.ees.anl.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Version 1.2 of BTOL is included below. Now have full support for X11/NeWS. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% BTOL -- VERSION 1.2 %%% (Better Than Op*n L**k) %%% %%% %%% Version 1.2: %%% Full support for Open Windows! Parts changed to allow %%% identical operation in the Merge as well as NeWS 1.1. Also fixed %%% some font handling bugs. BtolMenuButton now has an AutoSize routine %%% that needs to be called when font changes are made to the button. %%% %%% Version 1.1: %%% Now includes support for tear off menus! There is also a %%% minor programming change. After making the appropriate calls to %%% Make*Control, one must now call MoveFrameControls explicitly. %%% %%% Version 1.0: %%% This work was originaly generated to improve on the standard %%% lite window and menu implementations. Besides, we were all getting %%% tired of following those crazy pullright menus 4-5 levels deep. %%% %%% This is Version 1.0 of the BTOL window package %%% Feel free to use this code as you like, provided this header is %%% left intact. If you come up with neat new features, questions, bugs, %%% ideas or whatever let us know, it would be greatly appreciated. %%% %%% %%% Peter A. Korp %%% Argonne National Laboratory %%% Visual Interfaces Section %%% korp@athens.ees.anl.gov %%% %%% David C. Mak %%% Argonne National Laboratory %%% Visual Interfaces Section %%% mak@athens.ees.anl.gov %%% %%% David G. Zawada %%% Argonne National Laboratory %%% Visual Interfaces Section %%% zawada@athens.ees.anl.gov %%% %%% %%% %%% %%% BTOL provides NeWS application programmers with 5 new classes that %%% allow for writing more visually appealing software. These classes %%% implement new: %%% %%% 1) Buttons %%% 2) Menu Buttons %%% 3) Base Windows %%% 4) Menus %%% 5) Application Windows %%% %%% In Developing BTOL, we were aware of the standard lite API and %%% attempted to adhere to it in general, but did not feel BTOL had %%% to made 100% lite compatible. We feel it would require little %%% time to actually make it compatible and will do this if there is %%% enough user interest. %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolButton %%% %%% Purpose: To create a new button that conformed to our interface %%% %%% Useful methods: %%% %%% /new % label => instance %%% - creates a new instance of BtolButton %%% /resetcolors % - => - %%% - reset button colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /Activate % - => - %%% - allows button notify proc notification %%% /DeActivate % - => - %%% - Grays out button and disallow notification %%% /HiLite % - => - %%% - HiLite the button %%% /DeHiLite % - => - %%% - DeHilite the button %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolMenuButton %%% %%% Purpose: Create a button that can have a submenu off of it %%% %%% Useful methods: %%% %%% /new % Pullright label notifyproc ParentMenu width height => instance %%% - creates a new instance of BtolMenuButton %%% /movesubmenu % - => - %%% - moves the buttons submenu to its current x and y by mapping it %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolWindow %%% %%% Purpose: Create a window that has an array available for items that %%% will go into window as well as eventmgr. The items are %%% disposed of correctly when you destory the window %%% %%% Useful methods: %%% %%% /new % parentcanvas => instance %%% - creates a new instance of BtolWindow %%% /resetcolors % - => - %%% - reset button colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /hide % - => - %%% - If used from a BtolAppwin, allows the AppWin to hide all of %%% its children when it is deselected %%% /unhide % - => - %%% - If used from a BtolAppwin, allows the AppWin to show all of %%% its children when it is selected %%% /HiLiteFrame % - => - %%% - HiLite the window %%% /DeHiLiteFrame % - => - %%% - DeHilite the window %%% /CreateZapControl % - => - %%% - Creates a control in upper right of window to zap window %%% /CreateCloseControl % - => - %%% - Creates a control in upper left of window to close windows %%% /CreateResizeControl % - => - %%% - Creates resize controls at bottom of screen %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolMenu %%% %%% Purpose: Create a menu that has walking submenus and conforms to BTOL %%% UI %%% %%% Useful methods: %%% %%% /new % [menuitem names] [actions] => instance %%% - creates a new instance of BtolMenu %%% /resetcolors % - => - %%% - reset menu colors to specified defaults %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for menu %%% /dragmenu % - => - %%% - if this menu is a submenu it moves to parents right %%% /detach % - => - %%% - unmaps all submenus %%% /getcmi % - => BtolMenuButton %%% - get current menu item (Button that has its submenu showing) %%% /flipcmi % BtolMenuButton => - %%% - flip the state of current menu item %%% /setcmi % BtolMenuButton => - %%% - set the current menu item %%% /AutoSize % - => - %%% - after all the items are put in a menu run AutoSize to make %%% all the menu items and label fit nice. (Run before mapping) %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class: BtolAppWin %%% %%% Purpose: Create an application window with BTOL look and feel %%% %%% Useful methods: %%% %%% /new % Framelabel => instance -or- canvas => instance %%% - creates a new instance of BtolAppWindow %%% /newsubwin % Framelabel => subwindow %%% - create a subwindow for this application. It will automatically %%% open and close correctly, with the main AppWin %%% /sethue % hue => - %%% - set the hue for hsb value of button %%% /sethsb % color => - %%% - set the hsb color for button %%% /getappwin % - => BtolAppWin %%% - return the AppWindow whose menu is currently showing %%% /setappwin % BtolAppWin => - %%% - set the current AppWindow to be this AppWin %%% /destroychild % subwindow => - %%% - destroys a child subwindow %%% /destroychildren % [subwindows] => - %%% - destroys several child subwindows %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Class structure of BTOL %%% ----------------------- %%% %%% ------------ ------------- %%% |LiteWindow| |LabeledItem| %%% ------------ ------------- %%% | | %%% ------v----- -----v------ %%% |BtolWindow| |BtolButton| %%% ------------ ------------ %%% | | %%% _________|__________ | %%% | | | %%% -------v------- ---v------ ------v--------- %%% |BtolAppWindow| |BtolMenu|<-----|BtolMenuButton| %%% --------------- ---------- ---------------- %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Example -1- %%% %%% A trivial BTOL program. We let the Btol code do all the work. %%% /win framebuffer /new BtolAppWin send def %%% { %%% /PaintClient %%% { %%% 0 fillcanvas %%% 0 1 random 100 mul { random mul random 144 mul random random random setrgbcolor %%% moveto 240 100 lineto stroke } for %%% } def %%% reshapefromuser %%% totop %%% map %%% } win send %%% %%% psh Example -1- again and watch how the menus interact %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Example -2- %%% %%% A simple sample application written for BTOL %%% %%% /AppFont /Courier findfont def %%% /AppFontSize 18 def %%% %%% /changefontsize % dsize => - %%% { %%% /AppFontSize AppFontSize 3 -1 roll add 8 max store %%% %%% AppFont AppFontSize scalefont %%% /paint win send %%% } def %%% %%% %%% /changefont % fontname => - %%% { %%% /AppFont exch findfont store %%% 0 changefontsize %%% } def %%% %%% %%% /colormenu %%% [() dup dup dup dup dup dup dup dup dup] %%% [ {Hue /sethue /getappwin BtolAppWin send send} 9 { dup } repeat ] %%% /new BtolMenu send %%% dup /MenuItems get 0 1 9 %%% { dup 10 div /sethue 3 index 4 -1 roll get send } for pop %%% def %%% %%% /sizemenu %%% [(Enlarge by 2) (Enlarge by 10) (Reduce by 2) (Reduce by 10)] %%% [ { 2 changefontsize } { 10 changefontsize } { -2 changefontsize } { -10 changefontsize } ] /new BtolMenu send def %%% %%% /fontmenu %%% [ %%% (Courier) (Helvetica) (Times-Roman) %%% ] %%% [ { ItemLabel changefont } 2 index length 1 sub { dup } repeat ] /new BtolMenu send def %%% %%% /changefontmenu %%% [ (Font) (Size) ] %%% [ fontmenu sizemenu ] /new BtolMenu send def %%% %%% colormenu %%% /sethue %%% { %%% /Hue exch def %%% /HiLiteColor Hue 0.3 1 hsbcolor def %%% /ShadowColor Hue 1 0.45 hsbcolor def %%% /FaceColor Hue 0.4 .9 hsbcolor def %%% %%% HiLiteFrame %%% paint %%% } %%% put %%% %%% /mainmenu %%% [(Window Color) (Change Font) (Hide) (Quit)] %%% [ %%% colormenu %%% changefontmenu %%% { /flipiconic /getappwin BtolAppWin send send } %%% { /ZapNotify /getappwin BtolAppWin send send } %%% ] /new BtolMenu send def %%% %%% { %%% /FrameLabel (Example #2) def %%% AutoSize %%% } mainmenu send %%% %%% %%% /win framebuffer /new BtolAppWin send def %%% { %%% CreateCloseControl %%% CreateResizeControl %%% /FrameMenu mainmenu def %%% /FrameLabel (A BTOL window! Example #2) def %%% /IconLabel (Example #2) def %%% /PaintClient %%% { %%% gsave %%% 0 fillcanvas %%% 0 1 random 100 mul %%% { %%% random mul random 144 mul %%% random random random setrgbcolor %%% moveto 240 100 lineto stroke %%% } for %%% AppFont AppFontSize scalefont setfont %%% 50 50 moveto (BTOL - it just looks better!) show %%% grestore %%% } def %%% reshapefromuser %%% ClientCanvas /Retained true put %%% totop %%% map %%% } win send %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% Have fun with the sample code and please let us know how you like %%% the product. %%% - Dave, Dave and Peter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% version dup (1.1) eq { systemdict /LabeledItem known not { ($NEWSHOME/lib/NeWS/liteitem.ps) run } if } { systemdict /LabeledItem known not { ($OPENWINHOME/etc/NeWS/liteitem.ps) run } if } ifelse systemdict begin % ============================= Btol Button Item ============================= /BtolButton LabeledItem dictbegin /Activated? true def /Hue 0 def /ShadowColor .1 .1 .1 rgbcolor def /HiLiteColor .9 .9 .9 rgbcolor def /FaceColor .7 .7 .7 rgbcolor def /CurrentTextColor ShadowColor def dictend classbegin /new % label notifyproc parentcanvas => instance { % fake a labeled item. dup type /canvastype eq {() /Center 4 2 roll} {() /Center 6 2 roll} ifelse /new super send begin /ItemRadius 0 def /ItemFrame 2 def /ItemBorder null def % /ItemID 0 def %%%DZpatch -- used in dock currentdict end } def /resetcolors { /ShadowColor .1 .1 .1 rgbcolor store /HiLiteColor .9 .9 .9 rgbcolor store /FaceColor .7 .7 .7 rgbcolor store } def /sethue % hue { /Hue exch def /HiLiteColor Hue 0.3 1 hsbcolor def /ShadowColor Hue 1 0.45 hsbcolor def /FaceColor Hue 0.4 .9 hsbcolor def } def /sethsb % color -> - { /FaceColor exch def } def /reshape % x y w h => - { /ItemHeight exch def /ItemWidth exch def LabelSize /LabelHeight exch def /LabelWidth exch def ItemBorder null eq {/ItemBorder ItemFrame def} if /ItemWidth ItemWidth ItemBorder ItemGap add 2 mul LabelWidth add max def /ItemHeight ItemHeight ItemBorder ItemGap add 2 mul LabelHeight add max def /LabelX ItemWidth LabelWidth sub 2 div LabelX add def /LabelY ItemHeight LabelHeight sub 2 div LabelY add def ItemLabel type /stringtype eq { % adjust for descenders /LabelY LabelY ItemLabelFont fontdescent 2 div sub ItemBorder max def } if ItemRadius 0 gt ItemRadius .5 le and { /ItemRadius ItemWidth ItemHeight min ItemRadius mul def } if ItemWidth ItemHeight /reshape super send } def /PaintItem { ItemValue true eq {HiLightButton} {PaintButton} ifelse } def /SetButtonValue % bool => - { /ItemValue exch store ItemValue ItemPaintedValue ne {/paint self send} if } def /ClientDown { Activated? {true SetButtonValue} if } def /ClientUp { Activated? { ItemValue {NotifyUser} if false SetButtonValue StopItem } if } def /ClientEnter {Activated? {true SetButtonValue} if} def /ClientExit {Activated? {false SetButtonValue} if } def /Activate { /CurrentTextColor ShadowColor store /Activated? true def paint } def /DeActivate { gsave /CurrentTextColor FaceColor setcolor currenthsbcolor .2 sub hsbcolor def /Activated? false def paint grestore } def /HiLite { /State true store paint } def /DeHiLite { /State false store paint } def /HiLightButton { gsave HiLiteColor setcolor 0 0 ItemWidth ItemHeight rectpath fill HiLiteColor PaintShadow ShadowColor PaintHiLite HiLiteColor PaintFace ItemFrame dup neg translate PaintLabel grestore } def /PaintButton { gsave FaceColor setcolor 0 0 ItemWidth ItemHeight rectpath fill ShadowColor PaintShadow HiLiteColor PaintHiLite FaceColor PaintFace PaintLabel grestore } def /PaintFace % FaceColor => - { setcolor ItemFrame 0 0 ItemWidth ItemHeight insetrect rectpath fill } def /PaintShadow % ShadowColor => - { setcolor 0 0 moveto ItemFrame ItemFrame rlineto ItemWidth ItemFrame 2 mul sub 0 rlineto 0 ItemHeight ItemFrame 2 mul sub rlineto ItemFrame ItemFrame rlineto 0 ItemHeight neg rlineto fill } def /PaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 ItemHeight rlineto ItemWidth 0 rlineto ItemFrame neg dup rlineto ItemWidth ItemFrame 2 mul sub neg 0 rlineto 0 ItemHeight ItemFrame 2 mul sub neg rlineto fill } def /PaintLabel { CurrentTextColor setcolor ItemLabelFont setfont ItemWidth 2 div ItemHeight ItemLabelFont fontheight ItemLabelFont fontdescent sub sub 2 div moveto ItemLabel cshow } def classend def pause pause % =============================BtolMenuButton Item============================= /BtolMenuButton BtolButton dictbegin /State false def /ParentMenu null def /PullRight? false def /ArrowSize 0 def /SubMenu null def dictend classbegin /new % Pullright label notifyproc ParentMenu width height => instance { 2 index /ClientCanvas get 3 1 roll 4 -1 roll 7 1 roll /new super send begin /ItemValue false def /ArrowSize ItemLabelFont fontheight 2 mul 3 div def /PullRight? exch def /ParentMenu exch def 0 0 move PullRight? { /ItemWidth ItemWidth ArrowSize 1.5 mul add def 0 0 ItemWidth ItemHeight reshape } if currentdict end } def /AutoSize % - => - { gsave ItemLabelFont setfont /ItemWidth ItemLabel stringwidth pop ItemLabelFont fontheight add def /ArrowSize ItemLabelFont fontheight 2 mul 3 div def 0 0 move PullRight? { /ItemWidth ItemWidth ArrowSize 1.5 mul add def } if 0 0 ItemWidth ItemHeight reshape grestore } def /movesubmenu { SubMenu null ne ItemValue true eq and { /map SubMenu send } if } def /resetcolors { /resetcolors super send paint PullRight? { /resetcolors SubMenu send } if } def /sethue % hue => - { dup /sethue super send paint PullRight? { /sethue SubMenu send } { pop } ifelse } def /unmap { SubMenu null ne { /unmap SubMenu send } if } def /ZapNotify { SubMenu null ne { /ZapNotify SubMenu send } if } def /destroy { ZapNotify } def /PaintItem { %State true eq PullRight? and { /paint SubMenu send } if ItemValue true eq State true eq or {HiLightButton} {PaintButton} ifelse gsave PullRight? { ItemValue true eq State true eq or { ItemFrame dup neg translate } if ShadowColor setcolor ItemWidth ArrowSize 1.5 mul sub ItemHeight 2 div translate 0 ArrowSize 2 div neg moveto 0 ArrowSize 2 div lineto .866 ArrowSize mul 0 lineto stroke HiLiteColor setcolor .866 ArrowSize mul 0 moveto 0 ArrowSize 2 div neg lineto stroke } if grestore } def /PaintLabel { CurrentTextColor setcolor ItemLabelFont setfont 10 ItemHeight ItemLabelFont fontheight ItemLabelFont fontdescent sub sub 2 div moveto ItemLabel show } def classend def pause pause /BtolWindow LiteWindow dictbegin /items null def /itemmgr null def /IsUp? false def /ControlInterests null def /ControlMgr null def /FrameTextColor 0 0 0 rgbcolor def /MenuLabel () def /BorderWidth 0 def /BorderLeft 1 def /BorderBottom 1 def /BorderRight 1 def /BorderTop 0 def /ControlSize 0 def /ControlFrame 2 def /IconFrame 2 def /ShadowColor .1 .1 .1 rgbcolor def /HiLiteColor .9 .9 .9 rgbcolor def /FaceColor .7 .7 .7 rgbcolor def /Resizable? false def /Closable? false def /Zappable? false def dictend classbegin /new % parentcanvas => window { /new super send begin /ClientMenu null def /ControlInterests 15 dict store /FrameFillColor FaceColor def /FrameTextColor ShadowColor def /FrameFont /Times-Roman findfont 18 scalefont def /BorderTop FrameFont fontheight 1.5 mul store /ControlSize FrameFont fontheight store /IconFont /Helvetica findfont 10 scalefont def currentdict end } def /map { /IsUp? true def /map super send } def /unmap { /IsUp? false def /unmap super send } def /unhide { IsUp? { /map super send } if } def /hide { IsUp? { /unmap super send } if } def /resetcolors { /ShadowColor .1 .1 .1 rgbcolor store /HiLiteColor .9 .9 .9 rgbcolor store /FaceColor .7 .7 .7 rgbcolor store } def /sethue % hue { /Hue exch def /HiLiteColor Hue 0.3 1 hsbcolor def /ShadowColor Hue 1 0.45 hsbcolor def /FaceColor Hue 0.4 .9 hsbcolor def /FrameFillColor FaceColor def /FrameTextColor ShadowColor def } def /ZapNotify { ClientCanvas /Retained false put FrameCanvas /Retained false put ClientCanvas 0 0 0 0 rectpath reshapecanvas FrameCanvas 0 0 0 0 rectpath reshapecanvas FrameEventMgr null ne { FrameEventMgr killprocess } if itemmgr null ne {itemmgr killprocess} if ControlMgr null ne { ControlMgr killprocess } if currentdict /ZapControl undef currentdict /CloseControl undef currentdict /LeftStretchControl undef currentdict /MiddleStretchControl undef currentdict /RightStretchControl undef currentdict /ControlMgr undef currentdict /FrameEventMgr undef currentdict /ClientCanvas undef currentdict /FrameCanvas undef currentdict /ControlInterests undef currentdict /FrameInterests undef currentdict /items undef } def /CloseNotify { flipiconic } def /destroy { ZapNotify } def /PaintFrame % { PaintFrameBorder 0 FrameHeight BorderTop sub 1 add FrameWidth 1 sub BorderTop 1 sub rectpath gsave FrameFillColor setcolor fill grestore FrameTextColor setcolor stroke PaintFrameControls PaintFrameLabel } def /HiLiteFrame { /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def paintframe } def /DeHiLiteFrame { /FrameFillColor FaceColor def /FrameTextColor ShadowColor def paintframe } def /IconPaintFace % FaceColor => - { setcolor IconFrame 0 0 IconWidth IconHeight insetrect rectpath fill } def /IconPaintShadow % ShadowColor => - { setcolor 0 0 moveto IconFrame dup rlineto IconWidth IconFrame 2 mul sub 0 rlineto 0 IconHeight IconFrame 2 mul sub rlineto IconFrame dup rlineto 0 IconHeight neg rlineto fill pause } def /IconPaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 IconHeight rlineto IconWidth 0 rlineto IconFrame neg dup rlineto IconWidth IconFrame 2 mul sub neg 0 rlineto 0 IconHeight IconFrame 2 mul sub neg rlineto fill pause } def /PaintIconLabel { IconFont setfont 0 IconHeight IconFont fontheight 1.5 mul sub IconWidth IconFont fontheight 1.5 mul rectpath ShadowColor setcolor fill HiLiteColor setcolor IconWidth 2 div IconHeight IconFont fontheight sub moveto IconLabel cshow pause } def /PaintIcon { gsave IconCanvas setcanvas FaceColor fillcanvas IconImage null ne { 0 0 moveto IconImage showicon } if IconLabel null ne { PaintIconLabel } if HiLiteColor IconPaintHiLite ShadowColor IconPaintShadow grestore } def /CreateFrameInterests % - => - (Create frame control interests) { FrameInterests begin /FrameTopEvent PointButton /totop DownTransition FrameCanvas eventmgrinterest def /FrameMoveEvent AdjustButton /slide DownTransition FrameCanvas eventmgrinterest def /FrameMenuEvent MenuButton {} DownTransition FrameCanvas eventmgrinterest def /FrameDamageEvent /Damaged /FixFrame null FrameCanvas eventmgrinterest def /FrameEnterEvent /EnterEvent /EnterFrame [0 2] FrameCanvas eventmgrinterest def /FrameExitEvent /ExitEvent /ExitFrame [0 2] FrameCanvas eventmgrinterest def /FrameDoItEvent /DoItEvent {gsave /ClientData get cvx exec grestore} /Window null eventmgrinterest def /FrameIconicFcnKeyEvent /WindowFunction /flipiconic /FlipIconic FrameCanvas eventmgrinterest def /FrameFrontFcnKeyEvent /WindowFunction /totop /FlipFront FrameCanvas eventmgrinterest def /IconMenuEvent {} def end } def pause /CreateCloseControl { gsave FrameCanvas setcanvas /CloseControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /Closable? true def ControlInterests begin /FrameCloseEvent PointButton /CloseNotify DownTransition CloseControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 ControlSize dup rectpath CloseControl reshapecanvas grestore } def /CreateZapControl { gsave FrameCanvas setcanvas /ZapControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /Zappable? true def ControlInterests begin /FrameZapEvent PointButton /destroy DownTransition ZapControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 ControlSize dup rectpath ZapControl reshapecanvas grestore } def /CreateResizeControl { gsave /Resizable? true def /BorderBottom FrameFont fontheight 2 div 10 max def FrameCanvas setcanvas ShapeClientCanvas /LeftStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /MiddleStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def /RightStretchControl FrameCanvas newcanvas dup begin /Mapped true def /EventsConsumed /AllEvents def end def ControlInterests begin /FrameLeftStretchEvent PointButton {totop stretchcorner} DownTransition LeftStretchControl eventmgrinterest def /FrameMiddleStretchEvent PointButton {totop stretchwindowedge} DownTransition MiddleStretchControl eventmgrinterest def /FrameRightStretchEvent PointButton {totop stretchcorner} DownTransition RightStretchControl eventmgrinterest def end ControlMgr null ne {ControlMgr killprocess} if /ControlMgr ControlInterests forkeventmgr store 0 0 15 BorderBottom rectpath LeftStretchControl reshapecanvas 0 0 FrameWidth 30 sub BorderBottom rectpath MiddleStretchControl reshapecanvas 0 0 15 BorderBottom rectpath RightStretchControl reshapecanvas grestore } def /CreateIconInterests % - => - (Create icon control interests) { FrameInterests begin /IconOpenEvent PointButton /flipiconic DownTransition IconCanvas eventmgrinterest def /IconMoveEvent AdjustButton /slide DownTransition IconCanvas eventmgrinterest def /IconMenuEvent {} def /IconDamageEvent /Damaged /FixIcon null IconCanvas eventmgrinterest def /IconIconicFcnKeyEvent /WindowFunction /flipiconic /FlipIconic IconCanvas eventmgrinterest def /IconFrontFcnKeyEvent /WindowFunction /totop /FlipFront IconCanvas eventmgrinterest def end } def /CreateFrameControls % - => - (Create frame control canvases/items) { } def /CreateFrameCanvas % - => - (Create empty frame canvas) { /FrameCanvas ParentCanvas newcanvas def /ptr /ptr_m FrameCanvas setstandardcursor } def /CreateFrameMenu { } def /CreateIconMenu { } def /MoveFrameControls % - => - ([Re]set frame control shapes) { gsave Closable? { CloseControl setcanvas ControlFrame FrameHeight BorderTop sub BorderTop ControlSize sub 2 div add movecanvas } if Zappable? { ZapControl setcanvas FrameWidth ControlSize ControlFrame add sub FrameHeight BorderTop sub BorderTop ControlSize sub 2 div add movecanvas } if Resizable? { LeftStretchControl setcanvas 0 0 movecanvas FrameCanvas setcanvas 0 0 FrameWidth 30 sub BorderBottom rectpath MiddleStretchControl reshapecanvas MiddleStretchControl setcanvas 15 0 movecanvas RightStretchControl setcanvas FrameWidth 15 sub 0 movecanvas } if grestore } def /PaintFrameBorder { % - => - (Paint frame border areas) ShadowColor strokecanvas } def /PaintFocus { } def /PaintFrameLabel { gsave FrameTextColor setcolor FrameFont setfont FrameWidth 2 div FrameHeight FrameFont fontheight sub moveto FrameLabel cshow grestore } def /ControlPaintFace % FaceColor => - { setcolor ControlFrame 0 0 ControlSize dup insetrect rectpath fill } def /ControlPaintShadow % ShadowColor => - { setcolor 0 0 moveto ControlFrame dup rlineto ControlSize ControlFrame 2 mul sub 0 rlineto 0 ControlSize ControlFrame 2 mul sub rlineto ControlFrame dup rlineto 0 ControlSize neg rlineto fill } def pause /ControlPaintHiLite % HiLiteColor => - { setcolor 0 0 moveto 0 ControlSize rlineto ControlSize 0 rlineto ControlFrame neg dup rlineto ControlSize ControlFrame 2 mul sub neg 0 rlineto 0 ControlSize ControlFrame 2 mul sub neg rlineto fill } def /PaintFrameControls { gsave Closable? { CloseControl setcanvas FaceColor setcolor clippath fill ShadowColor ControlPaintShadow HiLiteColor ControlPaintHiLite FaceColor ControlPaintFace ShadowColor setcolor ControlFrame dup 2 div add 0 0 ControlSize dup insetrect rectpath fill FaceColor setcolor ControlFrame dup add 0 0 ControlSize dup ControlFrame sub insetrect rectpath fill } if Zappable? { ZapControl setcanvas FaceColor setcolor clippath fill ShadowColor ControlPaintShadow HiLiteColor ControlPaintHiLite FaceColor ControlPaintFace ShadowColor setcolor 2 { ControlFrame dup add dup moveto ControlSize ControlFrame dup add sub dup lineto ControlFrame dup add ControlSize ControlFrame dup add sub moveto ControlSize ControlFrame dup add sub ControlFrame dup add lineto stroke -1 0 translate } repeat } if Resizable? { LeftStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas MiddleStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas RightStretchControl setcanvas FaceColor fillcanvas ShadowColor strokecanvas } if grestore } def /reshape { /reshape super send MoveFrameControls } def classend def pause pause /BtolMenu BtolWindow dictbegin /CMI null def /MenuActions null def /MenuChoices null def /MenuItemFont /Helvetica findfont 14 scalefont def /MenuLabelFont /Helvetica-Bold findfont 14 scalefont def /MenuItems [] def /MenuItemsEM null def /ParentMenu null def /Pinned? false def dictend classbegin /new % [menu items names] [actions] => window { framebuffer /new super send begin /MenuActions exch store /MenuChoices exch store /FrameFont MenuLabelFont def /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def /BorderWidth 0 def /BorderLeft 0 def /BorderRight 0 def /BorderBottom 0 def /BorderTop MenuLabelFont fontheight 10 add def 0 100 1 1 reshape CreateZapControl 0 0 1 1 rectpath ZapControl reshapecanvas ClientCanvas /Retained true put MakeMenuItems currentdict end } def /dragmenu { ParentMenu null ne { gsave framebuffer setcanvas ParentMenu /FrameCanvas get getcanvaslocation ParentMenu begin FrameHeight add exch FrameWidth add exch end FrameHeight sub move grestore } if } def /move { /move super send CMI null ne { pause /dragmenu CMI /SubMenu get send } if } def /slide { { GetCanvas setcanvas InteractionLock { 20 dict begin /absmove { gsave %Canvas setcanvas [1 0 0 1 0 0] setmatrix yo add exch xo add exch move grestore pause } def gsave initmatrix /Canvas currentcanvas def currentcursorlocation /yo exch neg def /xo exch neg def clippath pathbbox /height exch def /width exch def pop pop Canvas parentcanvas createoverlay setcanvas 0 0 { absmove newpath } getanimated waitprocess aload pop absmove grestore end } monitor ParentMenu null ne Pinned? not and {detach} if } fork pop } def /map { MenuItems { /SubMenu get dup null ne { {Pinned? {map} if } exch send } { pop } ifelse } forall CMI null ne { /map CMI /SubMenu get send } if /map super send } def /unmap { /unmap super send CMI null ne { /unmap CMI /SubMenu get send } if MenuItems { /SubMenu get dup null ne { {Pinned? {unmap} if } exch send } { pop } ifelse } forall } def /totop { MenuItems { /SubMenu get dup null ne { {Pinned? {totop} if } exch send } { pop } ifelse } forall CMI null ne { /totop CMI /SubMenu get send } if /totop super send } def /unmapsubmenus % - => - { CMI null ne { /unmapsubmenus CMI /SubMenu get send } if unmap } def /resetcolors { /resetcolors super send HiLiteFrame MenuItems { /resetcolors exch send } forall } def /sethue % hue { dup /sethue super send HiLiteFrame MenuItems { 1 index /sethue 3 -1 roll send } forall pop } def /flipcmi % BtolMenuButton => - { dup CMI eq { dup /State get { pop null setcmi } { setcmi } ifelse } { setcmi } ifelse } def /setcmi % BtolMenuButton => - %%% cmi(Current Menu Item) { CMI null ne { /DeHiLite CMI send /unmapsubmenus CMI /SubMenu get send } if /CMI exch store CMI null ne { CMI /SubMenu get /Pinned? get { /CMI null store } { /HiLite CMI send {AutoSize totop dragmenu map} CMI /SubMenu get send } ifelse } if } def /getcmi % - => BtolMenuButton { CMI } def /detach { Pinned? not { /Pinned? true store 0 0 ControlSize dup rectpath ZapControl reshapecanvas MoveFrameControls PaintFrameControls } if {CMI null ne {/DeHiLite CMI send /CMI null def} if} ParentMenu send } def /ReshapeMenuItems % - => - { /tmp MenuItems 0 get /ItemHeight get def 0 1 MenuItems length 1 sub { 1 FrameHeight BorderTop sub tmp 1 add 3 index 1 add mul sub FrameWidth 2 sub tmp /reshape MenuItems 7 -1 roll get send } for } def /AutoSize % called after any change to the frame label or font { gsave FrameFont setfont /FrameWidth FrameLabel ( ) append stringwidth pop ControlSize 2 add dup add add def grestore MenuItems { /FrameWidth exch /ItemWidth get FrameWidth max store pause } forall /FrameWidth FrameWidth 2 add def /FrameHeight MenuItems length MenuItems 0 get /ItemHeight get 1 add mul BorderTop add def FrameX FrameY FrameWidth FrameHeight reshape ReshapeMenuItems } def /MakeMenuItems % - => - { /MenuItems [ 0 1 MenuChoices length 1 sub { MenuActions 1 index get type /dicttype eq { MenuChoices self MenuActions 3 index get begin /ParentMenu exch def /FrameLabel exch 2 index get def end true MenuChoices 2 index get { self /flipcmi ParentMenu send } self 0 0 /new BtolMenuButton send dup begin /SubMenu MenuActions 4 -1 roll get def /ItemLabelFont MenuItemFont def end /AutoSize 1 index send } { false MenuChoices 2 index get MenuActions 4 -1 roll get self 0 0 /new BtolMenuButton send dup begin /ItemLabelFont MenuItemFont def end } ifelse 0 0 /move 3 index send pause } for ] def /MenuItemsEM MenuItems forkitems def AutoSize } def /PaintClient { FaceColor fillcanvas MenuItems paintitems } def /CreateFrameInterests { % - => - (Create frame control interests) FrameInterests begin /FrameTopEvent PointButton /totop DownTransition FrameCanvas eventmgrinterest def /FrameMoveEvent AdjustButton /slide DownTransition FrameCanvas eventmgrinterest def /FrameDamageEvent /Damaged /FixFrame null FrameCanvas eventmgrinterest def end } def /ZapNotify { MenuItems {/ZapNotify exch send} forall MenuItemsEM null ne { MenuItemsEM killprocess } if /ZapNotify super send currentdict /MenuItems undef currentdict /ParentMenu undef currentdict /CMI undef } def /destroy { Pinned? { unmap 0 0 1 1 rectpath ZapControl reshapecanvas /Pinned? false store } { ZapNotify } ifelse } def /CreateFrameMenu {} def /flipiconic {} def classend def pause pause /BtolAppWin BtolWindow dictbegin /Childern null def dictend classbegin /AppWindow null def /TmpAppWin null def /new % label => instance { dup type /stringtype eq {framebuffer} {() exch} ifelse /new super send begin /FrameLabel exch def /IconLabel FrameLabel def /FrameMenu [(Info ...) (Hide) (Quit)] [ {} { /flipiconic /getappwin BtolAppWin send send } { /ZapNotify /getappwin BtolAppWin send send } ] /new BtolMenu send def FrameMenu /FrameLabel FrameLabel put /AutoSize FrameMenu send /PaintClient { FaceColor fillcanvas } def FrameX FrameY 1 1 reshape CreateZapControl currentdict AppWindow null ne { /totop AppWindow send } if /Children [] def end } def /newsubwin { framebuffer /new BtolWindow send dup dup /Children Children dup length 1 add 4 -1 roll arrayinsert def self exch begin /ParentApp exch def /FrameLabel 3 -1 roll def ParentApp begin ShadowColor FaceColor HiLiteColor end /HiLiteColor exch def /FaceColor exch def /ShadowColor exch def /IconLabel FrameLabel def /FrameFillColor ShadowColor def /FrameTextColor HiLiteColor def /PaintClient { FaceColor fillcanvas } def /totop { ParentApp /FrameMenu get /FrameCanvas get /CanvasAbove get null ne ParentApp /FrameMenu get /FrameCanvas get /CanvasBelow get FrameCanvas ne or { ParentApp /setappwin ParentApp send /totop super send /totop ParentApp /FrameMenu get send } if } def /destroy { /unmap self send } def FrameX FrameY 1 1 reshape end } def /flipiconic { /unmap self send /Iconic? Iconic? not def IconX null eq { FrameX FrameY FrameHeight add IconHeight sub /move self send } if ZoomProc /map self send Iconic? not { self setappwin /totop FrameMenu send /map FrameMenu send } { /unmap FrameMenu send } ifelse } def /map { Iconic? not { Children { /unhide exch send } forall } if /map super send } def /unmap { Iconic? not { Children { /hide exch send } forall } if /unmap super send } def /paint % { AppWindow self eq %FrameMenu /FrameCanvas get /Mapped get { /paint FrameMenu send } if /paint super send } def /totop % - => - { self setappwin FrameMenu /FrameCanvas get /CanvasAbove get null ne FrameMenu /FrameCanvas get /CanvasBelow get FrameCanvas ne or { /totop super send /totop FrameMenu send } if } def /resetcolors { /resetcolors super send FrameMenu null ne { /resetcolors FrameMenu send /paint FrameMenu send } if } def /sethue % hue => - { dup /sethue super send FrameMenu null ne { /sethue FrameMenu send } { pop } ifelse AppWindow self eq { HiLiteFrame painticon } if } def /getappwin % - => CurrentAppWindow { AppWindow } def /setappwin % BtolAppWin => - { /TmpAppWin exch store AppWindow TmpAppWin ne { AppWindow null ne { { /unmap FrameMenu send DeHiLiteFrame } AppWindow send } if /AppWindow TmpAppWin store AppWindow null ne { { /map FrameMenu send HiLiteFrame } AppWindow send } if } if } def /setmenu % BtolMenu => - { } def /ZapNotify { /ZapNotify FrameMenu send Children { /ZapNotify exch send } forall self getappwin eq {/AppWindow null store} if /ZapNotify super send } def /destroy { ZapNotify } def /arrayindex % array value => index true | false { 2 dict begin /i 0 def /v exch def false exch { /v load eq {pop i true exit} {/i i 1 add def} ifelse } forall currentdict /v undef currentdict /i undef end } def /destroychild % BtolWin => - { dup Children exch arrayindex { /Children Children 3 -1 roll arraydelete store /ZapNotify exch send } { pop console (Not a child of win\n) [] fprintf } ifelse } def /destroychildren % [BtolWin] => - { { dup Children exch arrayindex { /Children Children 3 -1 roll arraydelete store /ZapNotify exch send } { pop console (Not a child of win\n) [] fprintf } ifelse } forall } def /DeHiLiteFrame { Children { /DeHiLiteFrame exch send } forall /DeHiLiteFrame super send } def /HiLiteFrame { Children { /HiLiteFrame exch send } forall /HiLiteFrame super send } def classend def pause pause end From don Thu Dec 21 22:40:14 1989 Date: Thu, 21 Dec 89 22:40:14 -0500 To: NeWS-makers@brillig.umd.edu Subject: Open Windows From: korp@tripoli.ees.anl.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) One of the many bugs listed in the developers release of Open Windows is the fact that the NeWS side is not device independent! Sun has done a lot of things wrong in attempting to promote NeWS but taking the device independence out of PostScript has to rank among the big ones. One of the major reasons we develop under NeWS was the fact that PostScript was device independent. Sun does not consider this a very important bug according to the ratings in the bug report. How can this be? Could someone please enlighten me about why this was done or if it will change any time soon? Peter korp@athens.ees.anl.gov Argonne National Laboratory From don Thu Dec 21 22:47:06 1989 Date: Thu, 21 Dec 89 22:47:06 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: cs.utexas.edu!sun-barr!newstop!texsun!texbell!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <18637@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: > There is simply no use comparing something like stdio with a a > graphical user interface. There are two "tricks" behind stdio: 1) > let's imagine that files are just bytestreams and 2) the printf vararg > hack. So what sort of "tricks" do we need to solve the window programming problem? > These are nice tricks to be sure, but are something of an > overabstraction. How many times have you seen the query, "how do you > read a single character from the terminal" in comp.lang.c? And I'd expect that in a real high-level windowing environment you'll get the same sort of question. And the same sort of answer: "You don't do that". In the case of C, you use curses. Stdio is the wrong tool for hacking with the screen. It's too high a level of abstraction. In the case of windowing, you design the user interface at a higher level of abstraction. But don't force the whole program into that mould. > Hmmm. Let's see if we can find a simple abstraction for windowing... I don't know either. But I think it's a much more important problem than deciding what windows should look like. The examples I gave were deliberately simple... > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); > Looking kinda like a widget call isn't it? Maybe. But you don't want to design your program around the UI, like you have to with widgets. > Good points all. That is why I like to download all of my UI code > into the server and interface to it using stubs crafted to the > specific functionality of the interface. Looked at NeWS's "cps" yet? Yeh, it's a nice metaphor. I'm not sure it's the best one for today's systems, though. It's got quite a bit of overhead, and you're not going to be able to cram much of a postscript interpreter into 640K if you need your apps in there as well... > > Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's > > way too low level for something like this. > Mon ami, have you REALLY looked at the X widget interface? Nobody is > suggesting you write an interface using Xlib. The interface is not so bad. You still have to design the whole program around it, though, or you'll end up pissing off users who want to work instead of wait. That level of abstraction belongs in the server. Not the program. No matter how it's hidden. Here we have my "desirable" example: > > "I want a window big enough to hold the following > > objects: a text pane containing this text, and a > > selector for YES and NO. Tell me when someone selects > > YES or NO, and don't bug me otherwise", This stuff here was my "undesirable" example. Of course this is what systems like X give you. They hide it, but your program still has to be able to get back to the user or none of this will happen: > > "Draw a rectangle here, now put these characters in > > this font here, and then draw these rectangles... > > (lots deleted) now tell me when anyone clicks in my > > window. Oh, OK, erase this rectangle and redraw it > > here, and blit this rectangle up by the size of this > > font, put these characters here, and tell me what > > you want me to do next..." > There is a minimum complexity to a windowing interface unless you > accept that some of the inherent capabilities of the device will be > unaccessable. I accept that some inherent capabilities of the device will be unacessible at this level of abstraction. Similarly, most of the hardware UNIX runs on is quite capable of, oh, lightweight processes, asynchronous I/O, real time response, and so on. But people are wiling to give all this up so they can use a higher-level metaphor. Your argument here is beginning to sound like the ones advanced by PCware programmers who NEED to get to the raw hardware. Remember, form liberates. > Yes, simplifying models are quite useful, but they are > not always appropriate to the task at hand. This is why an > object-oriented interfacing approach is a Good Thing. But it makes your programs huge. The program itself should have as little of the user interface as possible as an integral part of itself. If you need to go to a lower level, do it. But first make the easy things easy. "Hello World" in a windowing system shouldn't be more than 10 lines of code. Oh, and yes. I would LOVE to play around with Display Postscript. But it's never going to show up in today's PCs, and the way things are going it's gonna be a long time before it'll show up in any. Standards aren't just for the elite. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Fri Dec 22 08:41:39 1989 Date: Fri, 22 Dec 89 08:41:39 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Must I have SunOS 4.0.3 for OpenWindows ?? From: laukee%canon.uucp@NSFnet-Relay.AC.UK Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Can I get by with SunOS 4.0.1 ?? We have it running under 4.0, 4.0.1 and 4.0.3c... which begs the question "why don't we upgrade?" Answers in 15 words or less on a postcard... -------- Canon Research Centre Europe, 19/20 Frederick Sanger Rd, Surrey Research Park, Guildford, Surrey, GU25YD, UK. NRS: laukee@uk.co.canon, ARPA: laukee%canon@nsfnet-relay.ac.uk UUCP: laukee@canon.uucp, PATH: ..!mcvax!ukc!uos-ee!canon!laukee Tel: +44 (0) 483 574325 Fax: +44 (0) 483 574360 From don Fri Dec 22 16:37:56 1989 Date: Fri, 22 Dec 89 16:37:56 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows From: fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Inre the message: > >One of the many bugs listed in the developers release of Open Windows is >the fact that the NeWS side is not device independent! Sun has done a lot of >things wrong in attempting to promote NeWS but taking the device independence >out of PostScript has to rank among the big ones. One of the major reasons >we develop under NeWS was the fact that PostScript was device independent. >Sun does not consider this a very important bug according to the ratings in >the bug report. How can this be? Could someone please enlighten me about >why this was done or if it will change any time soon? > > > Peter > korp@athens.ees.anl.gov > Argonne National Laboratory > The answer is somewhat simple: it's rather difficult to scale everything appropriately to handle differing device densities if your have no way of determining those densities. As most (though certainly not all) monitors do not have any provisio for providing this information to the framebuffer (and most framebuffers wouldnt know what to do with it anyway), certain assumptions have to be made about the attached devices in advance. In our shop, we regularly swap 16 and 19 inch color monitors around. On a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 inch monitor has a higher density of pixels per unit measure in either dimension than the 19 inch. The basic unit of measure in PostScript is the point, 1/72 of an inch; not too metric, to be sure, but having a basis in the printing industry. If the PostScript (or NeWS) programmer knows, or can query, the density of the device to be driven, s/he can transform everything accordingly, so that the same PS source prints to the same result on a 300 or 900 dpi printer. The higher density printer then simply provides just that. If the programmer can neither know in advance, nor find out a run-time by query the density of the output device, however, s/he faces a quandry. There is no real way, short of modifying the hardware, to solve the problem in a device independent way; so the NeWS programmers took the approach of changing the abstraction somewhat, from representing a point as a fixed measure, to representing it as a pixel. This is *not* truely device independent, but it does mean I can scale my output on the basis of frame- buffer resolution, which at least is something. At least NeWS attempts to make some sort of abstraction; under X, you must handle the abstraction yourself. Which is the better approach? Whatever works, I suppose. The only way this situation will change, though, is for the window server to take advantage of the newer hardware that does provide density information, so that the programmer can work at the same level of abstraction s/he uses with a PostScript printer. Whew, maybe it wasnt that simple an answer! I hope it helps. Tom Dockery, Market Focus Technologies sun!suntan!fajita!doc From don Fri Dec 22 16:40:43 1989 Date: Fri, 22 Dec 89 16:40:43 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I added comp.windows.misc to the discussion. In article <7391@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >In article <18637@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: >> Yes, simplifying models are quite useful, but they are >> not always appropriate to the task at hand. This is why an >> object-oriented interfacing approach is a Good Thing. >But it makes your programs huge. The program itself should have as >little of the user interface as possible as an integral part of itself. I think there is a major difference of perspective here. Some people want environments that let them *build tools* as fast as possible If you can build the basic tool in a few hours, who cares if it's portable? Others want the *tools* to be as fast (and small) as possible. The target market is different, i.e. PC's vs. Workstations. I don't thing the two problems can have have one solution in the near term. Unless you make a PC like a workstation, with all of the extra costs, etc. Another solution Peter is looking for is something more portable than X. >If you need to go to a lower level, do it. But first make the easy things >easy. "Hello World" in a windowing system shouldn't be more than 10 >lines of code. Window systems have evolved so much in the last 10 years. However it is still changing. SunWindows failed the Hello World test. SunView is a better job. Xlib also failed, but the X intrinsics fixes that. (See David Rosenthal's paper in core.src/doc/HelloWorld). Window systems evolve. Tool kits get better. >Oh, and yes. I would LOVE to play around with Display Postscript. But it's >never going to show up in today's PCs, and the way things are going it's >gonna be a long time before it'll show up in any. >Standards aren't just for the elite. The problem the PC's users are facing is evolution. Remember when some "expert" said that 64K was enough for any application? The future PC will be a 486 with 4 Megs of memory for under $1000. You'll see X and NeWS on PC's once some vendor ships Unix V.4. I know there is no standard User Interface or library. But there is a lot more that is not standard. What about the imaging model? Bitmaps are not going to be the model used in the future. Already everyone is talking about outline/rescalable fonts. The PostScript model is even more powerful, and allows for hardware accelerators. Think about the job a bitmap programmer has to do to stretch and rotate a diagram. This is trivial in PostScript. How about the basic model of the user interface? People don't want stand-alone applications. They want to drag a file and drop it onto a tool. Or select several files or objects, and then start the application with the input being the items selected. They also want to cut some information from one tool, and paste in into another tool - like a column of numbers into a chart drawing tool, which in turn is inserted into a document. If you change the data in the table, the chart will be updated and so with the document. These sort of issues make a large difference in the style of programming used to develop the application. What is 10 lines using one model might be 10 pages in another. Selecting a standard now won't solve those problems. Sure, you'll have a product next year, but the year after that you will have to redesign it anyway. I'm sorry for ranting on and on. My old company was very short sighted. They might still be around if they decided to take a few short term risks that had long term benefits. Perhaps that is why I believe so much in new technology. Happy Holidays, everyone. -- Bruce G. Barnett uunet!crdgw1!barnett From don Sat Dec 23 01:43:11 1989 Date: Sat, 23 Dec 89 01:43:11 -0500 To: NeWS-makers@brillig.umd.edu Subject: sun4/openwin 1.0 fails in init.ps? From: rocket!dove@uunet.uu.net (Webster &) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I just got a tape. I loaded, I setup a csh script in /local/bin/ --- xnews startup script #!/bin/csh -f -b setenv OPENWINHOME /local/openwin set path = ( $OPENWINHOME/{bin,bin/xview,demo} $path ) setenv LD_LIBRARY_PATH "$OPENWINHOME/lib:/usr/lib" setenv XNEWSHOME $OPENWINHOME setenv XVIEWHOME $OPENWINHOME setenv HELPDIR $OPENWINHOME/lib/help setenv MANPATH $OPENWINHOME/share/man:$MANPATH exec $OPENWINHOME/bin/xnews ------- It says something about undefined error reading init.ps ----- Process: 0x1b90c0 (Unnamed process) Error: undefined Stack: /HELPDIR (HELPDIR) (/lib/help) (\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000) (\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000) (/local/openwin) (\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000) Executing: Copy At: {... 4 -1 'roll' 1 'index' *Copy 'length' 4 -1 'roll' `putinterval'} In: {... 'type' /dicttype 'eq' packedarray{10} packedarray{16} *'ifelse'} In: Reading file('NeWS/init.ps',R) Sic transit gloria PostScript Help? -- Dr. Webster Dove Special Computing Applications Advanced Technology Engineering Sanders Associates (a Lockheed Company) uunet!rocket!dove From don Sat Dec 23 10:38:21 1989 Date: Sat, 23 Dec 89 10:38:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: Macintosh PostScript (and LaserPrep) From: usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!aero!louis@ucsd.edu (Louis M. McDonald) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) [ Please reply via email since I do not read all the groups I sent this to. I will post a summary of responses to all groups ] ================================================================ I have a modified created a modified version of LaserPrep 68 (also 60 and 52) that allows me to print Macintosh generated PostScript on non-Apple laserwriters (like DEC LPS40 and LNO3R). I decided to take one of these PostScript files (contains LaserPrep 68 and the PostScript for the figure [command-f]) to our IRIS workstation and try to display it with NeWS. I had no luck.... Has anyone successfully done this exercise in NeWS? Has anyone created a "transportable" version of LaserPrep 70 (color postscript) and display color Macintosh PostScript files in NeWS? -- Louis McDonald Internet: louis@aerospace.aero.org The Aerospace Corp. America OnLine: Louis Mc 213-336-8914 From don Fri Dec 29 12:32:24 1989 Date: Fri, 29 Dec 89 12:32:24 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows From: Rafael Bracho Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Re: doc%jalapeno.UUCP%fajita.UUCP@suntan.West.Sun.COM (Tom Dockery)'s message >The answer is somewhat simple: it's rather difficult to scale everything >appropriately to handle differing device densities if your have no way >of determining those densities. As most (though certainly not all) >monitors do not have any provisio for providing this information to the >framebuffer (and most framebuffers wouldnt know what to do with it anyway), >certain assumptions have to be made about the attached devices in advance. >In our shop, we regularly swap 16 and 19 inch color monitors around. On >a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 >inch monitor has a higher density of pixels per unit measure in either >dimension than the 19 inch. I agree with you in that it's impossible to find out actual monitor size. I still agree with Peter's original message in that the server should change the default matrix between an 1152 x 900 and a 1600 x 1280 framebuffers, so the same PostScript program should produce the same sized windows, on the same size monitors, regardless of framebuffer resolution. >The basic unit of measure in PostScript is the point, 1/72 of an inch; not >too metric, to be sure, but having a basis in the printing industry. If >the PostScript (or NeWS) programmer knows, or can query, the density of >the device to be driven, s/he can transform everything accordingly, so that >the same PS source prints to the same result on a 300 or 900 dpi printer. >The higher density printer then simply provides just that. If the >programmer can neither know in advance, nor find out a run-time by query >the density of the output device, however, s/he faces a quandry. There >is no real way, short of modifying the hardware, to solve the problem in a >device independent way ... I must disagree with you. The same PostScript source will produce the same output, without any resolution inquiries, providing the interpreter sets the default transformation matrix such that the default coordinate system is still 1/72's of an inch per unit (not quite points, but close enough). Thus the program: gsave 0 setgray /Helvetica findfont 14 scalefont setfont 144 144 scale 1 1 translate (Hello there!) show showpage grestore will produce a page with the string "Hello there!" in 14 point Helvetica, 2 inches above and 2 inches to the right of the lower left corner, *independently* of the printer's resolution. Note that it is possible to get in trouble by using 'setmatrix' instead of 'translate' and 'scale', particularly if one is not careful. Rafael Bracho rxb@asc.slb.com From don Fri Dec 29 12:32:40 1989 Date: Fri, 29 Dec 89 12:32:40 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <9405@hoptoad.uucp> hugh@hoptoad.UUCP (Hugh Daniel) writes: > I would like to point out that there is a version of NeWS for 640k MS-DOS > IBM-PC class machines, here is a note I had laying around about it. From the description you included, it sounds like a teaching tool. Can you write a program in C on the Sun, move it to the PC, compile it, and run it under NewsScript? Or is it a Postscript system only? -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Fri Dec 29 12:33:41 1989 Date: Fri, 29 Dec 89 12:33:41 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Portability is not easy in the X world. You must worry about > fonts to use [etc etc] Yes, I'm aware that X has some horrible design choices. > One of the best methods is to use Object > Oriented programming. You should be able to extend a scrollbar to > improve on it. Yeh, but that extension should not be in the application. The application programmer should not have to deal with the details of a scrollbar. Changes to the scrollbar should be outside the application binary. Of course this is virtually impossible in X. Which is why making X or X toolkits the basis of a future standard is, well, a horrible idea. X is a dead end. As I've said before, it's the Fortran of windowing systems. > It is true that there are a lot of applications that don't need O-O > techniques to develop powerful programs for them. But others do. Fine. And some applications don't need real-time response, but others do. Does this mean all programs should be written in a language designed for real-time work on a real-time O/S? > If you want a standard to be a subset of a powerful window system, fine. > I don't want such a standard myself. I would rather search for the > perfect user interface. Well then you don't think we need to standardise the UI either. Right? > If you want an application to run on PC's, Mac's, Amiga's and Unix > machines - I agree - this is a difficult problem. You can get X for > Mac's and I think PC's. I wouldn't *want* X for Macs or PCs or Amigas. It's big and it locks you into a programming model that isn't necessarily appropriate. But, yes > In conclusion, I think a standard library would limit creativity, and slow > down evolution towards a decent user interface. Depends on what the library looks like. And it would, properly designed, accelerate evolution towards a decent UI, by moving UI decisions OUT of the application. On the other hand a standard user interface just wastes time making people rewrite working software. And *stops* evolution towards a better one. Pick your poison. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Fri Dec 29 12:33:54 1989 Date: Fri, 29 Dec 89 12:33:54 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <7422@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Yeh, but that extension should not be in the application. The application >programmer should not have to deal with the details of a scrollbar. Changes >to the scrollbar should be outside the application binary. Not necessarily. Changing the cosmetics of it, and the simple user interface, yes. But suppose you had a scrollbar on a text window - like a C program. And you wanted to implement a pop-up menu that showed all of the functions defined in the program, allowing you to "go to" any function? This requires some interaction from the application programmer. If the scroll-bar didn't implement a pop-up menu, or implemented one that had a fixed list of choices, the application programmer must extend the scrollbar code to implement such functionality. >X is a dead end. As I've said before, it's the Fortran of windowing systems. Good analogy. >> It is true that there are a lot of applications that don't need O-O >> techniques to develop powerful programs for them. But others do. >Fine. And some applications don't need real-time response, but others do. >Does this mean all programs should be written in a language designed for >real-time work on a real-time O/S? I'm saying that if someone is proposing a standard that will be useful to as many applications as possible, it should support the a programming environment that makes the standard useful. User interfaces should not be cast in stone. There should be room to grow. Programmers need to modify and improve the efficiency of the program with respect to the interaction with the user. O-O techniques allows the programmer to easily change small portions of the user interface. It also allows the programmer the ability to extend the interface for a program without breaking other applications. If someone proposed a "windowing standard" without O-O extensions, I wouldn't even consider it usable. Unless I wanted something "quick and dirty". >> If you want a standard to be a subset of a powerful window system, fine. >> I don't want such a standard myself. I would rather search for the >> perfect user interface. > >Well then you don't think we need to standardise the UI either. > >Right? There is no doubt about the fact that a standard user interface will help Unix become more popular, which means programs become better, easier and cheaper. I also think the Right User Interface is not here yet. I feel it is important to have a style guide as a framework for future development. You need some starting point because the toolkit developers need to understand the basic features of the UI. Take Open Look's Push Pin menus. The fact that any menu can be pinned into place has implications in the program using this technique. One thing this does is provide an automatic means for adding menu acelerators - that is, if you use a menu often, you can pin it into place. The application programmer is no longer required to add special code to duplicate this functionality. Yet this is so important that each programmer would add this extension in some unique way. The end user would then be faced with a several programs with incompatible accelerators, giving the impression that each program had a different interface. There are a few things I do not like about the Push Pin menus - 1) The Push Pins and frames are too large. A lot of screen real-estate is used to show the frame and whitespace. 2) No keyboard accelerators - Some Mac applications have the ability to bind a key sequence to a menu choice. I think this should be added. I would like to change the window system to add these features. Others might change the initial package some other way. Eventually, the push-pins would evolve into it's replacement. >And it would, properly designed, accelerate evolution towards a decent UI, by >moving UI decisions OUT of the application. I don't believe that. The UI can be integral to a nicely tuned program. >On the other hand a standard user interface just wastes time making people >rewrite working software. And *stops* evolution towards a better one. > >Pick your poison. My "poison" would be tNt (the NeWS toolkit). This provides a starting point for applications. As I see shortcomings in the UI, I could extend the UI and make a program more useful to the end user. Since the extensions are made dynamically, I can either make a new class for just my applications, or if I felt the extensions was useful for all other applications, I would change the default object to my new improved object. All applications would then be improved, without recompiling, etc. Of course if the new model of the scrollbar, menu, etc. offered new functionality requiring new input from the application, it would have to be modified to make use of that new feature (like the scrollbar for the C program above). And since the NeWS toolkit is a complete O-O toolkit with multiple inheritance, I can use as much or as little of Open Look as I desire. I can use the scrollbar and nothing else - if that is what I need. I wouldn't call it poison. More like the first step towards my goal. -- Bruce G. Barnett uunet!crdgw1!barnett From don Fri Dec 29 13:01:26 1989 Date: Fri, 29 Dec 89 13:01:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: linus!community-chest!walters@think.com (Chris Walters) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <7422@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I wouldn't *want* X for Macs or PCs or Amigas. It's big and it locks you into >a programming model that isn't necessarily appropriate. But, yes Sure. X11/NeWS is BIG, X is just big. At least X will run on a 4MB 3/50. >`-_-' Peter da Silva. +1 713 274 5180. . > 'U` Also or . -- Chris Walters, walters@community-chest.mitre.org -- Chris Walters, MITRE McLean From don Fri Dec 29 13:01:39 1989 Date: Fri, 29 Dec 89 13:01:39 -0500 To: NeWS-makers@brillig.umd.edu Subject: XNeWS (FCS) From: russ@dash.mitre.org (Russell Leighton) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We have recently installed XNeWS FCS (First Customer Release). There is a problem that is NOT in the "special" release that is greatly annoying the users of the system. The arrow keys (r10, r8 ,r12, r14) no longer function in "xterm" windows. This means no arrow keys for Emacs but more importantly we have a group that makes extensive use of Matlab, whose line editing uses these keys. This may seem like a little problem but these people are very annoyed. How can I fix this? Did I not do something in the installation? Does the termcap need updating? Is this another of Sun's xnews "features" (like slowness, hogging memory, etc.). Frustrated. From don Fri Dec 29 13:01:59 1989 Date: Fri, 29 Dec 89 13:01:59 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows From: Robin Schaufler Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Tom Dockery got the explanation correct. To be picky, this technically is not device dependence; it is resolution dependence. It's no more device dependent than X is. There is a workaround in the bug report associated with the problem: Manually scale the user space from device pixels to points. For example, if using a 115 dot-per-inch display, the following PostScript code will construct the correct transformation: SAMPLE BEGIN 115 72 div dup scale SAMPLE END Tom is correct that in general the hardware does not announce its resolution to the software. However, the server's default transformation matrix could be set properly by means of a device database, analogous to termcap or terminfo. Unfortunately there are some additional problems where NeWS clients (including the window manager) set the current transform to the identity matrix, in which case the UI will fail even if the default transform were correct. Some NeWS clients (including the window manager) also use bitmaps which won't scale well if they use the default transform rather than the identity matrix. A good example of where a bitmap is usually used, that requires fixes in multiple places, is the cursor. So the problem requires fixes on many fronts, which is why it hasn't been fixed yet. -- Robin From: fajita!jalapeno!doc@suntan.West (Tom Dockery) Date: Fri, 22 Dec 89 16:37:56 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows > Inre the message: > > > >One of the many bugs listed in the developers release of Open Windows is > >the fact that the NeWS side is not device independent! Sun has done a lot of > >things wrong in attempting to promote NeWS but taking the device independenc e > >out of PostScript has to rank among the big ones. One of the major reasons > >we develop under NeWS was the fact that PostScript was device independent. > >Sun does not consider this a very important bug according to the ratings in > >the bug report. How can this be? Could someone please enlighten me about > >why this was done or if it will change any time soon? > > > > > > Peter > > korp@athens.ees.anl.gov > > Argonne National Laboratory > > > The answer is somewhat simple: it's rather difficult to scale everything > appropriately to handle differing device densities if your have no way > of determining those densities. As most (though certainly not all) > monitors do not have any provisio for providing this information to the > framebuffer (and most framebuffers wouldnt know wha> t to do with it anyway), > certain assumptions have to be made about the attached devices in advance. > In our shop, we regularly swap 16 and 19 inch color monitors around. On > a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 > inch monitor has a higher density of pixels per unit measure in either > dimension than the 19 inch. > The basic unit of measure in PostScript is the point, 1/72 of an inch; not > too metric, to be sure, but having a basis in the printing industry. If > the PostScript (or NeWS) programmer knows, or can query, the density of > the device to be driven, s/he can transform everything accordingly, so that > the same PS source prints to the same result on a 300 or 900 dpi printer. > The higher density printer then simply provides just that. If the > programmer can neither know in advance, nor find out a run-time by query > the density of the output device, however, s/he faces a quandry. There > is no real way, short of modifying the hardware, to solve the problem in a > device independent > way; so the NeWS programmers took the approach of > changing the abstraction somewhat, from representing a point as a fixed > measure, to representing it as a pixel. This is *not* truely device > independent, but it does mean I can scale my output on the basis of frame- > buffer resolution, which at least is something. > At least NeWS attempts to make some sort of abstraction; under X, you must > handle the abstraction yourself. Which is the better approach? Whatever > works, I suppose. The only way this situation will change, though, is for > the window server to take advantage of the newer hardware that does provide > density information, so that the programmer can work at the same level of > abstraction s/he uses with a PostScript printer. > Whew, maybe it wasnt that simple an answer! I hope it helps. > Tom Dockery, > Market Focus Technologies > sun!suntan!fajita!doc From don Fri Dec 29 13:02:24 1989 Date: Fri, 29 Dec 89 13:02:24 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows From: hpfcso!hpfcmgw!chan@hplabs.hp.com (Chan Benson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > The answer is somewhat simple: it's rather difficult to scale everything > appropriately to handle differing device densities if your have no way > of determining those densities. As most (though certainly not all) > monitors do not have any provisio for providing this information to the > framebuffer (and most framebuffers wouldnt know what to do with it anyway), > certain assumptions have to be made about the attached devices in advance. > In our shop, we regularly swap 16 and 19 inch color monitors around. On > a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 > inch monitor has a higher density of pixels per unit measure in either > dimension than the 19 inch. Certainly it would have been very easy (though a bit ugly) to have a config file in which the user could indicate the resolution (in dpi) of the monitor they have hooked up. -- Chan Benson HP Fort Collins From don Fri Dec 29 13:02:41 1989 Date: Fri, 29 Dec 89 13:02:41 -0500 To: NeWS-makers@brillig.umd.edu Subject: Whither NeWS? From: karl!davis@handies.ucar.edu (Glenn P. Davis) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) We are to write some software. It is supposed to take images ("weather pictures from space") and be able to overlay other information (like contour maps of surface temperature) on the resultant image. The kicker is that we would also like to be able to animate time series of these. Oh, yeah ... and it's supposed to work an whatever hardware the customer has, like low end workstations and maybe even high end PC's. At this point I've written VERY simple programs to loop say four of these images (no overlay) in the following API's: SunView NeXT Step Xt (Athena widgets). I'm personally convinced that the PostScript imaging model is the one to use. Running the Xt version even on a SPARCStation barely qualifies as 'animation'. I assume the problem is that I have to shove a quarter meg image down the client server pipe for each frame. I also feel that X puts too much responsibility in the client application. At the risk of starting a flame war, I'd like to get some information/opinions to back up my position, something I can use to convince the powers that be. Issues sure to come up: NeWS only available on Suns. I don't think this true. Other platforms supported, vendors and cost? Performance. Theoretically better for NeWS when Client/Server communications is the limiting factor. Other considerations? Is the PostScript in the pipeline binary encoded somehow or still ascii? (I seem to remember binary, but may be confused). Ease of programming. Any real world comparisons? (related to above) Maturity of toolkits. Remarks? Recommendations? NeWS was a good idea, but isn't it just a dead end now? Like, who is using it besides some pointy headed academics? (Not my opinion, but I've heard it said...) Examples of applications supporting NeWS. The Spectre of Display PostScript vs NeWS. If one concedes that X is the window system of the 80's and that PostScript is the way to go, we still aren't convinced that NeWS is the PostScript way to go. Please reply directly and I will summarize. Pointers to previous discussions also appreciated. Thanks for you input and the benefit of your experience. Glenn P. Davis davis@unidata.ucar.edu UCAR / Unidata PO Box 3000 1685 38th St. Boulder, CO 80307-3000 Boulder, CO 80301 (303) 497 8643 From don Fri Dec 29 13:02:57 1989 Date: Fri, 29 Dec 89 13:02:57 -0500 To: NeWS-makers@brillig.umd.edu Subject: NeWS Class From: dreams!rbogen@sun.com (Richard Bogen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Sun Microsystems Educational Services is pleased to announce that its NeWS Programming course (SG-260) has been updated to reflect the changes that were introduced into the merged xnews server by Openwindows. This 5 day course is offered at training centers in California and at several other locations throughout the U.S. and abroad. It consists of a combination of lectures and lab exercises on the following topics: PostScript(R) Language Programming NeWS Canvases, Processes, & Events Utilities & Debugging Object-Oriented Programming in NeWS A (Experimental) NeWS Toolkit - TNT Client Communications and X Windows To register for this or any other course call the following toll-free number between 8 a.m. and 5 p.m. PST: (800) 422-8020 or send email including your name and phone number with area code to: training@sun.com Employees of Sun should register via their internal mail alias and customers who wish to attend a facility outside of North America should contact their local sales office. From don Fri Dec 29 15:50:02 1989 Date: Fri, 29 Dec 89 15:50:02 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: hoptoad!hugh (Hugh Daniel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I would like to point out that there is a version of NeWS for 640k MS-DOS IBM-PC class machines, here is a note I had laying around about it. ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 1996 Hayes St. San Francisco CA94117 -------------------------------------------------------------------- NewScript, a NeWS interaction clone for MS/DOS by TAG inc. Technology Application Group inc. 10621 Bloomfield St., Suite 33 Los Alamitos, CA 90720 USA 213 430-9792 NewScript(tm) is a compact, high performance emulation of the NeWS, for 286 and 386 machines running DOS or OS/2(tm). NewScript offers an interactive user interface design environment for the development and prototyping of NeWS compatible graphical interfaces. Perfect for PostScript and NeWS class teaching! NewScript is based on the PostScript language as defined by Adobe Systems Inc. with Events, canvases, monitors, processes, and object PostScript extensions specified by NeWS. NewScript emulates a subset of NeWS and PostScript. CPS, network communications, and stroke fonts are not supported in version 1.0. From don Fri Dec 29 15:50:30 1989 Date: Fri, 29 Dec 89 15:50:30 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: hoptoad!hugh (Hugh Daniel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >From the description you included, it sounds like a teaching tool. Can you >write a program in C on the Sun, move it to the PC, compile it, and run it >under NewsScript? Or is it a Postscript system only? Right now it is a PostScript (NeWS really) only system with some serial I/O(I think). TAG ueses is to do user interfaces to run control equpment (milling machines etc.) ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 210 Clayton St. San Francisco CA94117 From don Fri Dec 29 19:25:07 1989 Date: Fri, 29 Dec 89 19:25:07 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Open Windows From: fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Inre Rafael Bracho's (ASC.SLB.COM!rxb) comment to my missive: > >>The basic unit of measure in PostScript is the point, 1/72 of an inch; not >>too metric, to be sure, but having a basis in the printing industry. If >>the PostScript (or NeWS) programmer knows, or can query, the density of >>the device to be driven, s/he can transform everything accordingly, so that >>the same PS source prints to the same result on a 300 or 900 dpi printer. >>The higher density printer then simply provides just that. If the >>programmer can neither know in advance, nor find out a run-time by query >>the density of the output device, however, s/he faces a quandry. There >>is no real way, short of modifying the hardware, to solve the problem in a >>device independent way ... > >I must disagree with you. The same PostScript source will produce the >same output, without any resolution inquiries, providing the interpreter >sets the default transformation matrix such that the default coordinate >system is still 1/72's of an inch per unit (not quite points, but close >enough). Thus the program: > > gsave > 0 setgray > /Helvetica findfont 14 scalefont setfont > 144 144 scale > 1 1 translate > (Hello there!) show > showpage > grestore > >will produce a page with the string "Hello there!" in 14 point >Helvetica, 2 inches above and 2 inches to the right of the lower left >corner, *independently* of the printer's resolution. > >Note that it is possible to get in trouble by using 'setmatrix' instead >of 'translate' and 'scale', particularly if one is not careful. > > Rafael Bracho > rxb@asc.slb.com > You seem to be disagreeing only to agree with me. Your are correct that the "Hello there!" code will be, independently of the printer, displayed at the same location on the page. But this is only due to the fact, as you mentioned, that the interpreter's default transformation matrix makes the appropriate scaling adjustment. For a port of PostScript to a given printer, this is no big deal, as the programmer knows in advance what the resolution of the device is, and can thus safely hardcode it in. With a PostScript interpreter for video, on the other hand, the programmer doesnt have that luxury, as the interpreter can and will be used with different resolution framebuffers *and* different size monitors. A key issue here is the distinction between the *resolution* of the framebuffer, which is a known, and the *density*, or dots-per-unit, of the monitor, which is an unknown. As Robin Schaufler (Sun.COM!robin) points out: > >Tom is correct that in general the hardware does not announce its >resolution to the software. However, the server's default >transformation matrix could be set properly by means of a device >database, analogous to termcap or terminfo. > Even this, though, is not entirely satisfactory, as it generally can only automate adjustment for the framebuffer (which is known anyway), but not for the monitor; the monitor would have to be explicitly specified, in an environmental variable I suppose, for the database lookup. Thus this solution is only somewhat better than that of explicitly adjusting ths scale for the monitor. In either case, the user must remember to explicitly change the adjustment or the variable every time s/he uses a different monitor. Tom Dockery, Market Focus Technologies sun!suntan!fajita!doc From don Fri Dec 29 19:25:57 1989 Date: Fri, 29 Dec 89 19:25:57 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or Op From: fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >>X is a dead end. As I've said before, it's the Fortran of windowing systems. > >Good analogy. Yeah, but look at what language most engineering students *still* cut their programming teeth on! And as government so aptly illustrates, bad ideas and dead ends dont always die the quick death they deserve. As a developer of a system that runs on multiple Unix platforms, I would love to be able to use NeWS on all of them; unfortunately, reality dictates that I use X (shudder) on most of them. And even Sun seems to be letting the excitement of the X bandwagon overcome them. And so, once again, the sublime is in danger of being overwhelmed by the vulgar. Sic transit gloria, tempus fugit, et cetera. Tom Dockery Market Focus Technologies (The rest of whom probably want very little to do with my opinions :{) ) sun!suntan!fajita!doc From don Sat Dec 30 00:37:16 1989 Date: Sat, 30 Dec 89 00:37:16 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: XNeWS (FCS) From: rruxi.bae.bellcore.com!tam2@bellcore.com (Wai Nam Tam) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I encountered the same problem on my Sun 3/60 running the FCS version of XNEWS. The arrow keys can be mapped using the "xmodmap" program. For the keyboard on my Sun 3/60 (Tyoe 3). Put the following in a file and then execute the "xmodmap" program on it. keycode 76=Up F28 keycode 98=Left F30 keycode 100=Right F32 keycode 120=Down F34 I just setup my Sparcstation 1 and have not had a chance to try the XNEWS stuff on it yet, so I don't know if the arrow keys are mapped for that server. If you have problems, check out the man page on "xmodmap". That's where I found all the info that I needed. Also, you can use the "xev" program to find out the "keycode value" for each key on the keyboard. If you want to check out the current key mappings, use "xmodmap -pk". I hope this helps. Wai Nam Tam tam2@rruxi.bae.bellcore.com ...!bellcore!rruxi!tam2 Standard disclaimers apply ... From don Sat Dec 30 16:58:25 1989 Date: Sat, 30 Dec 89 16:58:25 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Yeh, but that extension should not be in the application. The application >programmer should not have to deal with the details of a scrollbar. Changes >to the scrollbar should be outside the application binary. >Of course this is virtually impossible in X. Which is why making X or X >toolkits the basis of a future standard is, well, a horrible idea. >X is a dead end. As I've said before, it's the Fortran of windowing systems. >`-_-' Peter da Silva. +1 713 274 5180. . > 'U` Also or . >"It was just dumb luck that Unix managed to break through the Stupidity Barrier >and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com Almost all of the things you say about X could also be said about UNIX and have thus I am confused by your signature quote. Could it be that Sun is still trying to make something as good as the Apollo Display Manager .. a network windowing system based on the client server model? I think some of the toolkits coming out for X have alot of promise.. they are also for the most part still basically public domain freeware. In terms of extensibility they all have their good and bad sides. If NeWS is to find some niche it would be better off not knocking X but joining with it and enhancing it. Xnews is a poor attempt at this.. I do not think all of that stuff belongs in the server. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| From don Sun Dec 31 17:17:15 1989 Date: Sun, 31 Dec 89 17:17:15 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: diamond.bbn.com!mlandau@bbn.com (Matt Landau) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) lerici@SUPER.ORG (Peter W. Brewer) writes: >Could it be that Sun is still >trying to make something as good as the Apollo Display Manager .. a network >windowing system based on the client server model? No, they've already made something *better* than either X11 or the Apollo Display Manager: a network window system based on the client/server model where the imaging model in the server is *useful*, and helps rather than hinders someone who wants to write an application that has non-trivial display requirements. The place where Sun botched it was in not doing a "sample implementation" of NeWS and making it publicly available in the same way that the "sample implementation" of X11 is freely available. If they had, X would have died off by now, because NeWS is simply a technically superior idea. For the life of me, I still can't understand how anyone involved in the early design phases of X11 thought that a resolution-dependent imaging model based on rectangular arrays of pixels was a good idea, when the groundwork had already been laid for using a page description langauge as the basis of the imaging model in other systems. Was no one familiar with the history of SunDEW, for example? >I think some of the >toolkits coming out for X have alot of promise.. they are also for the most >part still basically public domain freeware. Tell that to OSF -- Motif, which is (alas!) likely to become the dominant X11 toolkit, is considered proprietary software with source code license fees, royalty payments due by software vendors who ship Motif binaries, etc. That's an interesting contrast to Sun -- historically considered the "bad guys" of the window system world for not making NeWS free -- which has finally seen the light and made the XView toolkit freely available to anyone, for any purpose. >In terms of extensibility they all have their good and bad sides. The point is not about toolkits, although personally I don't find any of the existing toolkits terribly worthwhile from the point of view of extensibility. (Writing new widgets, for instance, is considerably more difficult than it needs to be. InterViews might be an exception to the rule that toolkits are hard to extend -- writing in C++ buys you a lot a priori -- but I haven't had a chance to work much with InterViews.) The real point is that X11 is fundamentally flawed by virtue of not providing extensible window *server*. There's no way for an application at runtime to change the characteristics of the server, add new facilities to it, etc. If you look even cursorily at what you can do by downloading PostScript code into the X11/NeWS server, and at the contortions you have to go through to achieve the same thing in X, it should be obvious why a runtime-extensible server is The Right Thing. No, Display PostScript doesn't count. It only allows you to image stuff, not to extend the input handling characteristics of the server the way you can in X11/NeWS. It's also by no means universal, and if you can't count on a facility being in the server, then it might as well not be there. The so-called "extensibility" of the X11 protocol also doesn't count. You have to recompile the server to make extensions. As a software vendor, I shouldn't have to be in the business of writing modified window servers in order to write the kind of applications I want to write. >If NeWS is to find some niche it would >be better off not knocking X but joining with it and enhancing it. Xnews is >a poor attempt at this.. I do not think all of that stuff belongs in the >server. I'd be interested in knowing exactly what you think is wrong with X11/NeWS. Personally, the idea of a single server based on a reasonable imaging model that interprets both X11 and NeWS protocol requests seems like the most elegant way to provide the X11 compatibility that the market demands without sacrificing the inherently superior characteristics of NeWS. (Don't get me wrong -- there are some things wrong with X11/NeWS. One is that it runs too slowly and uses too much memory, but that can be fixed if Sun gets on the ball technically. Another is that making "point" == "pixel" in NeWS PostScript was just stupid -- granted you can't discover automatically the resolution of your display device, since the hardware doesn't tell you, but you could at least provide command line flags or environment variables read by the server that would let the *user* tell you what the resolution is. Maybe in OpenWindows 1.1??) -- Matt Landau mlandau@bbn.com Diplomacy is the art of saying "nice doggy" until you can find a rock. From don Sun Dec 31 17:17:21 1989 Date: Sun, 31 Dec 89 17:17:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!wuarchive!texbell!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4360@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > In article <7422@ficc.uu.net>, peter@ficc (Peter da Silva) writes: > >The application programmer should not have to deal with the details of a > >scrollbar. Changes to the scrollbar should be outside the application binary. > But suppose you had a scrollbar on a text window - > like a C program. And you wanted to implement a pop-up menu that > showed all of the functions defined in the program, allowing you to > "go to" any function? What does this have to do with a scrollbar? This sort of functionality could be attached to the window as a whole, with little if any loss of generality. Attaching menus to objects smaller than a window seems of dubious value to me. Your point seems to be that standardising will limit the things that can be done to the window. What if you're running under a window system that traps the menu button at a higher level? That won't let you attach a menu to something like a scrollbar? Now you've lost a capability... your program isn't portable anyway. I agree... standardisation involves limiting the capability of the programmer to implement things. It's the price you pay for the ability to run a program on a wide variety of systems. > >X is a dead end. As I've said before, it's the Fortran of windowing systems. > Good analogy. Thanks. So why standardize on an X toolkit? > >> It is true that there are a lot of applications that don't need O-O > >> techniques to develop powerful programs for them. But others do. > >Fine. And some applications don't need real-time response, but others do. > >Does this mean all programs should be written in a language designed for > >real-time work on a real-time O/S? > I'm saying that if someone is proposing a standard that will be useful > to as many applications as possible, it should support the a > programming environment that makes the standard useful. Yes, but it shouldn't require that environment. I find it hard to see how a standard program interface to windows will limit the utility of object oriented programming techniques any more than a standard program interface to files. > User interfaces should not be cast in stone. There should be room to > grow. Programmers need to modify and improve the efficiency of the > program with respect to the interaction with the user. Sure. I could really improve the capability of Browse if I could get real-time response, or if I could watch files to see when they change. But the hooks don't exist. You could do all sorts of amazing things with the machine if the interface to the file system was just a shared library that you could dig into and go around. There are good reasons for locking stuff away behind doors: security, efficiency (how well would buffer pools work if all programs had their own copy of the FS? How much work would be duplicated if every program had to do its own locking?) I think that windowing systems are another place where this sort of thing should be considered. > If someone proposed a "windowing standard" without O-O extensions, > I wouldn't even consider it usable. Unless I wanted something > "quick and dirty". If someone proposed a "windowing standard" that *required* O-O languages to work, I wouldn't even consider it usable. > I feel it is important to have a style guide as a framework for future > development. You need some starting point because the toolkit > developers need to understand the basic features of the UI. Take Open > Look's Push Pin menus. The fact that any menu can be pinned into place > has implications in the program using this technique. One thing this > does is provide an automatic means for adding menu acelerators - that > is, if you use a menu often, you can pin it into place. Yes, but you can also add menu accelerators by using keyboard shortcuts. I like them a lot better, because I generally don't have a lot of screen real-estate to throw away. If the UI wasn't in the program, I could take your application and set it up on my screen with Alt-N for New, Alt-D for Delete, and so on. *I*, as a user, could customise the UI. > The application programmer is no longer required to add special code > to duplicate this functionality. the application programmer was never required to do this. > Yet this is so important that each > programmer would add this extension in some unique way. That's your opinion. Not mine. Much more important is the ability for me, as a user, to customise the hell out of my environment without having to put up with application programmers stuck on Open Look, or Motif, or whatever. > The end user would then be faced with a several programs with > incompatible accelerators, giving the impression that each program had > a different interface. Not if the standard said "The user will have the ability to provide shortcuts for menus. The mechanism of this shortcut is not specified, and may change from one minute to the next, and in fact multiple methods may be used". > I would like to change the window system to add these features. Others > might change the initial package some other way. Eventually, the > push-pins would evolve into it's replacement. No, you'd have some *applications programmers* using pushpins, some using keyboard shortcuts, some using floating icons or icon bars, and so on... Or else you'll have people using pushpins, and pushpins only, until the cows come home. > I don't believe that. The UI can be integral to a nicely tuned program. If the UI is *that* integral to the program, then the UI or the program needs some redesign. > And since the NeWS toolkit is a complete O-O toolkit with multiple > inheritance, I can use as much or as little of Open Look as I desire. > I can use the scrollbar and nothing else - if that is what I need. Yes, but it doesn't (back to my point) require the PROGRAM as a whole to be written in an O-O language. Unfortunately the NeWS toolkit is too big for today's small computers. Which are going to be with us for a long time to come. Oh, and it's still proprietary to Sun, and not even available for the small machines that *can* support it (that is, the ones not dependent on intel's brain-dead processors). A properly designed windowing standard would let you port a program from the Sun to the Mac just by recompiling. Like Guido Von Rossum's "STDWIN" package. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Sun Dec 31 17:20:00 1989 Date: Sun, 31 Dec 89 17:20:00 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!wuarchive!texbell!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4360@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > In article <7422@ficc.uu.net>, peter@ficc (Peter da Silva) writes: > >The application programmer should not have to deal with the details of a > >scrollbar. Changes to the scrollbar should be outside the application binary. > But suppose you had a scrollbar on a text window - > like a C program. And you wanted to implement a pop-up menu that > showed all of the functions defined in the program, allowing you to > "go to" any function? What does this have to do with a scrollbar? This sort of functionality could be attached to the window as a whole, with little if any loss of generality. Attaching menus to objects smaller than a window seems of dubious value to me. Your point seems to be that standardising will limit the things that can be done to the window. What if you're running under a window system that traps the menu button at a higher level? That won't let you attach a menu to something like a scrollbar? Now you've lost a capability... your program isn't portable anyway. I agree... standardisation involves limiting the capability of the programmer to implement things. It's the price you pay for the ability to run a program on a wide variety of systems. > >X is a dead end. As I've said before, it's the Fortran of windowing systems. > Good analogy. Thanks. So why standardize on an X toolkit? > >> It is true that there are a lot of applications that don't need O-O > >> techniques to develop powerful programs for them. But others do. > >Fine. And some applications don't need real-time response, but others do. > >Does this mean all programs should be written in a language designed for > >real-time work on a real-time O/S? > I'm saying that if someone is proposing a standard that will be useful > to as many applications as possible, it should support the a > programming environment that makes the standard useful. Yes, but it shouldn't require that environment. I find it hard to see how a standard program interface to windows will limit the utility of object oriented programming techniques any more than a standard program interface to files. > User interfaces should not be cast in stone. There should be room to > grow. Programmers need to modify and improve the efficiency of the > program with respect to the interaction with the user. Sure. I could really improve the capability of Browse if I could get real-time response, or if I could watch files to see when they change. But the hooks don't exist. You could do all sorts of amazing things with the machine if the interface to the file system was just a shared library that you could dig into and go around. There are good reasons for locking stuff away behind doors: security, efficiency (how well would buffer pools work if all programs had their own copy of the FS? How much work would be duplicated if every program had to do its own locking?) I think that windowing systems are another place where this sort of thing should be considered. > If someone proposed a "windowing standard" without O-O extensions, > I wouldn't even consider it usable. Unless I wanted something > "quick and dirty". If someone proposed a "windowing standard" that *required* O-O languages to work, I wouldn't even consider it usable. > I feel it is important to have a style guide as a framework for future > development. You need some starting point because the toolkit > developers need to understand the basic features of the UI. Take Open > Look's Push Pin menus. The fact that any menu can be pinned into place > has implications in the program using this technique. One thing this > does is provide an automatic means for adding menu acelerators - that > is, if you use a menu often, you can pin it into place. Yes, but you can also add menu accelerators by using keyboard shortcuts. I like them a lot better, because I generally don't have a lot of screen real-estate to throw away. If the UI wasn't in the program, I could take your application and set it up on my screen with Alt-N for New, Alt-D for Delete, and so on. *I*, as a user, could customise the UI. > The application programmer is no longer required to add special code > to duplicate this functionality. the application programmer was never required to do this. > Yet this is so important that each > programmer would add this extension in some unique way. That's your opinion. Not mine. Much more important is the ability for me, as a user, to customise the hell out of my environment without having to put up with application programmers stuck on Open Look, or Motif, or whatever. > The end user would then be faced with a several programs with > incompatible accelerators, giving the impression that each program had > a different interface. Not if the standard said "The user will have the ability to provide shortcuts for menus. The mechanism of this shortcut is not specified, and may change from one minute to the next, and in fact multiple methods may be used". > I would like to change the window system to add these features. Others > might change the initial package some other way. Eventually, the > push-pins would evolve into it's replacement. No, you'd have some *applications programmers* using pushpins, some using keyboard shortcuts, some using floating icons or icon bars, and so on... Or else you'll have people using pushpins, and pushpins only, until the cows come home. > I don't believe that. The UI can be integral to a nicely tuned program. If the UI is *that* integral to the program, then the UI or the program needs some redesign. > And since the NeWS toolkit is a complete O-O toolkit with multiple > inheritance, I can use as much or as little of Open Look as I desire. > I can use the scrollbar and nothing else - if that is what I need. Yes, but it doesn't (back to my point) require the PROGRAM as a whole to be written in an O-O language. Unfortunately the NeWS toolkit is too big for today's small computers. Which are going to be with us for a long time to come. Oh, and it's still proprietary to Sun, and not even available for the small machines that *can* support it (that is, the ones not dependent on intel's brain-dead processors). A properly designed windowing standard would let you port a program from the Sun to the Mac just by recompiling. Like Guido Von Rossum's "STDWIN" package. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Sun Dec 31 17:20:35 1989 Date: Sun, 31 Dec 89 17:20:35 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Scaleing in NeWS From: crdgw1!montnaro@uunet.uu.net (Skip Montanaro) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <9443@hoptoad.uucp> hugh@hoptoad.uucp (Hugh Daniel) writes: There is a simple solution to the problem of the current batch of moniters not being able to tell the OS what there DPI is. Simpley use a enviornment variable, say setenv DPI display1=72,display2=116 or some such rot. This even lets users change the dpi on there screens to say, make EVERYTHING look bigger. It seems to me that enhancing the console entry in the eeprom or adding one or more screen entries with DPI information would be a more permanent solution. After all, the resolution of the screen isn't likely to change with each user. I agree the user should be able to override this info, however, in a manner as Hugh suggests. -- Skip (montanaro@crdgw1.ge.com) From don Sun Dec 31 17:20:44 1989 Date: Sun, 31 Dec 89 17:20:44 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8912302010.AA11723@super.super.org> lerici@SUPER.ORG (Peter W. Brewer) writes (and also sends in mail. I wish people would stop doing this... or at least *note* that they're mailing as well as posting a response!): > Almost all of the things you say about X could also be said about UNIX Not at all. The things that I particularly dislike about X are: It requires a huge runtime overhead linked in with each program. Complex policy is forced on the application programmer. A certain programming model is forced on the application programmer. It's very very large. None of these things are true of UNIX. The runtime for a small programming language (say, FORTH) under UNIX is under 1K. Most programs have no user interface policy at all. Almost none even have to parse filenames or scan directories. In fact, UNIX forces less policy on the program than anything I know: most systems at least expect a program to scan wildcards! UNIX has (and does) run languages and systems in every programming model you can think of... including communicating concurrent processes. And UNIX is small. It's run 8 users in 128 K words of RAM. The Cory 11/70 at Berkeley, running V7 and 2BSD, was usable with 35 users in 2 Meg of RAM. With 60 users it was unbearable but it kept going. These numbers are in line with the best proprietary systems of the time. Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. But there's nothing inherent in UNIX that makes it a hog. And it scales very well. X scales not at all... it starts big. > If NeWS is to find some niche it would > be better off not knocking X but joining with it and enhancing it. I'm sorry, I really don't know how you can combine X and NeWS. They have completely different ideas of how the system works. X puts all this overhead in the client, where it gets duplicated zillions of times and gets copied over the network redundently again and again and again... NeWS puts the window system where it's needed... in the display system. > Xnews is a poor attempt at this.. How could it help but be? > I do not think all of that stuff belongs in the server. It's gotta be one plece or the other. At least in the server you only need one copy of it. And RAM's generally cheaper for the server. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Sun Dec 31 17:22:27 1989 Date: Sun, 31 Dec 89 17:22:27 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <8912302010.AA11723@super.super.org> lerici@SUPER.ORG (Peter W. Brewer) writes (and also sends in mail. I wish people would stop doing this... or at least *note* that they're mailing as well as posting a response!): > Almost all of the things you say about X could also be said about UNIX Not at all. The things that I particularly dislike about X are: It requires a huge runtime overhead linked in with each program. Complex policy is forced on the application programmer. A certain programming model is forced on the application programmer. It's very very large. None of these things are true of UNIX. The runtime for a small programming language (say, FORTH) under UNIX is under 1K. Most programs have no user interface policy at all. Almost none even have to parse filenames or scan directories. In fact, UNIX forces less policy on the program than anything I know: most systems at least expect a program to scan wildcards! UNIX has (and does) run languages and systems in every programming model you can think of... including communicating concurrent processes. And UNIX is small. It's run 8 users in 128 K words of RAM. The Cory 11/70 at Berkeley, running V7 and 2BSD, was usable with 35 users in 2 Meg of RAM. With 60 users it was unbearable but it kept going. These numbers are in line with the best proprietary systems of the time. Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. But there's nothing inherent in UNIX that makes it a hog. And it scales very well. X scales not at all... it starts big. > If NeWS is to find some niche it would > be better off not knocking X but joining with it and enhancing it. I'm sorry, I really don't know how you can combine X and NeWS. They have completely different ideas of how the system works. X puts all this overhead in the client, where it gets duplicated zillions of times and gets copied over the network redundently again and again and again... NeWS puts the window system where it's needed... in the display system. > Xnews is a poor attempt at this.. How could it help but be? > I do not think all of that stuff belongs in the server. It's gotta be one plece or the other. At least in the server you only need one copy of it. And RAM's generally cheaper for the server. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Mon Jan 1 02:29:20 1990 Date: Mon, 1 Jan 90 02:29:20 -0500 To: NeWS-makers@brillig.umd.edu Subject: Scaleing in NeWS From: hoptoad!hugh (Hugh Daniel) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) There is a simple solution to the problem of the current batch of moniters not being able to tell the OS what there DPI is. Simpley use a enviornment variable, say setenv DPI display1=72,display2=116 or some such rot. This even lets users change the dpi on there screens to say, make EVERYTHING look bigger. Of cource the problems with this is that all of Sun's code is dependent on screen size, as in the File Manager's waste basket which comes up in the middle of a 1600x1200 screen (a XView app., but the same is true of Suns NDE (no more name changes...) toolkit). Also, with the low res of the screens Sun (and theire non Compeditors) use (say, screens with less the 2kx2k and less then 4 bits deep) one has to go to a LOT of work to get PostScript glyphs to look right, which has not been done. The alturnitive is to define everything by Pixels, which the last rev. that I saw of the Open Look spec. is back to using. This also is a lot of work, but the short term advantage is that at one dpi things look right, of cource next month when the next higher res. screen comes in someone gets to do all that work again... ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 210 Clayton St. San Francisco CA94117 From don Tue Jan 2 13:52:53 1990 Date: Tue, 2 Jan 90 13:52:53 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: pasteur!ic.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article peter@ficc.uu.net (Peter da Silva) writes: >Not at all. The things that I particularly dislike about X are: > > It requires a huge runtime overhead linked in with each program. > Complex policy is forced on the application programmer. > A certain programming model is forced on the application programmer. > It's very very large. > >None of these things are true of UNIX. The runtime for a small programming >language (say, FORTH) under UNIX is under 1K. ... > I am afraid I disagree with the arguments expressed here. The problem truely lies in toolkits and policy. In order for memory savings to take place, programs *must agree* to use the same features. Otherwise, using the NeWS paradigm, each program will download its own features into the server and you will have a gigantic server where little or no sharing occurs. Furthermore, the problem is *identical* for both NeWS and X. Both systems provide fairly low-level user interface programming facilities. Both systems require higher level facilities in order to quickly build real-world user interfaces. The solution is to have programs agree on a toolkit. The memory savings will be the same under both systems: - Under NeWS, toolkit facilities will be downloaded to the server where possible and applications will link against a shared library for client side facilities. - Under X, applications will link against a shared library for most toolkit functionality and may use server extensions (if present). In both cases, applications will share the toolkit code. The sum of server size and client size should be roughly equivalent. My point is that there is nothing fundamental about NeWS that makes this problem any easier. Furthermore, in my opinion, there are some problems in the NeWS model that make it harder to develop a general purpose toolkit that meets the needs of a wide range of application developers. I have posted these problems before in this newsgroup so I won't repeat them here. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) From don Tue Jan 2 13:56:09 1990 Date: Tue, 2 Jan 90 13:56:09 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article , peter@ficc (Peter da Silva) writes: >> But suppose you had a scrollbar on a text window - >> like a C program. And you wanted to implement a pop-up menu that >> showed all of the functions defined in the program, allowing you to >> "go to" any function? > >What does this have to do with a scrollbar? This sort of functionality could >be attached to the window as a whole, with little if any loss of generality. I generally use the scrollbar to "go to" a different part of the object I am looking at. I also like to jump to specific line numbers or procedures. Why shouldn't this be in the scrollbar? It is true that I could do this by a pop-up menu in the main window, but I might want to keep this menu free for my application, and since I can ask for a menu in the scrollbar area, why not use it? Also - the scrollbar can be used as the mechanism to split a window into two separate views of the same object, with two separate scrollbars. This little "feature" requires forethought; adding this to the UI might require a major rewrite of the code. Even if you would NEVER want to do the above, the point is - some people do want the ability, and because the style guide says it is possible, the toolkits should support this feature. Without the style guide, a toolkit could be written that would require major source code changes to support new features. All I am doing is repeating the basic software engineering waterfall model. To repeat myself, I believe AT&T/Sun did the right thing by specifying the style guide first, and then develop four toolkits that more or less meets the specification of the style guide. The obvious goal is to have several independent groups develop the best toolkit for the market segment. An application programmer can pick the most appropriate toolkit (X intrinsics, XView, NeWS, or SunView) and the end user will be unaware that there are different toolkits underneath. As this conversation proves, there is no one right language to everyone. Trying to specify a single language/window interface that can meet everyone's requirements is not possible. >X is a dead end. As I've said before, it's the Fortran of windowing systems. > So why standardize on an X toolkit? I'm not sure what you are asking. There are obvious reasons to standardize on an X toolkit. Unfortunately, the application writers and the end users will suffer, unless AT&T and OSF merge the two user interfaces. >> I'm saying that if someone is proposing a standard that will be useful >> to as many applications as possible, it should support the a >> programming environment that makes the standard useful. >Yes, but it shouldn't require that environment. I find it hard to see how >a standard program interface to windows will limit the utility of object >oriented programming techniques any more than a standard program interface >to files. Well, you may consider items like menus, windows, icons, cursors, buttons, scrollbars, and drawing primitives to be separate items with separate interfaces. NeWS views those items as different objects in the same class hierarchy. You can draw an object, enlarge it and use it as a background on your screen, convert it to an icon, button, window, cursor or anything else you want. There is no reason you couldn't, in NeWS, draw a new geometric shape, like a rectangle with curved corners complete with a shadow, and then make that shape the new default shape of all of your windows. You can also change constants (like the color of a window) into a procedure. In otherwords, the restrictions in most window systems don't apply to NeWS. A "standard program interface" would effectively eliminate most of the advantages of the NeWS windowing system. It's like asking a Lisp programmer to program in Fortran. [I talked about the shortcomings of Open Look, and how it doesn't support user defined keyboard accelerators for menu items] >Yes, but you can also add menu accelerators by using keyboard shortcuts. >> Yet this is so important that each >> programmer would add this extension in some unique way. > >That's your opinion. Not mine. Much more important is the ability for me, as >a user, to customise the hell out of my environment without having to put up >with application programmers stuck on Open Look, or Motif, or whatever. This is a misunderstanding here. I was discussing how Open Look does NOT allow the user to add keyboard accelerators. If I were developing a program that used Open Look, I would provide some way for the END USER to add those keyboard accelerators for the menu choices. >> The UI can be integral to a nicely tuned program. > >If the UI is *that* integral to the program, then the UI or the program >needs some redesign. Huh? There are a lot of satisfied Mac users. There are people who LIKE a one-button mouse. Convince them the user interface and/or the program needs redesign. >Unfortunately the NeWS toolkit is too big for today's small computers. As is X. > Oh, and it's still proprietary to Sun, It comes with the Unix source tape. >and not even available for the small machines that *can* support it >(that is, the ones not dependent on intel's brain-dead processors). Shrug. It was your decision to buy an Amiga. Bug Commodore for Unix V.4. -- Bruce G. Barnett uunet!crdgw1!barnett From don Tue Jan 2 14:04:05 1990 Date: Tue, 2 Jan 90 14:04:05 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <13323@diamond.BBN.COM>, mlandau@bbn (Matt Landau) writes: >Was no one familiar >with the history of SunDEW, for example? Mesa, Cedar and Docs (1980) had an advanced image model four years before SunDEW. -- Bruce G. Barnett uunet!crdgw1!barnett From don Tue Jan 2 14:05:16 1990 Date: Tue, 2 Jan 90 14:05:16 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: spectral!sjs@bellcore.com (Stan Switzer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article peter@ficc.uu.net (Peter da Silva) writes: > If the UI is *that* integral to the program, then the UI or the program > needs some redesign. Here's the crux of the problem: if you want a responsive GRAPHICAL user interface, you'll have to write the UI portion of the application in a particular, probably event-driven, way. There just ain't no getting around it. At the same time, it might just be possible to write the UI portion of the program as a separate front-end program (as in bc/dc in UNIX). There was some discussion about a year ago on this very group about techniques for doing this in NeWS. > Yes, but it doesn't (back to my point) require the PROGRAM as a whole to > be written in an O-O language. In NeWS, you write your program any way you want to, but it is just plain silly not to use O-O techniques in the UI part (which can be almost entirely in the server). > Unfortunately the NeWS toolkit is too big for today's small computers. Which > are going to be with us for a long time to come. Oh, and it's still > proprietary to Sun, and not even available for the small machines > that *can* support it (that is, the ones not dependent on intel's > brain-dead processors). First, I don't know what you mean by "today's small computers." This has been discussed to death. Small is already quite large and it is getting larger. Second, NeWS has been ported to PC's and this too has already been discussed. Third, although NeWS is "proprietary," it is available for token licensing fees. And this seems prudent to me. Anyone who is really serious about porting NeWS to a new platform as a commercial venture can scrape up the capital to do it. It is less than a year's salary for a grunt worker. Contact Steven Messino (messino@Sun.com) for details. Educational licensing is quite reasonable as well. Finally, your Intel bashing is tiring. What IS your point anyway? > A properly designed windowing standard would let you port a program from the > Sun to the Mac just by recompiling. > > Like Guido Von Rossum's "STDWIN" package. OH! That's it. Well for heaven's sake, if you find STDWIN adequate for your purposes, then by all means use it. The rest of us have real work to do. Stan Switzer sjs@bellcore.com From don Tue Jan 2 14:06:00 1990 Date: Tue, 2 Jan 90 14:06:00 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows?? From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Peter DaSilva responds: > I really don't know how you can combine X and NeWS. I think I said that X is just a name. I believe that the client server concept espoused by NeWS is the right one .. exactly the same one that Apollo has used quite well for 10 years now. X is just a name.. a label just as Fortran is now. Peter DaSilva responds: >Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. I believe the above three define the label UNIX. V7 is now obsolete and used only on obsolete systems. Roots smoots.. if you want to start that I will start telling you about how NeWS should do things that Apollo did 10 years ago!!! But no one learns from anyone else anymore. Until OSF comes out with something I believe those three (and now less so Berkeley) define UNIX. I hope that NeXT makes some headway before OSF spawns another monster. Peter Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| From don Tue Jan 2 14:06:06 1990 Date: Tue, 2 Jan 90 14:06:06 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) (Bob starts the new year by diving into a flamefest :-) In article <13323@diamond.BBN.COM> mlandau@bbn.com (Matt Landau) writes: The place where Sun botched it was in not doing a "sample implementation" of NeWS and making it publicly available in the same way that the "sample implementation" of X11 is freely available. Right! And it's surprising that their marketeers didn't see that. Enough people at the time were offering such suggestions as free advice, one wonders why Sun didn't listen. It's too late now. If they had, X would have died off by now, because NeWS is simply a technically superior idea. X may not have died off yet. It has become a rallying point for other companies' marketeers who noticed that Sun was getting its name on too many innovations that were being adopted as de-facto standards. The widespread adoption of X was, IMHO, largely in response to the announcement of NeWS. And since that time we've seen corresponding marketing department-based battles over the underlying operating systems (Why do you think OSF exists? Entirely for marketing and political reasons, the technical concerns included as an afterthought. But I digress still more...). For the life of me, I still can't understand how anyone involved in the early design phases of X11... My understanding is that X grew from W, the window system atop the V kernel from Stanford. ...Was no one familiar with the history of SunDEW, for example? V happened before SunDEW, and X just carried much of W's basic technology along. An interesting semi-early (1985) reference is "Methodology of Window Management", Aho, Hopgood, and Ullman; Springer-Verlag. Sorry, my copy is at home, else I'd have the ISBN handy to cite. The conference of which the book contains the proceedings discusses various historic approaches to windows and user interfaces on various underlying software architectures (Cedar, UNIX, Perqs, etc.) Well worth reading. No, Display PostScript doesn't count. Right! It's another marketing-originated red herring. It's useful for those without a sufficient imaging model who realized later (as PostScript printers became universal) that they needed to invoke the magic P-word for "compatibility". The so-called "extensibility" of the X11 protocol also doesn't count. It might help to have a sample implementation of a server that would be protocol-extensible on the fly, at runtime. In the mean time, X runs on everything and there are lots and lots of people writing free software for it. I use X mainly for those reasons, though my aesthetic sensibilities cry out for better. From don Tue Jan 2 14:06:33 1990 Date: Tue, 2 Jan 90 14:06:33 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: XNeWS (FCS) From: bochner@husc6.harvard.edu (Harry Bochner) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) When trying out XNeWS I've found that the server seems to be ignoring the caps lock key. Is there perhaps a fix involving keyboard remapping, similar to the fix that was posted for the arrow key problem? Harry Bochner bochner@endor.harvard.edu From don Tue Jan 2 14:08:44 1990 Date: Tue, 2 Jan 90 14:08:44 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!texbell!sugar!ficc!peter@ucsd.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > I am afraid I disagree with the arguments expressed here. The problem > truely lies in toolkits and policy. In order for memory savings to > take place, programs *must agree* to use the same features. This is a political problem, primarily. You have to convince people that it's not a good idea to create new *types* of gadgets. However, there's no point in trying to make them all look alike. > Otherwise, > using the NeWS paradigm, each program will download its own features > into the server and you will have a gigantic server where little or > no sharing occurs. Perhaps. Does this happen in practice, though? I think we can all agree that it does happen in X. And X doesn't even have the option of sharing resources when they're desirable... sure, you can use shared libraries, but that doesn't help when you're dealing with multiple machines. This is a networked window system, after all. And X doesn't leave a channel for the user to install enhanced gadgets, except by at least relinking all their programs. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Tue Jan 2 14:09:06 1990 Date: Tue, 2 Jan 90 14:09:06 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!texbell!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > since I can ask for a > menu in the scrollbar area, why not use it? Perhaps because having a bunch of context-sensitive menus attached to different parts of the window is a bad idea? > Also - the scrollbar can be used as the mechanism to split a window > into two separate views of the same object, with two separate > scrollbars. This little "feature" requires forethought; adding this > to the UI might require a major rewrite of the code. Perhaps, if the UI is specified at too low a level. If it's defined in terms of "text pane: size, contents" then what goes on inside that text pane is none of the applications business. Maybe you can "zoom" the pane out to encompass the whole window. Who cares? The application certainly shouldn't. The sort of micro-optimisation you're pushing for here seems penny wise and pound foolish. > As this conversation proves, there is no one right language to > everyone. Trying to specify a single language/window interface that > can meet everyone's requirements is not possible. No, but you can come close if you don't concentrate on details. > >Yes, but it shouldn't require that environment. I find it hard to see how > >a standard program interface to windows will limit the utility of object > >oriented programming techniques any more than a standard program interface > >to files. > Well, you may consider items like menus, windows, icons, cursors, > buttons, scrollbars, and drawing primitives to be separate items with > separate interfaces. Menus are a reasonable level of abstraction. Buttons, scrollbars, and the like aren't. They're too low. That's more in the lines of a standard program interface to arrays. Too language and application dependent. [lots of good stuff about NeWS] > This is a misunderstanding here. I was discussing how Open Look does > NOT allow the user to add keyboard accelerators. If I were developing > a program that used Open Look, I would provide some way for the END > USER to add those keyboard accelerators for the menu choices. And everyone else would do it differently. So much for your style guide. > Huh? There are a lot of satisfied Mac users. There are people who LIKE > a one-button mouse. Convince them the user interface and/or the > program needs redesign. They don't need to be convinced. They're happy with the UI. That's why I'm opposed to Open Look or Motif... it's forcing a single (new) UI on folks who are already happy with the one they have. And I see no reason why a program running under the Mac UI should have one line of code different from one running under Motif or Open Look. > >and not even available for the small machines that *can* support it > >(that is, the ones not dependent on intel's brain-dead processors). > Shrug. It was your decision to buy an Amiga. Bug Commodore for Unix V.4. And what about all the people with Macs? Or even Atari STs? Should they dump Finder and Gem? Maybe they like their own UIs... Actually the Amiga is better off than most home computers here. V.4 has been shown, and NeWS runs under AmigaOS. It's just not available for said political reasons. Or are you saying that if you can't afford a 5-10 grand workstation you aren't worth paying attention to? -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Tue Jan 2 16:40:07 1990 Date: Tue, 2 Jan 90 16:40:07 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <18YA-8xds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > Perhaps. Does this happen in practice, though? I think we can all agree > that it does happen in X. And X doesn't even have the option of sharing > resources when they're desirable... sure, you can use shared libraries, > but that doesn't help when you're dealing with multiple machines. This > is a networked window system, after all. > > And X doesn't leave a channel for the user to install enhanced gadgets, > except by at least relinking all their programs. Most of the NeWS applications I have seen posted here download their own UI code into the server without even expecting any other application will use these features. I remain adamant that the problem can only be solved by the adoption of a common toolkit that all application writers can link against. Work in this area is moving much faster under X than under NeWS. In any case, I expect the underlying system will not be very important once a dominant toolkit (like Motif) becomes commonplace. It is true that NeWS has a slight memory advantage if a user uses several applications each running on a different machine. However, due to the use of shared libraries, the savings is proportional to the number of machines not the number of applications and is thus reasonably small. With an appropriate implementation of shared libraries, it may even be possible to install enhanced gadgets without relinking (since some runtime binding is required to implement shared libraries). All in all, the differences are minor. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) From don Tue Jan 2 16:41:30 1990 Date: Tue, 2 Jan 90 16:41:30 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: diamond.bbn.com!mlandau@bbn.com (Matt Landau) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) bob@MorningStar.Com (Bob Sutterfield) writes: >(Bob starts the new year by diving into a flamefest :-) (Bob starts the new year by saying some remarkably reasonable things :-) > The place where Sun botched it was in not doing a "sample > implementation" of NeWS and making it publicly available >Right! And it's surprising that their marketeers didn't see that. >Enough people at the time were offering such suggestions as free >advice, one wonders why Sun didn't listen. It's too late now. Maybe not. I recently learned first-hand the degree to which customer opinion really can make a difference in Sun corporate policy. It's a little-known fact that until quite recently (the last couple of weeks), Sun had OpenWindows on a tight allocation policy, which is why people who'd ordered it months ago were still waiting for their tapes. At the recent Sun User Group conference, several of us got wind of this fact, and we were rather ... ahem ... "outspoken" ... in our opinion that this was a critical tactical mistake, and tantamount to suicide for both NeWS and Open Look. Basically, lots of people complained real loudly about this brain-dead policy (I spent about 45 minutes talking to Carl Wolf in the gripe booth, and another 30 talking to Scott McNealy; other people raised the issue in the public question-and-answer sessions and the executive roundtable.) The result was that, according to a piece of mail I got from a friend inside Sun, OpenWindows has been taken off allocation and will ship to all customers who order it. What's the point? The point is that if enough people make enough noise, things can change. Now ask yourself what might happen if Sun were to donate the source to X11/NeWS to the MIT X Consortium, just for the sake of promoting it as a superior technology that wasn't under Sun's complete control anymore... After all, Sun's done something similar with control of the Sparc processor architecture... And AT&T is doing something vaguely similar with SvR4... So ask yourself what might happen if X11R5 (or X12 or something) were based on the merged NeWS/X server... Then ask yourself how we might make this happen... From don Tue Jan 2 16:42:17 1990 Date: Tue, 2 Jan 90 16:42:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: Help: Event interests From: rochester!uhura.cc.rochester.edu!ur-valhalla!bobm@rutgers.edu (Bob Molyneaux) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi all; I can't seem to master the "niceties?" of NeWS beyond basic window creation, drawing, menues etc. I could use a quick tip. Problem: The default status of the left mouse button *in* the canvas region is null. I have an application which is menue driven. Upon selection of a certain menue entry I would like to activate interest in the left mouse button. I wish to cause the clicking (Down and or Up Transition) of the left button to return the currentcursorlocation to my C client in order that the object which is being pointed to in the display may be identified. I am using C and .CPS files to implement the application. The cursorlocation could be stored in cps variables and passed to the client easily. I just don't know how to cause the left button (or any event) do what I want. I would like to be able to alter the action taken by the left button at a later time according to some other menue selection as well as return the button to its default state. Should blockinputqueue be used to halt other input which may occur between the time of the left button click to the time the process is ready for more input?? Yes I have a NeWS manual. No I don't understand more than 50% of it. Email me at bobm@ee.rochester.edu or reply via this newsgroup. Thanks in advance for any help. ******************************************************************************** bobm@ee.rochester.edu ******************************************************************************** From don Tue Jan 2 16:49:27 1990 Date: Tue, 2 Jan 90 16:49:27 -0500 To: NeWS-makers@brillig.umd.edu Subject: obsolete arguments against NeWS From: don (Don Hopkins) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Date: 2 Jan 90 03:00:24 GMT >From: pasteur!ic.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >I am afraid I disagree with the arguments expressed here. The problem >truely lies in toolkits and policy. In order for memory savings to >take place, programs *must agree* to use the same features. Otherwise, >using the NeWS paradigm, each program will download its own features >into the server and you will have a gigantic server where little or >no sharing occurs. > >Furthermore, the problem is *identical* for both NeWS and X. Both >systems provide fairly low-level user interface programming facilities. >Both systems require higher level facilities in order to quickly build >real-world user interfaces. The solution is to have programs agree >on a toolkit. How can you get programs to agree on a toolkit if you can get the people who write and use the them to agree on one? Right now, I'd rather have a *GOOD* toolkit, than a *STANDARD* toolkit. Once there is such a thing as a good toolkit, then we can start talking about standards. >The memory savings will be the same under both systems: >- Under NeWS, toolkit facilities will be downloaded to the server where > possible and applications will link against a shared library for > client side facilities. NeWS applications share more than just the toolkit code. They share lots of runtime data, and even event managers (light weight NeWS processes). >- Under X, applications will link against a shared library for most > toolkit functionality and may use server extensions (if present). > And if the extensions are not present, you lose. I refer you to the thread in comp.windows.x about the impossibility of running anything that depends on Display PostScript on an X terminal or other workstation not supporting DPS. Under X, extensions are linked into the server during the entire session, even if you don't need them, but if you don't have a needed extension, you lose. Under NeWS, you don't have to load an extension until it's needed, and when you need it, you only have to load it if it's not already there. (For example, UniPress Emacs comes up much faster the second time you run it since it doesn't have to load its NeWS driver again.) It's even possible to un-load extensions you don't need any more. >In both cases, applications will share the toolkit code. The sum >of server size and client size should be roughly equivalent. What about the sum of server size plus the size of *each* client? As a contrived example, it would take less resources to run 10 NeWS performance monitors on 10 different machines than to run 10 X performance monitors on 10 different machines, especially if each X performance monitor had to link against the X toolkit to provide a "QUIT" button (with all the un-shared run time client side toolkit data structures that involves). >My point is that there is nothing fundamental about NeWS that makes >this problem any easier. Furthermore, in my opinion, there are some >problems in the NeWS model that make it harder to develop a general >purpose toolkit that meets the needs of a wide range of application >developers. I have posted these problems before in this newsgroup so >I won't repeat them here. > > David Harrison > UC Berkeley Electronics Research Lab > (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) Besides the fact that some of your arguments are obsolete with the introduction of X11/NeWS, I disagree that your objections have anything to do with the difficulty of developing a general purpose toolkit. In fact there are a lot of fundamental differences between NeWS and X that make toolkit development in NeWS easier, that have been discussed before on this mailing list. I will repeat your points myself. >Date: Wed, 7 Sep 88 10:14:09 EDT >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >1. No primitives for modifying colormaps. Fixed in the merge. (visual, colormap, and colormapentry data types) >2. No support for plane masks on multi-plane devices. Fixed in the merge. (setplanemask operator) >3. No support for interlocked tiling of filled regions. >[...] I don't know if this problem has been or will be addressed. Anybody who knows care to comment? >Date: Sat, 16 Apr 88 00:39:57 EDT >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >1. Raster operations other than copy or xor. >[...] That's been in NeWS since 1.0. (setrasteropcode) Its use is considered poor form. (I learned that the hard way when porting the UniPress Emacs NeWS interface to the Silicon Graphics 4D -- It was trying to blink, using exclusive-or for the visual bell, and since such rasterops require reading pixels back from the screen, and the CPU couldn't access the graphics memory directly but had to go through the graphics processor, it took a couple seconds to blink the window! Yes, this is the same machine that runs that excellent flight simulator in real time. If you depend on reading pixels back off the screen, then you are going to lose big time on certain types of hardware. {the fix was to use the NeWS overlay plane abstraction, but then it blinked much too fast, so I had to put in a short sleep.}) >Date: Mon, 15 Feb 88 10:55:17 EST >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >Raw Rendering Speed > > I am not convinced that the raw drawing speed of Postscript > based graphics interfaces is sufficient. Postscript was designed > as a page description language. Unfortunately, CAD of ICs > does not fit into this view of the world very well. Most > implementations of Postscript (and I assume NeWS) are very > good at rendering fonts and line drawings. Views of a large > integrated circuit have very little text but thousands of filled > boxes, polygons, and circles. So far, I have seen little > indication that any emphasis is being placed on this type > of graphics in Postscript or NeWS. You should see NeWS running on a Sparcstation with a GX accelerator, or the Silicon Graphics with its special graphics hardware. NeWS programs can take advantage of graphics accelerators like the GX board that speed up PostScript graphics, without any modification [modulo problems caused by the use of antisocial, device dependant operators like setrasteropcode, as described above]. >On a more personal note, I tend to like the amount of control given >by X. And I tend to like the ammount of power given by NeWS. It's because of people like you and people like me that Sun merged X11 and NeWS. Now I can play my games with the PostScript interpreter in one window, and still experience psychodellic colormap flashes whenever I move my cursor into a window running one of your X applications. >Until we understand more about modeling device independent >graphics, I feel we must have enough control over the device to try >out new approaches. As so many East European dictators have learned, total control is *not* necessarily a good thing. (Although one thing we have learned from the reign of X is what happens when you mix window systems and politics!) There are good reasons for window system application writers to give up direct control of their hardware. (Have you ever tried to port a program from an IBM-PC to a real computer?) >Finally, I have a nasty feeling about developing highly >interactive applications in a graphics environment based on an output >only graphics standard. There's nothing "output only" about NeWS. Adobe's non-cooperation certainly hasn't stopped Sun from coming up with well designed interactive extensions to PostScript. >The X team has put a lot of time into input >handling and event generation. I have a bad feeling that certain >interfaces may not be realizable in NeWS. > > David Harrison > (davidh@ic.Berkeley.EDU) > UC Berkeley Electronics Research Lab It's been almost two years since you said that. Has your bad feeling been confirmed? I think the NeWS input model is more general than the X input model, since PostScript processes can respond to events locally in the server, and there are no restrictions on the format of the data they send over the wire. There are certain types of interfaces that X is horrible at (like interfaces to remote applications at less than ethernet speeds, that provide responsive feedback.) -Don From don Wed Jan 3 03:41:29 1990 Date: Wed, 3 Jan 90 03:41:29 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: obsolete arguments against NeWS From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Some of you may receive this posting twice due to my error. My apologies. David Harrison>The solution is to have programs agree on a toolkit. Don Hopkins>How can you get programs to agree on a toolkit if you can get the Don Hopkins>people who write and use the them to agree on one? Right now, Don Hopkins>I'd rather have a *GOOD* toolkit, than a *STANDARD* toolkit. Once Don Hopkins>there is such a thing as a good toolkit, then we can start talking Don Hopkins>about standards. Here we agree. I too would prefer a good toolkit over a standard one. However, the problem of orthogonal UI development libraries and the resulting large applications and servers will not go away until a standard toolkit is adopted. Besides, I will stick by my argument that the underlying system (either NeWS or X) make very little difference when developing a good toolkit (or a standard toolkit). In the final analysis, I think the underlying system will make little difference in general to application programmers once a successful toolkit appears on the scence. Most application programming will be done at the toolkit level and not at the window system level. dk>NeWS applications share more than just the toolkit code. They share dk>lots of runtime data, and even event managers (light weight NeWS dk>processes). Perhaps I am missing something but it seems to me that the code and resources applications share is the definition of a UI toolkit. Even under X, toolkit applications share resources other than code. dsh>- Under X, applications will link against a shared library for most dsh> toolkit functionality and may use server extensions (if present). dk>And if the extensions are not present, you lose. I refer you to the dk>thread in comp.windows.x about the impossibility of running anything dk>that depends on Display PostScript on an X terminal or other dk>workstation not supporting DPS. dk> dk>Under X, extensions are linked into the server during the entire dk>session, even if you don't need them, but if you don't have a needed dk>extension, you lose. Under NeWS, you don't have to load an extension dk>until it's needed, and when you need it, you only have to load it if dk>it's not already there. (For example, UniPress Emacs comes up much dk>faster the second time you run it since it doesn't have to load its dk>NeWS driver again.) It's even possible to un-load extensions you dk>don't need any more. I agree NeWS has a better model for incremental extensibility than X. However, it is a two-edged sword and there are definite tradeoffs. Extensions downloaded into NeWS incrementally are interpreted. A 3-d enhancement package like PEX downloaded in this fashion would be much too slow to be useful. Of course this kind of extension could be "built in" to the server. This is exactly the problem X addresses with its extension mechanism. Not all enhancements to a server lend themselves to interpretation or the restrictions imposed by the Postscript imaging model. dsh>In both cases, applications will share the toolkit code. The sum dsh>of server size and client size should be roughly equivalent. dk>What about the sum of server size plus the size of *each* client? I mentioned this in a followup article in comp.windows.news. There is indeed a savings for NeWS applications that is proportional to the number of different machines used. This number is fairly small under most conditions and thus the savings are minimal. Don continues by mentioning some of the problems I have found with NeWS and how they are fixed in the new OpenWindows server. I am pleased these problems have been addressed. Personally, had they been addressed two years ago and had NeWS been more widely available, I might have chosen it for our application. One in particular requires some comment: dsh> I am not convinced that the raw drawing speed of Postscript dsh> based graphics interfaces is sufficient. Postscript was designed dsh> as a page description language. Unfortunately, CAD of ICs dsh> does not fit into this view of the world very well. Most dsh> implementations of Postscript (and I assume NeWS) are very dsh> good at rendering fonts and line drawings. Views of a large dsh> integrated circuit have very little text but thousands of filled dsh> boxes, polygons, and circles. So far, I have seen little dsh> indication that any emphasis is being placed on this type dsh> of graphics in Postscript or NeWS. dk>You should see NeWS running on a Sparcstation with a GX accelerator, dk>or the Silicon Graphics with its special graphics hardware. NeWS dk>programs can take advantage of graphics accelerators like the GX board dk>that speed up PostScript graphics, without any modification [modulo dk>problems caused by the use of antisocial, device dependant operators dk>like setrasteropcode, as described above]. The merged server has promise simply because it allows you to use X for graphics intensive work. I don't want an interpreter in the way when I dump fifty thousand stippled rectangles into a window. As far as machines go, I find the performance of my color DECstation 3100 running X very satisfying (especially when compared to any color Sun with or without accelerator). dsh>The X team has put a lot of time into input dsh>handling and event generation. I have a bad feeling that certain dsh>interfaces may not be realizable in NeWS. dk>It's been almost two years since you said that. Has your bad feeling dk>been confirmed? The lack of serious NeWS applications still makes this point an open question. It may now remain open since the two models have been merged. In my own development, I have found the X model sufficient for the tasks at hand with no major blocks to forward progress. When I looked at NeWS (and many of these points have been addressed), I could not say the same thing. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) From don Wed Jan 3 03:45:32 1990 Date: Wed, 3 Jan 90 03:45:32 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: bogus arguments, whether pro or con From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Under X, extensions are linked into the server during the entire session, even if you don't need them Gee, I guess you've never even looked at an NCR Towerview. It sure would be nice if this community got their facts straight. So many bogosities have passed on this list as "fact" for the past few days, I can't even begin to count them. From don Wed Jan 3 04:08:52 1990 Date: Wed, 3 Jan 90 04:08:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: cs.utexas.edu!wuarchive!texbell!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Most of the NeWS applications I have seen posted here download their > own UI code into the server without even expecting any other application > will use these features. Well, except for the stuff that is designed to globally modify the environment, like pie menus. Or I think it was Bruce who brought up rounded windows. And NeWS has another big advantage... if you put enough of the UI in the server, you don't have to munge the rest of the program into the X event loop/callback mould. > I remain adamant that the problem can only > be solved by the adoption of a common toolkit that all application > writers can link against. Yes. yes yes. In fact I think that's pretty much what I've been saying. Or at least that's what I think I've been saying. Oh, you get the idea. > Work in this area is moving much faster > under X than under NeWS. In any case, I expect the underlying system > will not be very important once a dominant toolkit (like Motif) becomes > commonplace. Is Motif a toolkit or an interface? I got the impression that it's just a style guide like OpenLook. A dominant standard toolkit is something I'd like to see very much... but should it be so tightly tied to X? In programming in X, the UI tends to dominate the app. This tends to lead to unfortunate consequences. Like, say you want a program to go away for a while and do some work. Under X you lose the UI... and you can't even put up an "I'm busy" sign because it won't get displayed until you return to the event loop. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com From don Wed Jan 3 04:09:49 1990 Date: Wed, 3 Jan 90 04:09:49 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: cbmvax!jesup@rutgers.edu (Randell Jesup) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4355@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >The problem the PC's users are facing is evolution. Remember when some >"expert" said that 64K was enough for any application? The future PC >will be a 486 with 4 Megs of memory for under $1000. You'll see X and NeWS >on PC's once some vendor ships Unix V.4. Or maybe an '030 or '040 with 4 Meg... BTW, we (Commodore) already have announced (and demoed in NYC) Sys V.4 for the Amiga 2500 (admittedly not $1000 yet). X is also available for the Amiga and shipping (doesn't require Unix, or even an '020/'030). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!" From don Wed Jan 3 04:17:25 1990 Date: Wed, 3 Jan 90 04:17:25 -0500 To: NeWS-makers@brillig.umd.edu Subject: bogus arguments, whether pro or con From: don (Don Hopkins) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: Tue, 02 Jan 90 17:04:30 -0500 From: rws@expo.lcs.mit.edu (Bob Scheifler) Under X, extensions are linked into the server during the entire session, even if you don't need them Gee, I guess you've never even looked at an NCR Towerview. No I haven't. I'd like to know how it works, if somebody would like to explain. Do I understand that NCR has a meta-extension for loading and unloading server extensions dynamically? Is it in the form of a standard X extension that I could link into, say, an X11/NeWS server? Or does it require server modification, and/or operating system support? (And of course, is it in R4?) I'll keep an eye out on comp.windows.x ... It sure would be nice if this community got their facts straight. So many bogosities have passed on this list as "fact" for the past few days, I can't even begin to count them. Don't count them, correct them, please! (and thanks!) A lot of messages have passed on this list in the past few days, and I can't even begin to count the bounces. It's holiday season everyone's mailer is on the fritz. I hope people who send mail to NeWS-makers aren't getting as many bounces as I am. I will try to find out what the problems are and fix them soon, but I don't have read permission on the queue files, so I've tried to let the systems staff know about it indirectly... -Don From don Wed Jan 3 06:52:21 1990 Date: Wed, 3 Jan 90 06:52:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: mstan!jordan@uunet.uu.net (Jordan Hayes) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Peter da Silva writes: But first make the easy things easy. "Hello World" in a windowing system shouldn't be more than 10 lines of code. Sigh. When will people learn to code before blabing on USENET? This is in Motif ... == not 10 lines but the meat is only 8 lines ... === main(argc, argv) int argc; char **argv; { Arg sArgs[3]; Display *display; Widget topW; XmString str; XtAppContext app; XtToolkitInitialize(); display = XtOpenDisplay(app = XtCreateApplicationContext(), (String)NULL, "Joe", "Hodedo", NULL, 0, &argc, argv); topW = XtAppCreateShell(NULL, NULL, applicationShellWidgetClass, display, NULL, 0); str = XmStringCreateLtoR("Hello World", XmSTRING_DEFAULT_CHARSET); XtSetArg(sArgs[0], XmNlabelString, (XtArgVal)str); XtManageChild(XmCreateLabel(topW, "label", sArgs, 1)); XtRealizeWidget(topW); XtAppMainLoop(app); } /jordan From don Thu Jan 4 14:33:35 1990 Date: Thu, 4 Jan 90 14:33:35 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" - SunView or OpenWindows??? From: fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) ficc!peter (Peter da Silva) writes: >A dominant standard toolkit is something I'd like to see very much... >but should it be so tightly tied to X? In programming in X, the UI >tends to dominate the app. This tends to lead to unfortunate consequences. >Like, say you want a program to go away for a while and do some work. >Under X you lose the UI... and you can't even put up an "I'm busy" sign >because it won't get displayed until you return to the event loop. >-- Huh? Much as I prefer NeWS to X, in this case I must point out a couple of inaccuracies. While it is true that if the client program is otherwise occupied, it will ignore anything on the event pipeline (they *do* queue up), This can be dealt with by taking advantage of the multitasking nature of the OS. So instead of tightly binding to the toolkit, simply use interprocess communication; or use multi-threading (light-weight processes) if supported by the OS. OK, that's a bit of a hack that I shouldnt *have* to do, and it wont work under MS-DOS (but we are talking *real* OS here), but in practice it isnt that hard, and works just fine. Does this sound like a hack to make X act like NeWS? You bet! And it greatly improves X's manners, which is a great argument for the superiority of the NeWS approach to server design. Secondly the "I`m busy" sign is simple; pop up the stupid thing *before* you go out to lunch. The event loop simply calls the "out to lunch" sign before it goes, and takes it down after it gets back. The event loop is one way; I can send stuff to the server from anywhere, once the connection is established. Indeed, the initial contact and initialization of resources in the server is generally made before the event loop is even started. To make a human analogy, I dont expect to be able to put up my sign after I'm already at the pizzeria; I do it on my way out. Tom Dockery Market Focus Technologies From don Thu Jan 4 14:34:44 1990 Date: Thu, 4 Jan 90 14:34:44 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: event-driven applications From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Like, say you want a program to go away for a while and do some work. Under X you lose the UI... and you can't even put up an "I'm busy" sign because it won't get displayed until you return to the event loop. Another over-generalization that seems typical for this list. "X" is a whole lotta things these days. To claim that all instances of X applications are single-threaded and strictly event-driven, in the canonical manner of Xt, is rather silly. There are multiple researchers out there working with X on the client side in a multi-threaded environment; there are even one or two products that work this way. Whether a multi-threaded client environment is better or worse than a single-threaded client with multi-threaded server is rather debateable, I'd say. The design of Xt was a concious one, for its portability across a wide range of systems. Clearly the model isn't adequate for all applications; that's good, it was an engineering solution. From don Thu Jan 4 14:35:13 1990 Date: Thu, 4 Jan 90 14:35:13 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: bogus arguments, whether pro or con From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Do I understand that NCR has a meta-extension for loading and unloading server extensions dynamically? It has a mechanism, yes. I don't know the implementation details. Is it in the form of a standard X extension that I could link into, say, an X11/NeWS server? There is no notion of a "standard X extension", in terms of implementation binaries or standardized internal interfaces, at least not right now. Or does it require server modification, and/or operating system support? I would say most interesting X extensions (3D, video, overlays, double-buffering, nonrectangular windows, input devices, shared memory) have required some amount of server modification and/or hardware/OS support. Don't count them, correct them, please! (and thanks!) I seldom have time to be more than annoyed/amused at this list, sorry. From don Thu Jan 4 14:35:56 1990 Date: Thu, 4 Jan 90 14:35:56 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm not sure that X is so fixed in concrete that some of the things you find bothersome could not change. I find InterViews almost equivalent to PostScript in terms of 'imaging power' and yet flexible enough to do low level stuff.. and there is no interpreter nor the restrictions of a 'page description' paradigm. I like the look and feel of Motif more than OpenLook as a 'style guide', but I think in terms of functionality InterViews has them beat.. particularly with their new Unidraw graphical object/'widget' editor. I have yet to see anything like this come from NeWS. I see NeXT with their NeXTStep and Display Postscript as being a more serious challenge to X and all other window systems than NeWS. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| From don Thu Jan 4 14:36:34 1990 Date: Thu, 4 Jan 90 14:36:34 -0500 To: NeWS-makers@brillig.umd.edu Subject: Roll EM Demo From: dreams!rbogen@sun.com (Richard Bogen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) % This toy program demonstrates cycloids which are curves % traced out by a fixed point attached to one curve which % rolls on the inside or outside of another. In this case % it is a circle rolling on another circle. The fixed point % is the endpoint of a line attached to the center of the % rolling circle. % % I wanted to use an overlay canvas to keep the picture of % the rolling circle separate from the cycloid curve which % is traced out but had problems when rapidly switching % back and forth between a canvas and its overlay. % % If anyone can make improvements to this program I would % greatly appreciate receiving them. % % Richard A. Bogen - Sun Microsystems, Inc. - 1/3/90 % % SAVE THIS FILE AS cycloids.ps; then psh it. %-------------------------------------------------------------- /xsize 1152 def /ysize 900 def /cx xsize 2 div def /cy ysize 2 div def /q 1 def % the amount in degrees to rotate on each iteration /t 0 def % the angle of the line on the rolling circle /oldx -1 def /Color 0 0 1 rgbcolor def % change to your favorite color /titlefont /Helvetica-Bold findfont 30 scalefont def /descrfont /Times-Italic findfont 24 scalefont def /dotitle {titlefont setfont 0 cy 50 sub moveto erasepage (Demo of Epi & Hypo Cycloids) cshow descrfont setfont 0 cy 100 sub moveto cshow 0 cy 130 sub moveto } def % Lets have a fullscreen! /can framebuffer newcanvas def cx cy translate cx neg cy neg xsize ysize rectpath can reshapecanvas can setcanvas can /Mapped true put /ov can createoverlay def (Drag mouse to choose size of diameter of fixed circle) dotitle (Click any mouse button to end selection) cshow 0 0 moveto (+) show ov setcanvas /circle {newpath 0 360 arc stroke} def /circle1 {dup mul exch dup mul add sqrt /r1 exch def newpath 0 0 r1 0 360 arc } def 100 0 setcursorlocation 0 0 {circle1} getanimated waitprocess aload pop can setcanvas (Drag mouse to choose size of diameter of rolling circle) dotitle (Click any mouse button to end selection) cshow circle1 stroke 0 0 moveto (+) show ov setcanvas /circle2 {pop dup r1 sub /r2 exch def newpath 0 r2 0 360 arc } def r1 50 add 0 setcursorlocation 0 0 {circle2} getanimated waitprocess aload pop can setcanvas (Drag mouse to choose length of line attached to center) dotitle ( of rolling circle. Click any mouse button to start demo) cshow 0 0 r1 circle 0 0 moveto (+) show circle2 stroke /s r1 r2 add def /a r1 r2 div q mul def ov setcanvas s 25 setcursorlocation s 0 {lineto} getanimated waitprocess aload pop can setcanvas dup mul exch s sub dup mul add sqrt /d exch def (After viewing output click any mouse button to exit demo) dotitle 0 0 r1 circle createevent dup begin /Name [/LeftMouseButton /MiddleMouseButton /RightMouseButton] def /Canvas can def end expressinterest {pause .9 setgray s 0 r2 circle s 0 moveto t cos r2 d add mul neg t sin r2 d add mul .5 setgray rlineto currentpoint stroke Color setcolor oldx -1 ne {oldx oldy moveto 2 copy lineto stroke} if /oldy exch def /oldx exch def /t t a add def countinputqueue 0 gt {exit} if q rotate } loop /delta .03 def initmatrix 8 { erasepage 0 0 moveto (That's All Folks!) cshow delta sleep /delta delta 1.5 div def 0 -20 translate} repeat framebuffer setcanvas can /Mapped false put From don Thu Jan 4 14:39:38 1990 Date: Thu, 4 Jan 90 14:39:38 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm not sure that X is so fixed in concrete that some of the things you find bothersome could not change. I find InterViews almost equivalent to PostScript in terms of 'imaging power' and yet flexible enough to do low level stuff.. and there is no interpreter nor the restrictions of a 'page description' paradigm. I like the look and feel of Motif more than OpenLook as a 'style guide', but I think in terms of functionality InterViews has them beat.. particularly with their new Unidraw graphical object/'widget' editor. I have yet to see anything like this come from NeWS. I see NeXT with their NeXTStep and Display Postscript as being a more serious challenge to X and all other window systems than NeWS. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| From don Thu Jan 4 14:40:12 1990 Date: Thu, 4 Jan 90 14:40:12 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: hplabsz!mayer@hplabs.hp.com (Niels Mayer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <634@s5.Morgan.COM> jordan@Morgan.COM (Jordan Hayes) writes: > But first make the easy things easy. "Hello World" in a > windowing system shouldn't be more than 10 lines of code. >Sigh. When will people learn to code before blabing on USENET? >This is in Motif ... > >== not 10 lines but the meat is only 8 lines ... === > Well, you can easily do a "hello world" in WINTERP in less than 10 lines. WINTERP is an interpretive environment for rapid prototyping applications using the Motif UI toolkit. It is based on the mini-lisp interpreter XLISP and makes extensive use of XLISP's object system as the application programmers interface to Motif. It is available for free on the X11r4 tape or via anonymous ftp from expo.lcs.mit.edu:contrib/winterp.tar.Z. You might think of WINTERP as client-side NeWS without the imaging model (??). Or you might think of WINTERP as a gnuemacs-like prototyping environment that uses widgets as it's primary UI interactor rather than textual buffers.... ---------- The following is an excerpt from a previous posting to comp.windows.x containing a 9 line hello world: ... WINTERP makes extensive use of XLISP's Smalltalk-like extensions for object oriented programming: All the Motif widget classes are actually implemented as XLISP classes, Xtoolkit functions become methods on the widget base class. Motif "Convenience Functions" become methods on particular classes. Because Motif Classes look like normal XLISP classes inside WINTERP, you may extend the functionality of existing widget classes in Lisp via subclassing, or by adding new methods to existing widget classes. Example -- evaluating the following form in WINTERP results in the display of a "hello world" window which sends me mail and prints "hello world" on stdout each time the button is clicked: (let* ((top_w (send TOP_LEVEL_SHELL_WIDGET_CLASS :new :XMN_TITLE "hello world" ;note auto string->XmString conv :XMN_ICON_NAME "hello world")) ;ditto (but_w (send XM_PUSH_BUTTON_WIDGET_CLASS :new :managed top_w :XMN_FONT_LIST "8x16"))) ;note auto string->FontList cv (send but_w :add_callback :XMN_ARM_CALLBACK '() '((system "echo \"Hello World Run!\" | mailx mayer@hplabs.hp.com") (format t "hello world\n"))) (send top_w :realize)) Once the "hello world" window is displayed, you can interactively modify the look and the functionality of the interface. For example, lets say I want to change the color of a widget on the display -- I give WINTERP the following command: (send (get_moused_widget) :set_values :XMN_FOREGROUND "white" :XMN_BACKGROUND "blue") and then click on the pushbutton widget created above. One can use the same technique to interactively change a widget's callbacks, eventhandlers, etc. For further information, take a look at the WINTERP source distribution's "examples" directory. Interesting mini-applications include a bitmap browser, a MH-based mail browser, and a grep-based file search browser. Other examples show you how to contruct menus, radio-boxes, etc. ... ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. * From don Thu Jan 4 14:41:11 1990 Date: Thu, 4 Jan 90 14:41:11 -0500 To: NeWS-makers@brillig.umd.edu Subject: What is UNIX? Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows?? From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > >Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. > I believe the above three define the label UNIX. I don't. UNIX is a family of operating systems based on a uniform device interface concept, with a common programming interface and a common set of utilities. I'm writing this message on a System-III based Xenix box. I could be using anything from a PC-XT running Minix to a Sequent Balance running whatever they run... and the system would look pretty much the same. Here you are saying "X is just a label", when it's even more closely tied into the implementation than UNIX, and then pegging UNIX as BSD+SYSV. I wish you were right. Because X is a horrible design. The first rule of system design is: make the easy things easy, then make the hard things possible. This is best done by providing a simple unifying concept that defines the system. I've not heard a lot about Apollo Domain, but what I have heard is typical of pre-UNIX proprietary systems: lots of complex system calls and data structures, I/O tied closely to the hardware. And X is certainly complex to use. Am I wrong? What's the simple unifying concept for DomainOS? Or X? -- _--_|\ Peter da Silva. +1 713 274 5180. . / `-_-'\ Also or \_.--._/ v From don Thu Jan 4 16:13:08 1990 Date: Thu, 4 Jan 90 16:13:08 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: shlump.nac.dec.com!riscy.dec.com!fuel.dec.com!graham@decwrl.dec.com (kris graham) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <13324@granite.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > Now ask yourself what might happen if Sun were to donate the source to > X11/NeWS to the MIT X Consortium, just for the sake of promoting it as a > superior technology that wasn't under Sun's complete control anymore... > After all, Sun's done something similar with control of the Sparc processor > architecture... And AT&T is doing something vaguely similar with SvR4... > So ask yourself what might happen if X11R5 (or X12 or something) were > based on the merged NeWS/X server... Then ask yourself how we might make > this happen... I have heard a lot about the so-called "Technical Superiority" of NeWS. Anybody care to educate us non-believers of this claim. I have never thought of Postscript as a friendly language to program in.....or love a windowing system that makes the implementation of a print screen facility more tedious than necessary ; BTW: On a more cynical note, we all know the outcome of the "SPARC versus XXX" 'technical superiority" battle ;-) One of my co-workers, Larry Timmins, has been involved in multiple ports of applications originally done with Sun's toolkits. On average, for every six months (calendar time) that the customer/software house put into the project, only one month was needed with DECwindows' XUI toolkit. Using the Intrinsics -based toolkit reduces the network requests and ultimately has proven itself over and over. Regarding the donation of X11/NeWS, fine -- put it in the contrib like others have. However, when OSF went with the XUI toolkit, it was a fully tested production -quality toolkit at over 300 sites. What is needed is solid incremental contributions and not yet another toolkit, approach, etc. Christopher Graham Digital Equipment Corp Ultrix Resource Center New York City Internet: graham@fuel.enet.dec.com UUCP: ...!decwrl!fuel.enet.dec.com!graham I speak as an individual, not representing any organisation or company. From don Thu Jan 4 16:16:26 1990 Date: Thu, 4 Jan 90 16:16:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Is SUN a "PURE PLAYER" - SunView or OpenWindows??? From: brewer@antares.mcs.anl.gov Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) fajita!jalapeno!doc@suntan.West.Sun.COM (Tom Dockery) writes >ficc!peter (Peter da Silva) writes: >>A dominant standard toolkit is something I'd like to see very much... >>but should it be so tightly tied to X? In programming in X, the UI >>tends to dominate the app. This tends to lead to unfortunate consequences. >>Like, say you want a program to go away for a while and do some work. >>Under X you lose the UI... and you can't even put up an "I'm busy" sign >>because it won't get displayed until you return to the event loop. >>-- [Some stuff deleted] >Secondly the "I`m busy" sign is simple; pop up the stupid thing >*before* you go out to lunch. The event loop simply calls the "out to >lunch" sign before it goes, and takes it down after it gets back. The >event loop is one way; I can send stuff to the server from anywhere, >once the connection is established. Indeed, the initial contact and >initialization of resources in the server is generally made before the >event loop is even started. To make a human analogy, I dont expect to >be able to put up my sign after I'm already at the pizzeria; I do it on >my way out. But how about something like continously updating a counter or some informational text while the application is doing its work? I want to be able to change something on the screen while the application is working in order to let the user know how the processing is going (i.e. number of things done, what it is currently doing, etc.). I'm sure there is probably a hack to do it, but what a pain in the ass. I don't want to program a workaround for every little thing like that. (And please don't anyone tell me its a "feature"; which reminds me of my favorite X windows joke: Q. How do most X programmers spend their time? A. Programming workarounds to X windows "features.") Orlie Brewer Mathematics and Computer Science Division, Argonne National Laboratory 9700 South Cass Avenue, Argonne, Illinois 60439 (312) 972 - 5094, brewer@mcs.anl.gov From don Thu Jan 4 16:17:18 1990 Date: Thu, 4 Jan 90 16:17:18 -0500 To: NeWS-makers@brillig.umd.edu Subject: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: don (Don Hopkins) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Date: Thu, 4 Jan 90 14:39:38 -0500 From: Peter W. Brewer I'm not sure that X is so fixed in concrete that some of the things you find bothersome could not change. I find InterViews almost equivalent to PostScript in terms of 'imaging power' and yet flexible enough to do low level stuff.. and there is no interpreter nor the restrictions of a 'page description' paradigm. I haven't used InterViews, so I'm not familiar with its imaging model and flexability. I don't know what you mean by "page description' paradigm, would you please explain? Does it have anything to do with device independance, printer compatibility, etc? I see having an interpreter as an advantage! I think WINTERP is an excellent idea, and I'd love to have a version of WINTERP with an interface to the NeWS toolkit. Extensibility is as useful on the client side as it is on the server side! What NeWS really needs is a way to dynamically link object files containing compiled primatives into the server at run time. (There was an *extremely* undocumented primative for just that purpose called "dynoload" in a beta version of NeWS 1.1 once, but I haven't seen it since. It's certainly possible, just not portable. [I guess we should just wait for PCR...]) I like the look and feel of Motif more than OpenLook as a 'style guide', but I think in terms of functionality InterViews has them beat.. particularly with their new Unidraw graphical object/'widget' editor. I have yet to see anything like this come from NeWS. I see NeXT with their NeXTStep and Display Postscript as being a more serious challenge to X and all other window systems than NeWS. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| Have you tried GoodNeWS, by Arthur van Hoff of Turing Institute? It's a window system built on top of NeWS, that includes a very nice PostScript drawing editor (and lots of other useful stuff like a LaTeX previewer that lets you place your GoodNeWS drawings in your documents.) *AND IT'S ALL FREE!!!* (available via anonymous ftp from tumtum.cs.umd.edu) Agreed, NeXTStep and Display PostScript are serious challenges to a lot of people, places, and things. (It doesn't hurt having H. Ross Perot fighting for your cause.) IMOH, it remains to be seen how flexable and easy to use the NeXTStep window system is. I had a wonderful argument with Jobs at EduCom about it, and he claimed they had tried all kinds of different user interface techniques and done all sorts of usability studies that showed that NeXTStep was incredibly easy to use. I'd like it if they'd publish those usability studies, and included the source to the window system in case I didn't agree with them, since I still haven't figured out a way to interact with a window that's partially covered up by another window, or how to type into a window without clicking on it and bringing it to the top. Enforced click-to-type is a throwback to the MacIntosh. Make it an option or make it so I can fix the problem! The interface builder looks very nice, but I don't know the merits of the toolkit it's built on top of. Ohio State did a study showing the interface builder was indeed easy to use. But how easy is it to write an application such that you can build an interface to it? And how easy is it to modify and implement new parts of the toolkit and integrate them with pre-existing applications? I talked with one of the NeXT window techies about implenting pie menus on NeXTStep, gave him some papers on the subject, and encouraged him to do it. I will be impressed if somebody can implement pie menus in NeXTStep (with or without the round windows) as seamlessly as they dropped into NeWS (so every application gets pie menus, without modification). -Don From don Thu Jan 4 17:26:09 1990 Date: Thu, 4 Jan 90 17:26:09 -0500 To: NeWS-makers@brillig.umd.edu Subject: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: don (Don Hopkins) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) >Date: 4 Jan 90 19:05:10 GMT >From: shlump.nac.dec.com!riscy.dec.com!fuel.dec.com!graham@decwrl.dec.com (kris graham) > >In article <13324@granite.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > >> Now ask yourself what might happen if Sun were to donate the >> source to X11/NeWS to the MIT X Consortium, just for the sake of >> promoting it as a superior technology that wasn't under Sun's >> complete control anymore... After all, Sun's done something >> similar with control of the Sparc processor architecture... And >> AT&T is doing something vaguely similar with SvR4... So ask >> yourself what might happen if X11R5 (or X12 or something) were >> based on the merged NeWS/X server... Then ask yourself how we >> might make this happen... Yay verily! GnuWS! >I have heard a lot about the so-called "Technical Superiority" of NeWS. >Anybody care to educate us non-believers of this claim. I have never >thought of Postscript as a friendly language to program in..... >or love a windowing system that makes the implementation of a print >screen facility more tedious than necessary ; Are you refering to the paper "Visualizing X Clients", that "Sgt" David Rosenthal and David Lemke presented at the Winter 1989 San Diego Usenix? >BTW: On a more cynical note, we all know the outcome of the "SPARC > versus XXX" 'technical superiority" battle ;-) > >One of my co-workers, Larry Timmins, has been involved in multiple >ports of applications originally done with Sun's toolkits. Which toolkits?? >On average, for every six months (calendar time) that the >customer/software house put into the project, only one month was >needed with DECwindows' XUI toolkit. Using the Intrinsics -based >toolkit reduces the network requests and ultimately has proven >itself over and over. Reduced network requests over what, SunView??! The NeWS toolkit? Lite? XView? MTV? What was your application, a metacircular prolog interpreter? >Regarding the donation of X11/NeWS, fine -- put it in the contrib >like others have. However, when OSF went with the XUI toolkit, it >was a fully tested production -quality toolkit at over 300 sites. >What is needed is solid incremental contributions and not yet >another toolkit, approach, etc. X11/NeWS is not a toolkit, it is an extensible window system kernel, on top of which many different toolkits can run (including XUI, the NeWS toolkit, GoodNeWS, BTOL (Better Than Open Look), XView, InterViews, and so on...) Richard Stallman is willing to add NeWS to the Gnu distribution tapes were it to become free. Distribution is not the sticky point. I think the main problem now is getting Sun to make NeWS free. It wouldn't be an unprecidented move -- they did it with XView. Sun doesn't have to go as far as copylefting it, and Project Gnu doesn't have to go as far as to maintaining it. People just have to demand it. >Christopher Graham >Digital Equipment Corp >Ultrix Resource Center >New York City By the way, why do you have all those spaces after your name and address? -Don From don Thu Jan 4 22:32:38 1990 Date: Thu, 4 Jan 90 22:32:38 -0500 To: NeWS-makers@brillig.umd.edu Subject: GoodNeWS under OpenWindows From: rbogen@EBay.Sun.COM (Richard Bogen) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Has anyone been able to get GoodNeWS1.2 working under NeWS 2.0 (i.e. OpenWindows 1.0)? I'd love to hear about the experience as I have been unsuccessful. From don Thu Jan 4 22:33:58 1990 Date: Thu, 4 Jan 90 22:33:58 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: mcsun!unido!tub!net@uunet.uu.net (Oliver Laumann) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4572@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > In article <634@s5.Morgan.COM> jordan@Morgan.COM (Jordan Hayes) writes: > > But first make the easy things easy. "Hello World" in a > > windowing system shouldn't be more than 10 lines of code. > >Sigh. When will people learn to code before blabing on USENET? > >This is in Motif ... > > Well, you can easily do a "hello world" in WINTERP in less than 10 lines. [Example program and WINTERP blurb deleted] This is how you would write it in `Elk' Scheme: ;;; -*-Scheme-*- (require 'xwidgets) (load-widgets shell label) (let* ((con (create-context)) (dpy (initialize-display con 'kraftbus:0 'hello 'demo)) (top (create-shell 'hello 'demo (find-class 'application-shell) dpy)) (w (create-managed-widget (find-class 'label) top 'label "Hello world"))) (realize-widget top) (context-main-loop con)) Note that the initialization of the application context and display is somewhat lengthy (by the way, I wonder why the initialization is missing in the WINTERP example). `kraftbus' is the name of the workstation on my desk (yes, the name is weird, if you want me to tell you the anecdote behind it, drop me a letter), so `kraftbus:0' obviously is the display name. One can use #f instead to indicate that the value of the $DISPLAY environment variable is to be used. The `require' form loads the Elk interface to the Xlib, Xt, and the Athena widget set (one would write "(require 'motif)" to load the interface to the OSF/Motif widgets). `find-class' creates a Scheme object of type `widget class' (widget classes are, like widgets and application contexts, first class objects). If the example had used the Athena command widget, one could have added a callback like this: (add-callback w 'callback (lambda (widget) ; do something )) or, using set-values!, (set-values! w 'callback (list (lambda (widget) ...))) -- Oliver Laumann net@TUB.BITNET net@tub.UUCP From don Thu Jan 4 22:34:15 1990 Date: Thu, 4 Jan 90 22:34:15 -0500 To: NeWS-makers@brillig.umd.edu Subject: Paint/Draw/Word Processing programs...??? From: ogicse!goward@decwrl.dec.com (Philip Goward) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hi! I'm looking for MacPaint and MacWrite style software for X or NeWS (preferably in the public domain). Anyone know any location I can obtain these from? Also if anyone out there has a version of troff that runs under X or NeWS and the sources for it are available.... Thanks! (a friend is posting this for me, so) please reply to: John Roberts robertsj@admin.ogi.edu or Cogent Research, Inc. 1100 NW Compton Drive Beaverton, Oregon 97006 (503)690-1450 From don Fri Jan 5 18:06:04 1990 Date: Fri, 5 Jan 90 18:06:04 -0500 To: NeWS-makers@brillig.umd.edu Subject: Window System Extensibility From: intercon!news@uunet.uu.net (Amanda Walker) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <9001042053.AA10511@brillig.UMD.EDU>, don@CS.UMD.EDU (Don Hopkins) writes: > I will be impressed if > somebody can implement pie menus in NeXTStep (with or without > the round windows) as seamlessly as they dropped into NeWS (so > every application gets pie menus, without modification). One of the things that has impressed me about NeWS over X, SunView, and any other window system that I've used except for the Macintosh OS is that it factors out the user interface code from client programs. Under NeWS, the code to draw windows, handle user input events, and so on is determined when the program is invoked, not when it is compiled or linked. This separation of code is the single greatest advantage that NeWS has over X, in my opinion. To take a concrete example, there was a while when I had a Sun 3/50 on my deks running NeWS 1.1 with liteUI. I rewrote and twiddled the UI PostScript code and produced a window system that looked more like a Mac than a Sun, including customizable color icons selectable per window, and so on, without touching a byte of client code. The same binaries that ran on my machine looking like a Macintosh ran on my co-workers machines looking like vanilla liteUI. I don't want half a dozen kinds of windows and UI policies on my screen, each depending on which toolkit the author decided to use. I want to decide what my screen looks like, and have it stay consistent. One of the strengths of Apple's X server for the Mac OS is that it has an option to use the native window system as the X window manager. This means I can have an xterm or whatever that acts just like all of the rest of the windows on my screen. This is a win. With NeWS, this could be taken even farther, since the *server* is responsible for higher levels of user interaction abstraction, such as widget appearance and event handling. If I want to change how a NeWS client interacts with me, I can do it, because these decisions are not decided at compile time, but at invocation time. I find this to be a great advantage over more classical approaches to windowing UIs. If I (or someone else, for that matter) makes an improvement or a change that I want to use, I can, without disturbing anyone else and still have it apply across the board when I'm using even older client software. This is the gem behind all of Sun's marketing hype. Unless I have missed a pretty fundamental shift in philosophy, X does not permit such flexibility. Amanda Walker InterCon Systems Corporation -- From don Fri Jan 5 18:07:01 1990 Date: Fri, 5 Jan 90 18:07:01 -0500 To: NeWS-makers@brillig.umd.edu Subject: Common toolkit (Was Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows???) From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article , peter@ficc (Peter da Silva) writes: >They don't need to be convinced. They're happy with the UI. That's why >I'm opposed to Open Look or Motif... it's forcing a single (new) UI >on folks who are already happy with the one they have. Peter, you first started criticizing Open Look in September, 1988 [article <1587.ficc.uu.net>]. In a mail message to me a month ago, you indicated you still haven't read the style guide. You have a *lot* of chutzpah, Peter. Don't you believe in researching something before you criticize it? You want a high level toolkit that doesn't have a lot of UI in it. One that would be portable across Mac, PC, and Unix machines. What good it is? Who would use it? >Or are you saying that if you can't afford a 5-10 grand workstation you >aren't worth paying attention to? Why would a vendor spend years in developing a toolkit that has no commercial value? One that lobotimizes the *REAL* toolkit they have worked so hard on? One they couldn't GIVE away? Instead, they are writing programs that allow someone to build an application in hours. One that can make proper use of the native window system. An application that has commercial value. This product does makes sense. That's why almost every vendor is developing such a program. A toolkit like the one you want would just be a toy. -- Bruce G. Barnett uunet!crdgw1!barnett From don Fri Jan 5 20:26:13 1990 Date: Fri, 5 Jan 90 20:26:13 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: obsolete arguments against NeWS From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <20973@pasteur.Berkeley.EDU> davidh@dent.Berkeley.EDU (David S. Harrison) writes: The merged server has promise [for applications that need raw drawing speed] simply because it allows you to use X for graphics intensive work. I don't want an interpreter in the way when I dump fifty thousand stippled rectangles into a window. It's my understanding that you'll still have an interpreter in the way when using the merged server. There are two interpretive language frontends on the same internal data structures driving the same display backend. One interprets PostScript and manipulates the internals appropriately, the other interprets the X11 protocol as a simple language (single threaded, no loops or branches, etc.) and also manipulates the internals appropriately. So if your task requires a lot of work of the PostScript interpreter, then indeed it may get in the way. But if the task is characterized more by fondling internals or squirting bits on a screen, the bottleneck moves further back in the pipeline. In that case, requests of both the X interpreter and the NeWS interpreter would experience the same performance. I suspect that your example (50K stippled rectangles) would be interpreted once by NeWS and then handed to the guys in the back room. (But then again, how would I know? We're still waiting for our xnews shipment.) Other tasks are probably better suited to illustrate your point. From don Mon Jan 8 14:41:18 1990 Date: Mon, 8 Jan 90 14:41:18 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? From: zaphod.mps.ohio-state.edu!rpi!crdgw1!grymoire!barnett@tut.cis.ohio-state.edu (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1558@riscy.dec.com> graham@fuel.dec.com (kris graham) writes: |I have heard a lot about the so-called "Technical Superiority" of NeWS. |Anybody care to educate us non-believers of this claim. I have never |thought of Postscript as a friendly language to program in.....or love a |windowing system that makes the implementation of a print screen facility |more tedious than necessary ; Well, PostScript is not a "high level" language, designed to make the programmer's life as easy as possible. Instead, is is a language designed for quickly generating graphical images. There is very little syntactic "sugar" that has been added. So the programmer's job is harder, but the execution is faster because the parsing is simpler. But some of the advantages of NeWS as I see are: 1) the user's program can execute in the server or the client. Or both. One example was mentioned in the Sun Technology article discussing the IBM 3270 emulator with graphic support. Who keeps track of the text and graphics in the window? The implementation desided that the text would be maintained in the client, while the server maintains the graphics. One benefit from this model was that it became possible to redisplay the graphics, changing the position, scaling factor, zooming in our out, changing the colors, etc - WHILE the IBM was still sending new graphics to the server. Another example is all of the NeWS programs that have no client code - the entire application resides in the server. You could have an illustration program work over a low speed modem. You could down load the program to the server, and transfer the diagram back when you are done. but inbetween there would be no network traffic! 2) The Graphics image is PostScript, of course. This gives you automatic scaling and rotation. Also - text is now treated the same as graphics. A text program can be a WYSIWYG editor with little effort. 3) Flexibility - Because the entire window system is based on the PostScript model, there are very few limitations. You can make a new shape, and use it for a cursor, character, icon, button, menu, or window. The distinction between these window concepts is very fuzzy. So you can have "icons" that contain "icons", windows containing windows. The "winwin" program is a simple ROOMS-type extension to the server, allowing you to organize a group of windows and icons into super windows, allowing you to switch between one set of tools and another. A "character" could really be a button or a window. This simplifies a HyperText system, for instance. Don Hopkins has done a lot of "blurring" in this direction. :-) His Pie Menus and HyperText system, for instance. He published some code in this newsgroup that transformed the cursor into a pulsating rainbow. As I also mentioned, you can draw a new thing on the screen, and use it to modify/redefine an existing button, menu choice, window shape, etc. Don also wrote soft menus - some code downloaded to the server that lets you cut/modify and paste menus from one aplication to another. Another example mentioned here was the integration of dozens of workstations to a large "Strategic Command Display". Each user could move the mouse up to the top of his/her workstation, and it would appear on the large display on the far wall, where it could be used to manipulate the information shown to everyone. Also - because of the syntax of PostScript, you can redefine the "reserved words" - well, actually, there are no reserved words in PostScript. You can redefine the entire language on the fly, changing constants into procedures. As an example, I changed the FillColor constant (which colors the background of the window) into a procedure. I made a table that listed machine names and colors. The procedure got the host name the client was running on, and returned a different color for each machine. This let me have several windows on the screen, and all of the icons and windows with a pale green were remote programs on the same system. It only took 10 lines of code downloaded into the server. Note that all of the above DID NOT require any modification of the server. It was done with dynamic extensions. 4) The window system is object oriented. The windows/ icons, buttons are all different objects in the object hierarchy (at least with the tNt toolkit). Subclassing icons and windows is easy. You could subclass every program and define new methods that apply to them. Send them a "refresh", "update" "Print HardCopy", "Return to original position", "revert to original defaults", "save to file", etc. method, much like we send kill signals. And you can add new methods on the fly, like a "send contents to a Laser Printer" or "start collecting a histogram" method to all windows of a certain class. I must admit the ways people have extended X is amazing. There must be a dozen new techniques to add the sort of feature to X that NeWS had all along. (Of course NeWS has evolved too - due to the influence of X). |One of my co-workers, Larry Timmins, has been involved in multiple ports |of applications originally done with Sun's toolkits. On average, for every six |months (calendar time) that the customer/software house put into the project, |only one month was needed with DECwindows' XUI toolkit. Using the Intrinsics |-based toolkit reduces the network requests and ultimately has proven itself |over and over. I don't understand. First of all, Sun has several toolkits. The older applications (SunView) did not have any networking support. I don't see how the number of network requests can be reduced from zero. The NeWS server allows the entire application to reside in the server. If there are a large number of network requests, the code can be re-written to eliminate this. The only other package I know about is XView, which is very new. It supports the older SunView model, in a manner that is easy to convert from SunView to X, but may not be tuned properly. There is a new document that tells people how to convert the old PixWin code to the new Xlib code, making better use of the native technology, instead of using code who's function is backwards compatability. I would like to hear more about this "reduction in network requests", because the argument doesn't ring true. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett From don Mon Jan 8 14:41:40 1990 Date: Mon, 8 Jan 90 14:41:40 -0500 To: NeWS-makers@brillig.umd.edu Subject: SPARCstation: GX or CG3? From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I've received lots of questions from people about whether they should or shouldn't get the GX option on the Sun SPARCstation if they're going to run X, and what the effect on performance is. We had to answer that question for our group; here is some information that you might find useful as part of your decision-making process. The following numbers were obtained using x11perf version 1.2, as distributed in R4. Remember, this is just one set of benchmark numbers, you really need to understand your environment and application requirements to make sense of things. All numbers were obtained on the same physical machine, using the same kernel; GX and CG3 framebuffer boards were just swapped in and out. The machine is a SPARCstation 1, with 16Mb of memory, and a Wren disk for swap, running SunOS 4.0.3. The kernel is "vanilla"; I think there was something about a "segment driver" for the GX in the OpenWindows distribution, but that has not been used, so please take note of that. The servers are the MIT R4 server compiled with the standard Sun compiler, and the OpenWindows 1.0 server. The OpenWindows server was run in X11ONLY mode. The MIT R4 server makes no use of the GX hardware, it simply treats it as a memory frame buffer; the performance characteristics of the GX hardware when used this way are not identical to the CG3 hardware. The main numbers below are the "trep (things/sec.)" numbers as reported by x11perf when run with a -repeat count of 3. The numbers in parentheses are ratios of the given column to column 1, i.e., performance relative to an R4/CG3 base; for example, R4/GX large scrolls are about half as fast as R4/CG3, whereas OW/GX large scrolls are over seven times faster than R4/CG3. Differences of just a few percent should certainly be ignored in making comparisons. I should point out that the pixelization rules used by the OpenWindows server appear to be different than those used by the R4 server for wide lines and solid arcs (and I believe the R4 algorithms match the X protocol specification in most cases); it is unclear what effect this has on performance. 1: MIT R4 on CG3 2: MIT R4 on GX 3: OpenWindows 1.0 on CG3 4: OpenWindows 1.0 on GX 1 2 3 4 Operation -------- ---------------- ---------------- ---------------- ---------------- 155000.0 156000.0( 1.01) 108000.0( 0.70) 112000.0( 0.72) Dot 36900.0 34600.0( 0.94) 5420.0( 0.15) 8330.0( 0.23) 1x1 rectangle 18900.0 15500.0( 0.82) 4750.0( 0.25) 8420.0( 0.45) 10x10 rectangle 682.0 580.0( 0.85) 549.0( 0.80) 5810.0( 8.52) 100x100 rectangle 30.0 26.0( 0.87) 26.2( 0.87) 378.0( 12.60) 500x500 rectangle 17300.0 17700.0( 1.02) 3160.0( 0.18) 2700.0( 0.16) 1x1 stippled rectangle 3200.0 3150.0( 0.98) 1870.0( 0.58) 2450.0( 0.77) 10x10 stippled rectangle 220.0 202.0( 0.92) 87.0( 0.40) 775.0( 3.52) 100x100 stippled rectangle 16.3 14.2( 0.87) 4.2( 0.26) 48.1( 2.95) 500x500 stippled rectangle 22000.0 21600.0( 0.98) 3930.0( 0.18) 2680.0( 0.12) 1x1 opaque stippled rectangle 5010.0 4830.0( 0.96) 1900.0( 0.38) 2490.0( 0.50) 10x10 opaque stippled rectangle 341.0 322.0( 0.94) 84.4( 0.25) 774.0( 2.27) 100x100 opaque stippled rectangle 24.6 21.9( 0.89) 4.0( 0.16) 48.2( 1.96) 500x500 opaque stippled rectangle 35700.0 35400.0( 0.99) 3940.0( 0.11) 2800.0( 0.078) 1x1 4x4 tiled rectangle 16500.0 14900.0( 0.90) 2530.0( 0.15) 2460.0( 0.15) 10x10 4x4 tiled rectangle 661.0 572.0( 0.87) 87.8( 0.13) 561.0( 0.85) 100x100 4x4 tiled rectangle 30.0 25.9( 0.86) 3.8( 0.13) 35.3( 1.18) 500x500 4x4 tiled rectangle 22300.0 22200.0( 1.00) 4100.0( 0.18) 2660.0( 0.12) 1x1 161x145 tiled rectangle 7210.0 7020.0( 0.97) 2790.0( 0.39) 2340.0( 0.32) 10x10 161x145 tiled rectangle 247.0 245.0( 0.99) 117.0( 0.47) 292.0( 1.18) 100x100 161x145 tiled rectangle 11.5 11.4( 0.99) 5.4( 0.47) 15.0( 1.30) 500x500 161x145 tiled rectangle 46300.0 47900.0( 1.03) 20900.0( 0.45) 55100.0( 1.19) 1-pixel line segment 34700.0 34100.0( 0.98) 18200.0( 0.52) 54700.0( 1.58) 10-pixel line segment 13500.0 12000.0( 0.89) 8200.0( 0.61) 29500.0( 2.19) 100-pixel line segment 3600.0 3100.0( 0.86) 2390.0( 0.66) 8280.0( 2.30) 500-pixel line segment 9620.0 8710.0( 0.91) 6650.0( 0.69) 20100.0( 2.09) 100-pixel line segment (1 kid) 7590.0 6940.0( 0.91) 5230.0( 0.69) 11300.0( 1.49) 100-pixel line segment (2 kids) 6150.0 5890.0( 0.96) 4200.0( 0.68) 14800.0( 2.41) 100-pixel line segment (3 kids) 21700.0 21700.0( 1.00) 1510.0( 0.070) 1610.0( 0.074) 10-pixel dashed segment 5370.0 5300.0( 0.99) 521.0( 0.097) 764.0( 0.14) 100-pixel dashed segment 4850.0 4820.0( 0.99) 333.0( 0.069) 587.0( 0.12) 100-pixel double-dashed segment 53500.0 41600.0( 0.78) 26500.0( 0.50) 110000.0( 2.06) 1-pixel line 38900.0 28300.0( 0.73) 22400.0( 0.58) 104000.0( 2.67) 10-pixel line 14000.0 11000.0( 0.79) 8990.0( 0.64) 35200.0( 2.51) 100-pixel line 3640.0 3010.0( 0.83) 2450.0( 0.67) 8820.0( 2.42) 500-pixel line 23900.0 23300.0( 0.97) 3600.0( 0.15) 5190.0( 0.22) 10-pixel dashed line 5540.0 5500.0( 0.99) 634.0( 0.11) 1150.0( 0.21) 100-pixel dashed line 4960.0 4890.0( 0.99) 382.0( 0.077) 767.0( 0.15) 100-pixel double-dashed line 3030.0 2930.0( 0.97) 21200.0( 7.00) 80400.0( 26.53) 10x1 wide line 721.0 698.0( 0.97) 207.0( 0.29) 291.0( 0.40) 100x10 wide line 112.0 103.0( 0.92) 71.0( 0.63) 203.0( 1.81) 500x50 wide line 304.0 307.0( 1.01) 42.8( 0.14) 48.4( 0.16) 100x10 wide dashed line 279.0 284.0( 1.02) 37.0( 0.13) 42.1( 0.15) 100x10 wide double-dashed line 19000.0 19400.0( 1.02) 1050.0( 0.055) 1020.0( 0.054) 1-pixel circle 14600.0 13800.0( 0.95) 773.0( 0.053) 763.0( 0.052) 10-pixel circle 5220.0 4270.0( 0.82) 355.0( 0.068) 395.0( 0.076) 100-pixel circle 1430.0 1090.0( 0.76) 69.1( 0.048) 75.7( 0.053) 500-pixel circle 375.0 380.0( 1.01) 62.7( 0.17) 80.2( 0.21) 100-pixel dashed circle 276.0 276.0( 1.00) 47.8( 0.17) 68.2( 0.25) 100-pixel double-dashed circle 274.0 267.0( 0.97) 785.0( 2.86) 758.0( 2.77) 10-pixel wide circle 68.6 68.4( 1.00) 58.2( 0.85) 56.7( 0.83) 100-pixel wide circle 14.1 13.6( 0.96) 17.0( 1.21) 23.2( 1.65) 500-pixel wide circle 17.2 17.5( 1.02) 6.1( 0.35) 7.2( 0.42) 100-pixel wide dashed circle 14.6 15.2( 1.04) 4.3( 0.29) 4.9( 0.34) 100-pixel wide double-dashed circle 6800.0 6940.0( 1.02) 487.0( 0.072) 485.0( 0.071) 10-pixel partial circle 2520.0 2530.0( 1.00) 331.0( 0.13) 348.0( 0.14) 100-pixel partial circle 86600.0 88000.0( 1.02) 1010.0( 0.012) 905.0( 0.010) 1-pixel solid circle 8730.0 8330.0( 0.95) 713.0( 0.082) 699.0( 0.080) 10-pixel solid circle 604.0 543.0( 0.90) 225.0( 0.37) 334.0( 0.55) 100-pixel solid circle 35.0 31.1( 0.89) 21.9( 0.63) 68.5( 1.96) 500-pixel solid circle 3250.0 3390.0( 1.04) 426.0( 0.13) 430.0( 0.13) 10-pixel fill chord partial circle 619.0 581.0( 0.94) 232.0( 0.37) 292.0( 0.47) 100-pixel fill chord partial circle 3180.0 3450.0( 1.08) 412.0( 0.13) 417.0( 0.13) 10-pixel fill slice partial circle 612.0 577.0( 0.94) 206.0( 0.34) 263.0( 0.43) 100-pixel fill slice partial circle 13000.0 12800.0( 0.98) 781.0( 0.060) 779.0( 0.060) 10-pixel ellipse 4270.0 4140.0( 0.97) 410.0( 0.096) 406.0( 0.095) 100-pixel ellipse 1080.0 1040.0( 0.96) 92.3( 0.085) 101.0( 0.094) 500-pixel ellipse 456.0 459.0( 1.01) 83.2( 0.18) 108.0( 0.24) 100-pixel dashed ellipse 332.0 338.0( 1.02) 61.2( 0.18) 90.1( 0.27) 100-pixel double-dashed ellipse 118.0 120.0( 1.02) 769.0( 6.52) 781.0( 6.62) 10-pixel wide ellipse 19.8 18.9( 0.95) 54.2( 2.74) 56.9( 2.87) 100-pixel wide ellipse 4.2 4.1( 0.98) 18.5( 4.40) 26.0( 6.19) 500-pixel wide ellipse 6.9 7.0( 1.01) 7.9( 1.14) 8.7( 1.26) 100-pixel wide dashed ellipse 4.2 4.3( 1.02) 5.6( 1.33) 6.3( 1.50) 100-pixel wide double-dashed ellipse 6460.0 6700.0( 1.04) 510.0( 0.079) 508.0( 0.079) 10-pixel partial ellipse 2870.0 2840.0( 0.99) 382.0( 0.13) 393.0( 0.14) 100-pixel partial ellipse 10500.0 9830.0( 0.94) 714.0( 0.068) 705.0( 0.067) 10-pixel filled ellipse 1010.0 920.0( 0.91) 298.0( 0.30) 386.0( 0.38) 100-pixel filled ellipse 67.7 59.3( 0.88) 37.3( 0.55) 92.9( 1.37) 500-pixel filled ellipse 3400.0 3640.0( 1.07) 442.0( 0.13) 445.0( 0.13) 10-pixel fill chord partial ellipse 1050.0 1030.0( 0.98) 302.0( 0.29) 338.0( 0.32) 100-pixel fill chord ellipse 3460.0 3730.0( 1.08) 427.0( 0.12) 433.0( 0.13) 10-pixel fill slice partial ellipse 1050.0 1020.0( 0.97) 274.0( 0.26) 309.0( 0.29) 100-pixel fill slice ellipse 6220.0 5980.0( 0.96) 2970.0( 0.48) 4970.0( 0.80) Fill 1-pixel/side triangle 3320.0 3200.0( 0.96) 1980.0( 0.60) 5060.0( 1.52) Fill 10-pixel/side triangle 346.0 315.0( 0.91) 284.0( 0.82) 4710.0( 13.61) Fill 100-pixel/side triangle 4010.0 3870.0( 0.97) 2300.0( 0.57) 5030.0( 1.25) Fill 10x10 trapezoid 404.0 364.0( 0.90) 336.0( 0.83) 4750.0( 11.76) Fill 100x100 trapezoid 1330.0 1270.0( 0.95) 1020.0( 0.77) 1240.0( 0.93) Fill 10x10 stippled trapezoid 26.2 24.7( 0.94) 68.3( 2.61) 108.0( 4.12) Fill 100x100 stippled trapezoid 1430.0 1390.0( 0.97) 1100.0( 0.77) 1250.0( 0.87) Fill 10x10 opaque stippled trapezoid 28.4 27.2( 0.96) 67.3( 2.37) 108.0( 3.80) Fill 100x100 opaque stippled trapezoid 1240.0 1210.0( 0.98) 1320.0( 1.06) 1260.0( 1.02) Fill 10x10 tiled trapezoid 21.7 20.8( 0.96) 71.2( 3.28) 211.0( 9.72) Fill 100x100 tiled trapezoid 2260.0 1940.0( 0.86) 1780.0( 0.79) 3160.0( 1.40) Fill 10-pixel/side complex polygon 277.0 257.0( 0.93) 285.0( 1.03) 1160.0( 4.19) Fill 100-pixel/side complex polygons 26100.0 25700.0( 0.98) 25000.0( 0.96) 52900.0( 2.03) Char in 80-char line (6x13) 36900.0 35800.0( 0.97) 30800.0( 0.83) 64400.0( 1.75) Char in 80-char line (TR 10) 11900.0 11700.0( 0.98) 11100.0( 0.93) 41200.0( 3.46) Char in 30-char line (TR 24) 27000.0 26700.0( 0.99) 22500.0( 0.83) 38800.0( 1.44) Char in 20/40/20 line (6x13, TR 10) 48400.0 43600.0( 0.90) 18100.0( 0.37) 41000.0( 0.85) Char in 80-char image line (6x13) 23100.0 22400.0( 0.97) 21800.0( 0.94) 48400.0( 2.10) Char in 80-char image line (TR 10) 7260.0 6860.0( 0.94) 6870.0( 0.95) 26700.0( 3.68) Char in 30-char image line (TR 24) 4890.0 4940.0( 1.01) 808.0( 0.17) 909.0( 0.19) Scroll 10x10 pixels 406.0 248.0( 0.61) 232.0( 0.57) 888.0( 2.19) Scroll 100x100 pixels 19.2 11.0( 0.57) 14.6( 0.76) 137.0( 7.14) Scroll 500x500 pixels 4690.0 4540.0( 0.97) 799.0( 0.17) 891.0( 0.19) Copy 10x10 from window to window 354.0 230.0( 0.65) 125.0( 0.35) 891.0( 2.52) Copy 100x100 from window to window 16.8 10.2( 0.61) 5.7( 0.34) 71.4( 4.25) Copy 500x500 from window to window 5010.0 5350.0( 1.07) 1130.0( 0.23) 1050.0( 0.21) Copy 10x10 from pixmap to window 435.0 404.0( 0.93) 171.0( 0.39) 249.0( 0.57) Copy 100x100 from pixmap to window 20.1 18.2( 0.91) 8.3( 0.41) 13.5( 0.67) Copy 500x500 from pixmap to window 4830.0 4910.0( 1.02) 822.0( 0.17) 767.0( 0.16) Copy 10x10 from window to pixmap 353.0 269.0( 0.76) 123.0( 0.35) 94.9( 0.27) Copy 100x100 from window to pixmap 16.7 12.3( 0.74) 6.1( 0.37) 4.0( 0.24) Copy 500x500 from window to pixmap 5600.0 5940.0( 1.06) 944.0( 0.17) 1050.0( 0.19) Copy 10x10 from pixmap to pixmap 488.0 485.0( 0.99) 167.0( 0.34) 183.0( 0.38) Copy 100x100 from pixmap to pixmap 22.1 22.3( 1.01) 9.2( 0.42) 9.2( 0.42) Copy 500x500 from pixmap to pixmap 4740.0 5120.0( 1.08) 1050.0( 0.22) 1100.0( 0.23) Copy 10x10 1-bit deep plane 436.0 395.0( 0.91) 130.0( 0.30) 641.0( 1.47) Copy 100x100 1-bit deep plane 23.3 21.1( 0.91) 6.7( 0.29) 93.1( 4.00) Copy 500x500 1-bit deep plane 2410.0 2410.0( 1.00) 1320.0( 0.55) 1320.0( 0.55) PutImage 10x10 square 79.0 76.4( 0.97) 57.8( 0.73) 68.8( 0.87) PutImage 100x100 square 3.5 3.5( 1.00) 2.5( 0.71) 3.1( 0.89) PutImage 500x500 square 384.0 395.0( 1.03) 145.0( 0.38) 144.0( 0.38) GetImage 10x10 square 94.4 88.2( 0.93) 22.2( 0.24) 21.3( 0.23) GetImage 100x100 square 4.8 4.4( 0.92) 1.0( 0.21) 1.0( 0.21) GetImage 500x500 square 61200.0 60400.0( 0.99) 65900.0( 1.08) 67500.0( 1.10) X protocol NoOperation 476.0 487.0( 1.02) 341.0( 0.72) 309.0( 0.65) GetAtomName 471.0 499.0( 1.06) 296.0( 0.63) 292.0( 0.62) GetProperty 7970.0 7210.0( 0.90) 4210.0( 0.53) 4630.0( 0.58) Change graphics context 1310.0 1360.0( 1.04) 158.0( 0.12) 134.0( 0.10) Create and map subwindows (4 kids) 1520.0 1550.0( 1.02) 197.0( 0.13) 204.0( 0.13) Create and map subwindows (16 kids) 1550.0 1590.0( 1.03) 211.0( 0.14) 213.0( 0.14) Create and map subwindows (25 kids) 1470.0 1550.0( 1.05) 218.0( 0.15) 219.0( 0.15) Create and map subwindows (50 kids) 1480.0 1480.0( 1.00) 219.0( 0.15) 219.0( 0.15) Create and map subwindows (75 kids) 1460.0 1500.0( 1.03) 209.0( 0.14) 211.0( 0.14) Create and map subwindows (100 kids) 1350.0 1380.0( 1.02) 200.0( 0.15) 200.0( 0.15) Create and map subwindows (200 kids) 3690.0 3570.0( 0.97) 160.0( 0.043) 160.0( 0.043) Create unmapped window (4 kids) 3720.0 3390.0( 0.91) 317.0( 0.085) 315.0( 0.085) Create unmapped window (16 kids) 3700.0 3580.0( 0.97) 308.0( 0.083) 308.0( 0.083) Create unmapped window (25 kids) 3720.0 3610.0( 0.97) 335.0( 0.090) 333.0( 0.090) Create unmapped window (50 kids) 3730.0 3610.0( 0.97) 342.0( 0.092) 340.0( 0.091) Create unmapped window (75 kids) 3700.0 3610.0( 0.98) 343.0( 0.093) 340.0( 0.092) Create unmapped window (100 kids) 3730.0 3600.0( 0.97) 327.0( 0.088) 324.0( 0.087) Create unmapped window (200 kids) 1640.0 1730.0( 1.05) 501.0( 0.31) 550.0( 0.34) Map window via parent (4 kids) 2330.0 2420.0( 1.04) 1330.0( 0.57) 1350.0( 0.58) Map window via parent (16 kids) 2350.0 2570.0( 1.09) 1390.0( 0.59) 1350.0( 0.57) Map window via parent (25 kids) 2450.0 2530.0( 1.03) 1100.0( 0.45) 1100.0( 0.45) Map window via parent (50 kids) 2520.0 2620.0( 1.04) 1020.0( 0.40) 1050.0( 0.42) Map window via parent (75 kids) 2560.0 2640.0( 1.03) 1050.0( 0.41) 1090.0( 0.43) Map window via parent (100 kids) 2590.0 2670.0( 1.03) 921.0( 0.36) 909.0( 0.35) Map window via parent (200 kids) 8900.0 8440.0( 0.95) 2690.0( 0.30) 2850.0( 0.32) Unmap window via parent (4 kids) 19200.0 17800.0( 0.93) 1370.0( 0.071) 1440.0( 0.075) Unmap window via parent (16 kids) 21500.0 20500.0( 0.95) 1530.0( 0.071) 1540.0( 0.072) Unmap window via parent (25 kids) 25100.0 23200.0( 0.92) 1560.0( 0.062) 1470.0( 0.059) Unmap window via parent (50 kids) 26500.0 24000.0( 0.91) 1460.0( 0.055) 1510.0( 0.057) Unmap window via parent (75 kids) 27300.0 25000.0( 0.92) 1460.0( 0.053) 1480.0( 0.054) Unmap window via parent (100 kids) 28500.0 26000.0( 0.91) 1180.0( 0.041) 1210.0( 0.042) Unmap window via parent (200 kids) 1730.0 1820.0( 1.05) 203.0( 0.12) 43.6( 0.025) Destroy window via parent (4 kids) 5580.0 5340.0( 0.96) 41.9( 0.008) 42.4( 0.008) Destroy window via parent (16 kids) 5960.0 6290.0( 1.06) 301.0( 0.051) 298.0( 0.050) Destroy window via parent (25 kids) 7630.0 6380.0( 0.84) 324.0( 0.042) 110.0( 0.014) Destroy window via parent (50 kids) 7950.0 7350.0( 0.92) 341.0( 0.043) 346.0( 0.044) Destroy window via parent (75 kids) 8160.0 7510.0( 0.92) 306.0( 0.037) 334.0( 0.041) Destroy window via parent (100 kids) 8380.0 7670.0( 0.92) 250.0( 0.030) 250.0( 0.030) Destroy window via parent (200 kids) 691.0 761.0( 1.10) 126.0( 0.18) 132.0( 0.19) Hide/expose window via popup (4 kids) 1210.0 1320.0( 1.09) 195.0( 0.16) 220.0( 0.18) Hide/expose window via popup (16 kids) 1310.0 1430.0( 1.09) 243.0( 0.19) 246.0( 0.19) Hide/expose window via popup (25 kids) 1270.0 1480.0( 1.17) 250.0( 0.20) 243.0( 0.19) Hide/expose window via popup (50 kids) 1410.0 1510.0( 1.07) 230.0( 0.16) 233.0( 0.17) Hide/expose window via popup (75 kids) 1380.0 1530.0( 1.11) 220.0( 0.16) 233.0( 0.17) Hide/expose window via popup (100 kids) 1430.0 1530.0( 1.07) 183.0( 0.13) 188.0( 0.13) Hide/expose window via popup (200 kids) 644.0 714.0( 1.11) 130.0( 0.20) 144.0( 0.22) Move window (4 kids) 492.0 526.0( 1.07) 86.7( 0.18) 107.0( 0.22) Move window (16 kids) 429.0 452.0( 1.05) 81.2( 0.19) 73.9( 0.17) Move window (25 kids) 336.0 340.0( 1.01) 41.7( 0.12) 41.9( 0.12) Move window (50 kids) 269.0 286.0( 1.06) 25.8( 0.096) 25.7( 0.096) Move window (75 kids) 207.0 235.0( 1.14) 17.3( 0.084) 17.2( 0.083) Move window (100 kids) 134.0 133.0( 0.99) 5.9( 0.044) 6.0( 0.045) Move window (200 kids) 10100.0 9120.0( 0.90) 2480.0( 0.25) 2260.0( 0.22) Moved unmapped window (4 kids) 10100.0 8840.0( 0.88) 2470.0( 0.24) 2250.0( 0.22) Moved unmapped window (16 kids) 10000.0 8360.0( 0.84) 2460.0( 0.25) 2260.0( 0.23) Moved unmapped window (25 kids) 10000.0 9660.0( 0.97) 2430.0( 0.24) 2240.0( 0.22) Moved unmapped window (50 kids) 9980.0 9120.0( 0.91) 2420.0( 0.24) 2230.0( 0.22) Moved unmapped window (75 kids) 9840.0 9150.0( 0.93) 2430.0( 0.25) 2220.0( 0.23) Moved unmapped window (100 kids) 9670.0 8830.0( 0.91) 2420.0( 0.25) 2210.0( 0.23) Moved unmapped window (200 kids) 2050.0 2070.0( 1.01) 499.0( 0.24) 878.0( 0.43) Move window via parent (4 kids) 4610.0 4180.0( 0.91) 1960.0( 0.43) 2510.0( 0.54) Move window via parent (16 kids) 5400.0 4860.0( 0.90) 2740.0( 0.51) 3960.0( 0.73) Move window via parent (25 kids) 6440.0 5600.0( 0.87) 3920.0( 0.61) 7040.0( 1.09) Move window via parent (50 kids) 6750.0 5820.0( 0.86) 4190.0( 0.62) 10400.0( 1.54) Move window via parent (75 kids) 6780.0 6040.0( 0.89) 4680.0( 0.69) 12100.0( 1.78) Move window via parent (100 kids) 7040.0 6100.0( 0.87) 5110.0( 0.73) 15400.0( 2.19) Move window via parent (200 kids) 613.0 688.0( 1.12) 108.0( 0.18) 85.9( 0.14) Resize window (4 kids) 513.0 563.0( 1.10) 69.6( 0.14) 65.3( 0.13) Resize window (16 kids) 457.0 494.0( 1.08) 53.3( 0.12) 56.4( 0.12) Resize window (25 kids) 369.0 383.0( 1.04) 35.2( 0.095) 35.1( 0.095) Resize window (50 kids) 303.0 328.0( 1.08) 21.9( 0.072) 21.8( 0.072) Resize window (75 kids) 245.0 277.0( 1.13) 17.0( 0.069) 17.0( 0.069) Resize window (100 kids) 165.0 164.0( 0.99) 6.5( 0.039) 6.5( 0.039) Resize window (200 kids) 9340.0 8420.0( 0.90) 623.0( 0.067) 600.0( 0.064) Resize unmapped window (4 kids) 9270.0 8630.0( 0.93) 596.0( 0.064) 500.0( 0.054) Resize unmapped window (16 kids) 9310.0 8620.0( 0.93) 611.0( 0.066) 576.0( 0.062) Resize unmapped window (25 kids) 9210.0 8580.0( 0.93) 616.0( 0.067) 548.0( 0.060) Resize unmapped window (50 kids) 9240.0 8500.0( 0.92) 622.0( 0.067) 532.0( 0.058) Resize unmapped window (75 kids) 9140.0 8590.0( 0.94) 620.0( 0.068) 524.0( 0.057) Resize unmapped window (100 kids) 8910.0 8320.0( 0.93) 560.0( 0.063) 544.0( 0.061) Resize unmapped window (200 kids) 261.0 288.0( 1.10) 89.8( 0.34) 161.0( 0.62) Circulate window (4 kids) 178.0 203.0( 1.14) 74.6( 0.42) 81.7( 0.46) Circulate window (16 kids) 171.0 193.0( 1.13) 73.8( 0.43) 85.1( 0.50) Circulate window (25 kids) 158.0 183.0( 1.16) 92.5( 0.59) 81.3( 0.51) Circulate window (50 kids) 152.0 171.0( 1.12) 82.1( 0.54) 70.9( 0.47) Circulate window (75 kids) 142.0 156.0( 1.10) 67.8( 0.48) 65.2( 0.46) Circulate window (100 kids) 121.0 135.0( 1.12) 54.4( 0.45) 50.5( 0.42) Circulate window (200 kids) 32000.0 31900.0( 1.00) 7430.0( 0.23) 7430.0( 0.23) Circulate Unmapped window (4 kids) 24300.0 25800.0( 1.06) 5750.0( 0.24) 5800.0( 0.24) Circulate Unmapped window (16 kids) 21500.0 21500.0( 1.00) 4880.0( 0.23) 4920.0( 0.23) Circulate Unmapped window (25 kids) 16300.0 15500.0( 0.95) 3540.0( 0.22) 3520.0( 0.22) Circulate Unmapped window (50 kids) 13300.0 12500.0( 0.94) 2730.0( 0.21) 2740.0( 0.21) Circulate Unmapped window (75 kids) 10900.0 10400.0( 0.95) 2240.0( 0.21) 2230.0( 0.20) Circulate Unmapped window (100 kids) 6460.0 6320.0( 0.98) 1130.0( 0.17) 1110.0( 0.17) Circulate Unmapped window (200 kids) From don Mon Jan 8 14:42:52 1990 Date: Mon, 8 Jan 90 14:42:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: size of X vs. NeWS From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I performed the following experiments on a SPARCstation 1 with CG3: 1. Started up xnews in NEWSONLY mode, two psterms, and a roundclock. 2. Started up R4 Xsun, a twm, two xterms, and an oclock. (xnews comes up with an internal wm, and roundclock ends up internal too.) (oclock is a true oval clock; R4 supports nonrectangular windows.) Here are numbers, in kilobytes, using size(1) for TEXT and ps(1) for DATA: TEXT DATA TEXT DATA xnews 1352 2628 Xsun 688 296 psterm 64 64 xterm 120 176 psterm 64 xterm 176 twm 152 100 oclock 80 32 I'm not sure how to measure shared library sizes, here's what size(1) says: libX11 176 libXt 200 libXmu 48 TEXT DATA TEXT DATA Totals: 1416 2756 1464 780 (Some portion of the xnews text should be subtracted as X specific.) From don Mon Jan 8 14:48:38 1990 Date: Mon, 8 Jan 90 14:48:38 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: hplabsz!mayer@hplabs.hp.com (Niels Mayer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <1132@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: > > [code fragment for hello-world in elk deleted] > >Note that the initialization of the application context and display >is somewhat lengthy (by the way, I wonder why the initialization is >missing in the WINTERP example). Because WINTERP already has the application context and the display initialized when it starts up. You also don't need to explicitly code an event handling loop since that is also implicit in WINTERP. You see, lisp forms sent to WINTERP's serverized lisp listener look just like another event to WINTERP -- there is no need to switch between a lisp-listener loop and an Xevent loop since the loops are merged. I did things this way because I wanted WINTERP-based applications to 1) be fully interactive -- unlike elk, there's no need to exit and reenter the X event loop in order to access the lisp listener. This means I can interpretively and interactively create, and modify an interface. 2) allow for WINTERP-based processes to be able to send messages to each other through the TCP-based serverized lisp listener. THis will allow for better application integration as applications can talk to each other. It is also a necessary feature in allowing real-time communications between the experimental multimedia and groupware applications that we are building. The Elk approach is more of a 1-to-1 correspondence to the Xtoolkit intrinsics calls, and is similar to my initial proof-of-concept "alpha" WINTERP that I hacked together out of ELI and the HP Xwidgets about a year ago. I found my "alpha" approach to be workable, but still a bit too verbose. Thus in the released "beta" WINTERP I opted to use XLISP's object system as the API to the Motif widget classes. This has resulted in a much cleaner design that allows me to eploit OOP features such as polymorphism, inherticance and subclassing on existing Motif widget classes. Furthermore, interactive use of the beta WINTERP is much more robust since you cannot accidentally call, for example, the function XmGetText() on a pushbutton widget class instance causing a core dump. In the "beta" WINTERP, XmGetText() is called in response to the message :GET_TEXT on instances of the XM_TEXT_WIDGET_CLASS; an "undefined method" error is signalled if you send that message to an instance of the wrong class. The assumptions and coding style must change drasticaly when coding in an object oriented model in compiled C (Xtoolkit/Motif) versus an interpreted object oriented lisp (WINTERP/XLISP).... So anyways, if I send the following form to WINTERP's serverized lisp listener (let* ((top_w (send TOP_LEVEL_SHELL_WIDGET_CLASS :new :XMN_TITLE "hello world" ;note auto string->XmString conv :XMN_ICON_NAME "hello world")) ;ditto (but_w (send XM_PUSH_BUTTON_WIDGET_CLASS :new :managed top_w :XMN_FONT_LIST "8x16"))) ;note auto string->FontList cv (send but_w :add_callback :XMN_ARM_CALLBACK '() '((system "echo \"Hello World Run!\" | mailx mayer@hplabs.hp.com") (format t "hello world\n"))) (send top_w :realize)) I can expect a "hello world" window to pop up as soon as WINTERP has finished evaluating the form. The receipt of the form is seen as a "lisp event" by WINTERP's XtMainLoop() and is sent off to the evaluator which in turn ends up calling the various Motif/Xt functions to create widgets. Upon return to the XtMainLoop, the windows are created, mapping and expose events are processed, and the windows appear on the screen... I see application contexts, display initializations, loading widgets, XtMainLoops and such as too much low-level noise that the WINTERP programmer really shouldn't have to deal with -- they should be transparent. One feature currently supported in Elk and not supported in WINTERP is the ability to dynamically load C object code. Although I wanted this feature in WINTERP, I explicitly decided against it due to the fact that (1) dynamic loaders are inherently unportable and my primary goal for the first public release of WINTERP were that it be easily portable (*); (2) I wrote "beta" WINTERP on an extremely tight schedule; (3) I didn't want to worry about dynamic loading because I had my hands full trying to understand Motif, the Xtoolkit, and the internals of XLISP. When I add dynamic loading to WINTERP, I hope to make it a dynamic auto-loader. PS: (*) -- I've received reports that WINTERP currently runs on the following machines: HP9000s3xx (68030), HP9000s8xx (HP PA-RISC), HP-Apollo DN-*, Sun3, Sun4, MIPS, DEC 3100. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. * From don Mon Jan 8 14:48:44 1990 Date: Mon, 8 Jan 90 14:48:44 -0500 To: NeWS-makers@brillig.umd.edu Subject: Common toolkit (Was: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows???) From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article , peter@ficc (Peter da Silva) writes: >They don't need to be convinced. They're happy with the UI. That's why >I'm opposed to Open Look or Motif... it's forcing a single (new) UI >on folks who are already happy with the one they have. Quite a statement. You have critized Open Look for 16 months, yet you still haven't read the style guide. How do you know what Mac users will say? Especially the power users, where the market is. I know for a *fact* that some Mac users LOVE the features of Motif and/or Open Look. Have you considered that either one (or both combined) might be a SUPERSET of the Mac interface? You have proposed a universal toolkit. One that would work with the native window system of the PC, Amiga or Mac, as well as X or NeWS. >Or are you saying that if you can't afford a 5-10 grand workstation you >aren't worth paying attention to? What commercal reason would a vendor have for creating such a useless toolkit? -- Bruce G. Barnett uunet!crdgw1!barnett From don Mon Jan 8 15:04:02 1990 Date: Mon, 8 Jan 90 15:04:02 -0500 To: NeWS-makers@brillig.umd.edu Subject: size of X vs. NeWS (Take 2) From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) [Corrections from the previous message: 1. A GX was installed, not a CG3. 2. I forgot to include the X widget library! 3. I failed to include data sizes for the X shared libraries. ] I performed the following experiments on a SPARCstation 1 with GX: 1. Started up xnews in NEWSONLY mode, two psterms, and a roundclock. 2. Started up R4 Xsun, a twm, two xterms, and an oclock. (xnews comes up with an internal wm, and roundclock ends up internal too.) (oclock is a true oval clock; R4 supports nonrectangular windows.) Here are numbers, in kilobytes, using size(1) for TEXT and ps(1) for DATA: TEXT DATA TEXT DATA xnews 1352 2628 Xsun 688 296 psterm 64 64 xterm 120 176 psterm 64 xterm 176 twm 152 100 oclock 80 32 I'm not sure how to measure shared library sizes, here's what size(1) says: libX11 176 24 libXt 200 48 libXmu 48 8 libXaw 152 40 TEXT DATA TEXT DATA Totals: 1416 2756 1616 900 (Some portion of the xnews text should be subtracted as X specific.) From don Mon Jan 8 15:04:12 1990 Date: Mon, 8 Jan 90 15:04:12 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Paint/Draw/Word Processing programs...??? From: Peter W. Brewer Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The only reasonable one I've seen that will run everywhere.. idraw from InterViews... Peter From don Mon Jan 8 15:04:43 1990 Date: Mon, 8 Jan 90 15:04:43 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Window systems should not be substitutes for decent environments From: diamond.bbn.com!mlandau@bbn.com (Matt Landau) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) joel@decwrl.dec.com (Joel McCormack) writes: >Most of the points about NeWS's ``technical superiority'' >are really complaints about UNIX and C in disguise. You should >certainly complain that your programming language and environment >doesn't give you support for the kinds of things you want to do, but >don't get confused and complain that the lack of such support is a >problem inherent to X. This is a crock. The basic point is this: the X11 protocol simply does not allow me, as an application writer, to decide what parts of my application belong close to the user (in the server, where they can provide fast feedback, etc.) and what parts belong in the client. The only way for me to change this is to write my own server extensions and only allow my application to run with servers that have my extensions. In effect, I have to get into the X server business if I want to be able to do certain things. NeWS allows me to decide what parts of my application belong in the server, and to download them into the server myself, at runtime. I never have to worry about whether a particular extension or facility is present, because I can *make* it present, in any NeWS server, at any time, using a well-defined protocol (which happens to be based on PostScript, with all the nice things that implies about imaging models, etc.) There's also an argument that the X11 protocol does not allow me, as a user, to change what parts of my user-interface look like and have the change apply to all applications. That argument is also true, but only partially. It relies on all NeWS applications using the same server-resident tools for the user interface (they don't as yet) and it assumes that I don't have dynamically linked toolkits on the X11 client side that I can replace with different toolkits for a different UI policy (I don't know of such a thing for X yet, but the N3 project at AT&T sounds like a good start). Now, do we all understand why NeWS is a more powerful idea than X? Because runtime extensibility is good, and it's GUARANTEED by the very definition of NeWS, and it's NOT guaranteed by the very definition of X11. -- Matt Landau The happiest cold and lonely guy mlandau@bbn.com stuck in the Yukon without a dog. From don Mon Jan 8 15:06:13 1990 Date: Mon, 8 Jan 90 15:06:13 -0500 To: NeWS-makers@brillig.umd.edu Subject: Window systems should not be substitutes for decent environments From: decwrl.dec.com!joel@decwrl.dec.com (Joel McCormack) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) From the types of arguments offered for NeWS recently in this group, I must conclude that you guys all write ``real'' programs in Forth, yes? It's interpreted, extensible, uses RPN, etc. No, you probably all program in C, and many would defend its use technically (ugh). (I can't argue with using C for sales and lots of other reasons...but then, we're talking technical here, right?) A window system is not the place to put support for dynamic loading, concurrency, OO programming, etc. Instead, a window system should be able to use all these things if they are provided by a decent environment. Most of the points about NeWS's ``technical superiority'' are really complaints about UNIX and C in disguise. You should certainly complain that your programming language and environment doesn't give you support for the kinds of things you want to do, but don't get confused and complain that the lack of such support is a problem inherent to X. - Joel McCormack (decwrl!joel, joel@decwrl.dec.com) From don Mon Jan 8 15:08:11 1990 Date: Mon, 8 Jan 90 15:08:11 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Paint/Draw/Word Processing programs...??? From: ccncsu!longs.LANCE.ColoState.Edu!robert@boulder.colorado.edu (Robert Thompson) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <6478@ogicse.ogc.edu> goward@ogicse.ogc.edu (Philip Goward) writes: > > > Hi! > > I'm looking for MacPaint and MacWrite style software for > X or NeWS (preferably in the public domain). Anyone know > any location I can obtain these from? > > Also if anyone out there has a version of troff that runs > under X or NeWS and the sources for it are available.... I don't know of a word processing appliction for X (if someone does please post the source as I am looking for the same thing) The other applications are available at: expo.lcs.mit.edu 18.30.0.212 Or just about any other comp.sources.x archive site. Hope this helps. Robert Thompson Center for Computer Assisted Engineering Colorado State University From don Mon Jan 8 15:08:21 1990 Date: Mon, 8 Jan 90 15:08:21 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Window systems should not be substitutes for decent environments From: pandora.pa.dec.com!joel@decwrl.dec.com (Joel McCormack) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Now, do we all understand why NeWS is a more powerful idea than X? Because runtime extensibility is good, and it's GUARANTEED by the very definition of NeWS, and it's NOT guaranteed by the very definition of X11. I agree completely runtime extensibility is good. That's why people program in LISP and other such languages and environments. What I'm trying to say is that extensibility is not a problem that every tool in the world should have to address in it own idiosyncratic way. The more various tools try to compensate for basic deficiencies in the programming environment, the more weird interpreted languages I have to learn, and the more entrenched the stupid environment becomes. You can choose, each time you build a tool that you want to be extensible, to include yet another interpreter, for yet another language, in it. Or you can complain that what you'd really like is for EVERY program to have the option of being dynamically linkable to new pieces of code. Sure, you can download PostScript code into a NeWS server. Big deal: (1) PostScript wasn't designed as a programming language that humans should write in, and (2) PostScript was designed for printer speeds, not memory speeds. (And even so, a lot of people at printer companies complain how slow it is to image complicated diagrams with PostScript, and how PostScript semantics makes this especially hard to make fast. The lower resolution of a screen helps some, but not really enough.) Wouldn't you really rather be able to link compiled code into the server dynamically? I don't care about loading mouse-tracking code into the server--today's processors give me quite adequate tracking performance across the network. I'd like to download compiled code that will run fast, like 3-D extensions and image decompression algorithms. NeWS isn't going to do a thing for me, at least not in real time. I can't do this to an X server, either, at least in any portable way. But shouldn't I be able to? Why keep compensating for poor programming environments? You'll just encourage them! - Joel McCormack (decwrl!joel, joel@decwrl.dec.com) (This message brought to you by the C and UNIX are to Computer Science what FORTRAN is to Numeric Analysis Foundation.) From don Mon Jan 8 15:22:52 1990 Date: Mon, 8 Jan 90 15:22:52 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Common toolkit From: zaphod.mps.ohio-state.edu!mips!excelan!crdgw1!crdgw1.ge.com!barnett@tut.cis.ohio-state.edu (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <5V++88ggpc2@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >How about the fact that there are several million such machines out there? Well, how much money is Dec, HP, Sun, etc. going to make by developing a toolkit usable on a 1 Meg machine? Besides, they don't want a toolkit that is comparable to the Mac/MS Windows. They want one that is better. Why buy a 5 grand machine when you can run the same software on a $2,000 PC? One of the advantages of Open Look and Motif is that it can do things that the Mac/PC cannot do. If a Unix workstation doesn't have a better toolkit, then it will be tough to get Mac/PC users to switch. -- Bruce G. Barnett uunet!crdgw1!barnett From don Mon Jan 8 15:49:17 1990 Date: Mon, 8 Jan 90 15:49:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Window systems should not be substitutes for decent environments From: spectral!sjs@bellcore.com (Stan Switzer) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2405@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes: > From the types of arguments offered for NeWS recently in this group, I > must conclude that you guys all write ``real'' programs in Forth, yes? > It's interpreted, extensible, uses RPN, etc. No, you probably all > program in C, and many would defend its use technically (ugh). Well not this guy, that's for sure. C is a great language for writing interpreters. That's about it. > A window system is not the place to put support for dynamic loading, > concurrency, OO programming, etc. Instead, a window system should be > able to use all these things if they are provided by a decent > environment. Most of the points about NeWS's ``technical superiority'' > are really complaints about UNIX and C in disguise. Even allowing that this is true, and I think that it just might be, a solution is a solution. My dreadful UNIX/C environment isn't going to change for many a moon, but I can use the powerful features you mention (dynamic loading, concurrency, OO programming) and a few you don't (PostScript imaging model, high level execution abstraction--I'd settle for Scheme w/ OO extensions instead of PostScript RPN, minimal UI code in windowing client, rapid prototyping, dynamic modification of environment, powerful event distribution scheme, (almost) reflective programming language, etc.). The UNIX/C world suffers from least-common-denominatorism of the worst kind. Look at the Widget implementation. I mean, sure it's brilliant, but it should never have been done in C. Maybe Andrew had the right idea: a special preprocessor. Or maybe it should have been done in C++. Or maybe Objective-C. NeWS threatens to raise the denominator. True, it doesn't solve everybody's problems, but it does help solve the problems of the UI programmer. > You should > certainly complain that your programming language and environment > doesn't give you support for the kinds of things you want to do, but > don't get confused and complain that the lack of such support is a > problem inherent to X. OK, maybe I'm confused. Let's say that I had the power of the Mach OS, plus a windowing server with a powerful imaging model, plus a reasonable programming language. Then I might just be convinced. BUT: That OS isn't UNIX. That server isn't an unextended X. And that language isn't C. Maybe I should buy a NeXT? Stan Switzer sjs@bellcore.com ``I can't see the end of me / My whole expanse is all I see I formulate infinity / And store it deep inside me.'' -- Meat Puppets From don Mon Jan 8 15:49:24 1990 Date: Mon, 8 Jan 90 15:49:24 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Common toolkit (Was: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows???) From: nuchat!sugar!ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > You have proposed a universal toolkit. One that would work with the native > window system of the PC, Amiga or Mac, as well as X or NeWS. > >Or are you saying that if you can't afford a 5-10 grand workstation you > >aren't worth paying attention to? > What commercal reason would a vendor have for creating such a useless toolkit? I don't know. I guess I'm totally out to lunch. It's just my imagination that many very large companies have spent zillions of man-hours developing software for sub-5-grand workstations. Microsoft Windows 1.x (a nice UI in many ways) runs usably fast on a PC/XT with 256K of RAM. How about the fact that there are several million such machines out there? -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-' From don Mon Jan 8 15:49:42 1990 Date: Mon, 8 Jan 90 15:49:42 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Window systems should not be substitutes for decent environments From: nuchat!sugar!ficc!peter@uunet.uu.net (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <2405@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes: > From the types of arguments offered for NeWS recently in this group, I > must conclude that you guys all write ``real'' programs in Forth, yes? NeWS *is* Forth. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-' From don Mon Jan 8 15:50:06 1990 Date: Mon, 8 Jan 90 15:50:06 -0500 To: NeWS-makers@brillig.umd.edu Subject: Openwindows VT100 tool From: "Grootwassink, David" Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Hello Net, I would like to put NeWS or OpenWindows on my 4/370's however I have a definite need for a VT100 look alike for using a VAX on my network. Is there a VT100 emulator that will run under OpenWindows (X11 or NeWS), and if so where can I get it. Thanks, Dave ------------------------------------------------------------------------------- Lt. Dave Grootwassink USAF Tactical Air Warfare Center INTERNET: GROOTWASS@TAWC1.EGLIN.AF.MIL (129.61.5.1) PHONE: (904)882-4100 AUTOVON 872-4100 (904)882-4600 872-4600 ------------------------------------------------------------------------------- From don Mon Jan 8 15:50:34 1990 Date: Mon, 8 Jan 90 15:50:34 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Toolkits, toolkits, toolkits ... From: mcsun!unido!tub!net@uunet.uu.net (Oliver Laumann) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <4585@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > > The Elk approach is more of a 1-to-1 correspondence to the Xtoolkit > intrinsics calls, and is similar to my initial proof-of-concept "alpha" > WINTERP that I hacked together out of ELI and the HP Xwidgets about a year > ago. I found my "alpha" approach to be workable, but still a bit too > verbose. Since we are using Elk-Scheme as the extension language for a `real' software package (an ODA-based document processing system), we do need to be able to access the full power of the X toolkit, for instance, our application must be able to open more than one display (for shared editing of a document). Of course, funtionality like opening a display and creating an application context (the things that you called `noise') can be hidden in an additional `layer' if desired; building abstractions is one of the things that can be done in Scheme quite elegantly (which is one reason why we think that Scheme is better suited as a general extension language than, for instance, Xlisp). [Since this has no longer anything to do with NeWS, I have directed follow-ups to comp.windows.x] Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP From don Mon Jan 8 17:11:03 1990 Date: Mon, 8 Jan 90 17:11:03 -0500 To: NeWS-makers@brillig.umd.edu Subject: Open {Windows,House} at UniForum and USENIX From: cs.utexas.edu!sun-barr!newstop!sundc!npg%sundc.east.sun.com@tut.cis.ohio-state.edu (Neil Groundwater - Sun Consulting) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) The evening of January 23rd there will be an OpenWindows Open House at the Ramada Renaissance, East Salon Ballroom, Techworld, 999 9th Street NW, Washington, DC. The Ramada is located near the Washington Convention Center, the site of the UniForum show. Come and talk to Bill Joy and other Sun personnel about X11, NeWS, and Sun. For more information stop by the Sun booth at UniForum. ...Neil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Neil Groundwater ARPA : npg@sun.com Sun Microsystems, Inc. Internet: npg@sundc.East.Sun.COM 8219 Leesburg Pike Usenet : ...!uunet!sun!sundc!npg Suite #700 AT&T : (703) 883-1221 Vienna, VA 22182 FAX : (703) 893-0576 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From don Mon Jan 8 17:35:18 1990 Date: Mon, 8 Jan 90 17:35:18 -0500 To: NeWS-makers@brillig.umd.edu Subject: Changing font for LiteItem button From: logicon.arpa!trantor.harris-atd.com!melmac!chuck@nosc.mil (Chuck Musciano) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) [ Bear with me, I'm new to NeWS... ] I am trying to create a button object using the classes defined in liteitem.ps on a Silicon Graphics machine (if that matters). I tried to set the ItemFont class variable to no avail. How is this done? Could someone explain the difference between "instance variables" and "class variables"? I'm no stranger to object-oriented programming, but the documentation from SGI is so pathetic, I can't figure this out. My code looks like: #! /usr/NeWS/bin/psh systemdict /Item known not { (NeWS/liteitem.ps) run } if /createitems { /items dictbegin % Tooltool Current Items % /item0 (Input Source) /nullproc can /new ButtonItem send def { /ItemFont /Times-Italic findfont 36 scalefont def % <-- why won't this work? /ItemFrame 2 def } item0 send 8 396 200 10 /reshape item0 send /item1 (Network Configuration) /nullproc can /new ButtonItem send def 8 354 200 10 /reshape item1 send % End Tooltool Items % dictend def } def /win framebuffer /new DefaultWindow send def { /PaintClient {1 fillcanvas items paintitems} def /FrameLabel (Tooltool Sample!) def /DestroyClient { currentprocess killprocessgroup } def } win send 20 20 293 454 /reshape win send /can /GetCanvas win send def createitems /ih items forkitems def /map win send I also tried send a message to the ButtonItem class to change ItemFont, but that didn't work either. Any help is very much appreciated! Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} Gee, Beaver, everything that's fun can get you in trouble. Haven't you learned that yet? --Gilbert From don Mon Jan 8 17:45:09 1990 Date: Mon, 8 Jan 90 17:45:09 -0500 To: NeWS-makers@brillig.umd.edu Subject: Changing font for LiteItem button From: don (Don Hopkins) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Try changing /ItemLabelFont to effect the font that the item label is displayed in. /ItemFont effects the font of the ItemObject Thing. (Buttons just have a label, no ItemObject. (stuff like Cycle and Text Items have both a label and an object.) -Don From don Mon Jan 8 20:01:26 1990 Date: Mon, 8 Jan 90 20:01:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: event-driven applications From: frisbee!jcb@sun.com (Jim Becker) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: Like, say you want a program to go away for a while and do some work. Under X you lose the UI... and you can't even put up an "I'm busy" sign because it won't get displayed until you return to the event loop. Another over-generalization that seems typical for this list. I will try not to make the same mistake. These comments are focused on _your_ comments regarding Xt. "X" is a whole lotta things these days. To claim that all instances of X applications are single-threaded and strictly event-driven, in the canonical manner of Xt, is rather silly. There are multiple researchers out there working with X on the client side in a multi-threaded environment; there are even one or two products that work this way. Whether a multi-threaded client environment is better or worse than a single-threaded client with multi-threaded server is rather debateable, I'd say. I take this to be roughly an argument that a multi-threaded OS is needed to support separate thread event dispatch using the Xt or other similiar toolkit model. What current OSes support this? Is this something that users can rely on anytime in the future? Will all OSes to which X is ported allow this model? Given the basic design of the X event model there are a number of problems that arise when creating more complex applications than those more closely interface driven. These are starting to arise now that developers are venturing into _real application land_. The design of Xt was a concious one, for its portability across a wide range of systems. Clearly the model isn't adequate for all applications; that's good, it was an engineering solution. ~~~~~~~~~~~ Clearly the model is designed for simple applications, not those that have vastly complex interfaces. The model breaks with more complex interfaces and applications that do real work rather than heavy UI and light functionality. It is *not* good that Xt isn't adequate for all applications, simply because it is being asserted as a _standard_ on which all toolkits are to be based. If the initial foundation is inadequate then it should not be deemed the standard on which all solutions are based. By locking all users into a deficient standard prior to the marketplace understanding the variables in the game, one has effectivily crippled further progress in this area. I have yet to meet someone that could understand programming Xt in a single sitting; and there are pretty amazed reactions when people get into understanding it. Those here that have attempted to use it have been pretty smart, and it was no cakewalk to understand it for them. My brain has done automatic garbage collection after reading the various Xt texts, and I couldn't start writting a program using Xt. Although I think that X it pretty good up through the Xlib layer, seeing that Xt has become a stated underlying standard makes me have to realize that those defining the standards haven't yet understood the issues that will make X and Unix mainline consumer products. The Xt solution increases complexity when it should be a high level distilled usage of Xlib. Programmers out there don't want more complexity, they need less. Why do you think that software never catches up with hardware advances? Maybe the software isn't simple enough to use... Unix will be a bane rather than a blessing if no one decides that "engineering solutions" aren't wide market solutions, and works on productizing Unix for real people rather than expert users. Creating a barrier to learning and progress like the Xt gobbledygook is bad enough in itself (sorry Ralph). But making this a standard that all have to understand and suffer with simply limits the commercial viablity of Unix/X in the face of OS/2 and PM. If we want X to win then why is the door shut to creativity beyond the Xt class based model? Sorry to sound so negative, but I don't think that learning and creating the interface should be 80% of the application development time. I have created interfaces for large X applications in the past and don't think Xt (or Interviews) based solutions will work. I would really like to see an Xt based application with >100 windows, dialogs and alerts. By that time those teams of programmers designing and implementing widgets will have more than consumed the `peace dividend' in time spent learning Xt and subclassing widgets! The Sun solution of XView and Guide presents an example where the same basic functionality of the interface mechanisms have been created sans Xt. Last I checked InterViews didn't use Xt. Since there are multiple ways to skin this cat, and you state that Xt isn't the final solution, why is it a standard? -Jim Becker These thoughts are my own, and will probably get me into major trouble.. -- Jim Becker / jcb%frisbee@sun.com / Sun Microsystems ...these are my opinions, and even my id disagrees.. From don Tue Jan 9 21:02:50 1990 Date: Tue, 9 Jan 90 21:02:50 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Openwindows VT100 tool From: misc!jdn@sun.com (Jeff Nisewanger) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <9001081718.AA13840@brillig.UMD.EDU> grootwass@TAWC1.EGLIN.AF.MIL ("Grootwassink, David") writes: >Hello Net, > > I would like to put NeWS or OpenWindows on my 4/370's however I have a >definite need for a VT100 look alike for using a VAX on my network. Is there >a VT100 emulator that will run under OpenWindows (X11 or NeWS), and if so >where can I get it. > > > Thanks, > > Dave > >------------------------------------------------------------------------------- > > Lt. Dave Grootwassink USAF Tactical Air Warfare Center > > INTERNET: GROOTWASS@TAWC1.EGLIN.AF.MIL (129.61.5.1) > >PHONE: (904)882-4100 AUTOVON 872-4100 > (904)882-4600 872-4600 >------------------------------------------------------------------------------- The X11 program 'xterm' is a reasonably complete vt100 emulator and is in the OpenWindows distribution in the demo binary directory. Jeff Nisewanger ARPA: jdn@sun.com Window Systems Group UUCP: ...!sun!jdn Sun Microsystems, Inc. 415/336-5743 From don Tue Jan 9 21:03:17 1990 Date: Tue, 9 Jan 90 21:03:17 -0500 To: NeWS-makers@brillig.umd.edu Subject: HELP wanted on application dealing with input focus From: att!cbnewsc!bwong@ucbvax.Berkeley.EDU (bruce.f.wong) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I'm using tNt to build a RowColumnBag stuffed with ClassTextControl's with the following input focus behaviour: * On creation: the first field has the focus. * After the field with the focus calls the notify, the next field will have the input focus. This wraps around so the last field will transfer focus to the first field. * This is independent of the current focus management policy. The generalization of this problem is: Given a bag with canvases that are interested in the focus, how can focus be transfered without moving the mouse ? Please explain how this might be done and, if possible, provide sample code. -- Bruce F. Wong ATT Bell Laboratories att!iexist!bwong 200 Park Plaza, Rm 1B-232 708-713-5111 Naperville, Ill 60566-7050 From don Tue Jan 9 21:03:28 1990 Date: Tue, 9 Jan 90 21:03:28 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Window systems should not be substitutes for decent environments From: cs.utexas.edu!sun-barr!newstop!texsun!texbell!sugar!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) [ Postscript is too slow, want to download object modules to the server ] Sounds like you want to be using an AT&T 5620 Blit terminal. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-' From don Tue Jan 9 21:04:51 1990 Date: Tue, 9 Jan 90 21:04:51 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Common toolkit From: cs.utexas.edu!sun-barr!newstop!texsun!texbell!ficc!peter@tut.cis.ohio-state.edu (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Now we're getting somewhere... Subject is: A UI that's common to PCs, Macs, Amigas, and... UNIX. > >How about the fact that there are several million such machines out there? > Well, how much money is Dec, HP, Sun, etc. going to make by developing > a toolkit usable on a 1 Meg machine? I don't expect Dec, HP, or Sun to do so. It's in their best interests to make the toolkit as large as is needed. Even if they can't make *much* money selling memory, it certainly doesn't hurt the balance sheet. > Besides, they don't want a toolkit that is comparable to the Mac/MS > Windows. They want one that is better. Well, from my experience with $10,000 machines running X, from a performance basis alone they've got a lot of catching up to do. Adding a larger and more complex toolkit sure isn't going to help. > Why buy a 5 grand machine when > you can run the same software on a $2,000 PC? Multitasking, protected memory, and so on. After all, the current situation they have is that their 5 grand machine can't run as much software as the $2000 PC. They still manage to sell a few. Actually, my $1000 PC has better performance and more software (on a title-count basis) than your typical $10,000 UNIX box. I'd expect that the motivation would be the other way around: to develop a toolkit so that the $5000 workstations are capable of running software written for $2000 PCs. There's more software like that than the other way around. > One of the advantages of Open Look and Motif is that it can do things > that the Mac/PC cannot do. That's debatable. UNIX can, yes, bt that'll be true no matter what the toolkit, or the UI. But from a UI viewpoint, what does a $5000 DECstation buy you that you can't do with a $2000 Mac? 2 extra buttons? I hate the one button mouse, but I wouldn't pay $1000 a pop to add more. People buy computers to run software, not to pin menus in place. Don't make it hard to write and port software. > If a Unix workstation doesn't have a better > toolkit, then it will be tough to get Mac/PC users to switch. If the toolkit keeps people from porting PC software, it's not going to help. The big boys will go over. You'll get Lotus. But what about the small-scale vertical market software? -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-' From don Tue Jan 9 21:05:20 1990 Date: Tue, 9 Jan 90 21:05:20 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: HELP wanted on application dealing with input focus From: att!cbnewsc!bwong@ucbvax.Berkeley.EDU (bruce.f.wong) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <12663@cbnewsc.ATT.COM> bwong@cbnewsc.ATT.COM (bruce.f.wong) writes: >... >The generalization of this problem is: > >Given a bag with canvases that are interested in the focus, >how can focus be transfered without moving the mouse ? After firing off this article, I read about ``setinputfocus'' in Appendix B of the NeWS Programmer's Guide and it does exactly what I want. I was wallowing in all the details on how bags manage focus that I overlooked this simple mechanism and got very confused too. -- Bruce F. Wong ATT Bell Laboratories att!iexist!bwong 200 Park Plaza, Rm 1B-232 708-713-5111 Naperville, Ill 60566-7050 From don Tue Jan 9 21:05:47 1990 Date: Tue, 9 Jan 90 21:05:47 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: size of X vs. NeWS From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Are "psterm" and "xterm" comparable in functionality, or could functionality differences account for the difference in size between them, at least in part? I don't have a good feel for comparing their functionality. I suspect xterm has more (generally useless :-) bells and whistles. Was "psterm" linked with any NeWS shared libraries? ldd says it is only linked with libc. From don Tue Jan 9 21:06:05 1990 Date: Tue, 9 Jan 90 21:06:05 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: size of X vs. NeWS From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) How much of the XSUN size was server size? All of it? Xsun *is* the X server. You should split the memory usage into server/client requirements, praps? I thought that's what I did on the X side ... From don Wed Jan 10 20:14:09 1990 Date: Wed, 10 Jan 90 20:14:09 -0500 To: NeWS-makers@brillig.umd.edu Subject: Reverse video on Shelltool From: Rafael Bracho Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Has anyone figured out if there is an escape sequence that will reverse the video on an OpenWindows shelltool? The termcap-specified sequence, ESC-[-7-m doesn't work. Thanks, -Rafael From don Wed Jan 10 20:18:26 1990 Date: Wed, 10 Jan 90 20:18:26 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: event-driven applications From: rws@expo.lcs.mit.edu (Bob Scheifler) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I take this to be roughly an argument that a multi-threaded OS is needed to support separate thread event dispatch using the Xt or other similiar toolkit model. It's possible to use application-level threads and get somewhere. The main problem with such an approach is system calls blocking all threads; you have to understand application specifics to know how bad of a problem this is (but it's definitely a problem for some applications). What current OSes support this? Mach, Sprite, Symbolics, TI Explorer, Cedar, V(?), probably others. It seems like there is a relative abundance of application-level threads packages for C, although few of them are widely/easily available I guess. Processes are now fairly common in product Lisp systems. Several people have put threads into C++. Is this something that users can rely on anytime in the future? If OSF has its way, Mach may be widespread eventually. :-) There is a POSIX committee working hard on a standard Threads definition, indications are that they are making considerable progress. Clearly the model is designed for simple applications, not those that have vastly complex interfaces. I've seen a number of X products that are quite sophisticated. (I don't know about "vastly complex", we don't encourage those. :-) The model breaks with more complex interfaces and applications that do real work rather than heavy UI and light functionality. The model breaks when there is significant "computation" in parallel with user interaction, if that computation cannot easily be decomposed into Xt's notion of "work procs". I agree completely. But, as I have argued in the (distant) past, user interaction in sophisticated applications will very likely require interaction with the "back end" data of the application, and can't always be "downloaded" into a window server and run autonomously; multiple threads will be needed in the client as well. I remember Mark Callow of SGI at a SIGGRAPH panel a couple years ago admitting this turned out to be essentially the case for several applications they had been building. It is *not* good that Xt isn't adequate for all applications, simply because it is being asserted as a _standard_ on which all toolkits are to be based. You have the emphasis in the wrong place. It is *a* standard; the X Consortium does not view it as the only possible standard. I strongly disagree that one should build the universal toolkit (whatever that is) or be damned; I'd much rather take the 80% rule (and be damned :-). One of the common citations is that Macs/PCs have a wealth of useful applications, yet they are based on essentially the same model. By locking all users into a deficient standard prior to the marketplace understanding the variables in the game, one has effectivily crippled further progress in this area. When I count the number of new toolkits *still* being designed in the X environment (whether Xt based or not), I find it hard to agree that progress is being crippled. On the other hand, I've talked to a fair number of real end-users (e.g. people from federal agencies), and their almost universal cry is "give us something yesterday, I don't care what it is, I trust you that it's good enough for what I need to build right now". Standardization is an attempt to satisfy those kinds of needs, hopefully without stiffling innovation. It's a tricky road to walk. I have yet to meet someone that could understand programming Xt in a single sitting; and there are pretty amazed reactions when people get into understanding it. Anecdotal evidence is hard to compare. I have an undergraduate (a freshman as I recall) with no prior experience in windowing or graphics, just a little bit of C programming. We gave him the task of rewriting bitmap(1) to be a toolkit client, using the Athena Widgets. He read the documentation, asked very few questions, and poof, he's got a reasonably good application up and running (certainly much better than the current bitmap), including having written his own widget. Those here that have attempted to use it have been pretty smart, and it was no cakewalk to understand it for them. I agree it is difficult. I think a large part of it may be the documentation (e.g. separating out cleanly what widget users need vs. what widget writers need). I hope the Asente/Swick book nearing completion will help. And widget set documentation is getting better, as people learn how to present the information better. But making this a standard that all have to understand and suffer with simply limits the commercial viablity of Unix/X in the face of OS/2 and PM. Gee, I've read the PM documentation, and I can't say it's any better. If we want X to win then why is the door shut to creativity beyond the Xt class based model? Who in the world ever said it was shut? There is a wealth of creativity going on. Look around; attend the X Conference. :-) But, there's no consensus on any of it yet, that would enable standardization. I'm not really sure what your complaint is. You seem to want the world's best toolkit, which doesn't exist and probably won't in our lifetime, yet complain that people have agreed to a common definition of something that does in fact enable a reasonable range of applications to be built. Since there are multiple ways to skin this cat, and you state that Xt isn't the final solution, why is it a standard? Because multiple vendors rely on the Xt foundation, and desire to have a common, vendor-neutral definition and evolution of that layer. If the same were true of some other interface, the X Consortium would consider standardization of it. From don Wed Jan 10 20:19:27 1990 Date: Wed, 10 Jan 90 20:19:27 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Common toolkit From: crdgw1!crdgw1.ge.com!barnett@uunet.uu.net (Bruce Barnett) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article , peter@ficc (Peter da Silva) writes: >> Well, how much money is Dec, HP, Sun, etc. going to make by developing >> a toolkit usable on a 1 Meg machine? > >I don't expect Dec, HP, or Sun to do so. It's in their best interests to >make the toolkit as large as is needed. Even if they can't make *much* >money selling memory, it certainly doesn't hurt the balance sheet. Who else is left? If someone wants to make a new toolkit and give it away - fine. > >> Besides, they don't want a toolkit that is comparable to the Mac/MS >> Windows. They want one that is better. > >Well, from my experience with $10,000 machines running X, from a performance >basis alone they've got a lot of catching up to do. Adding a larger and >more complex toolkit sure isn't going to help. You need more experience, I think. X is not a good comparison, anyway. Perhaps a Sparcstation with GX running openwin is a good start. (Read comp.windows.x for speed comparisons) Expect cheaper machines in the future. >> One of the advantages of Open Look and Motif is that it can do things >> that the Mac/PC cannot do. > >That's debatable. UNIX can, yes, bt that'll be true no matter what the >toolkit, or the UI. But from a UI viewpoint, what does a $5000 DECstation >buy you that you can't do with a $2000 Mac? 2 extra buttons? I hate the >one button mouse, but I wouldn't pay $1000 a pop to add more. Want a list of a hundred things that are difficult to do with the Mac interface? (I'm not counting all of the add-on DA's, FKeys, etc. that change the basic UI. You can improve any window system by patching the code.) Again, if you used both the Mac and some of the better toolkits, if would be obvious how inadequate the Mac UI is. Even for simple things like resizing/moving windows, starting up programs, and selecting filenames. I find it amusing that with all of the hoopla about the Mac UI, they still haven't extended the desktop analogy to anything other than a directory and trashcan. The metaphor should extend to *programs*, allowing you to drag a file to a printer, tape drive, text editor, etc. Apple plans this for the System 7 release. Sun is shipping this now. -- Bruce G. Barnett uunet!crdgw1!barnett From don Wed Jan 10 20:19:37 1990 Date: Wed, 10 Jan 90 20:19:37 -0500 To: NeWS-makers@brillig.umd.edu Subject: PaintRoot From: russ@dash.mitre.org (Russell Leighton) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) Redefining "PaintRoot" nolonger works in XNeWS with FCS. If X is running, my redefined "PaintRoot" gets ignored. How can I redefine the "PaintRoot" program so it works when both the X and NeWS servers are running? Russ From don Thu Jan 11 05:26:07 1990 Date: Thu, 11 Jan 90 05:26:07 -0500 To: NeWS-makers@brillig.umd.edu Subject: Record and Playback of events From: bcstec!sleepy!darryl@uunet.uu.net (Darryl Ljunghammar) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) I am trying to find a program that will record user generated events and then replay those events. I want this capability to test a window based application which is currently under development. My platform is a Sun 386i (SunOS 4.02) running the X/NeWS window server. The application will be run with the Motif window manager. I have looked at Journalling which comes with X/NeWS, however, it does not work (well) with the Motif window manager, as should be expected. I have also heard about Xghost but I don't know if it can be used with X/NeWS (I heard that the X server had to be modified in order to run Xghost but I don't know how involved that would be). What I would like is an X implemented program to record user events to a file and at some other time read that file and send those old events to the server to distribute to the clients. If you don't know of any such program do you know if one would be difficult to write from scratch ? Please e-mail to me directly (uunet!bcstec!sleepy!darryl) and thank you in advance. -- Darryl Ljunghammar (206)865-4567 Boeing Computer Services MS - 7M-44, P.O. Box 24346, Seattle, Wa 98124 ..uunet!bcstec!sleepy!darryl From don Thu Jan 11 22:44:29 1990 Date: Thu, 11 Jan 90 22:44:29 -0500 To: NeWS-makers@brillig.umd.edu Subject: SIGUCCS CALL for PARTICIPATION From: Amin Shafie - Univ of Cincinnati Comp Ctr Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) <-------------------------------------------------------------------- < < SIGUCCS User Services Conference XVIII < Call For Participation < < New Centerings in Computing Services < < September 30 through October 3, 1990 < < Westin Hotel < Cincinnati, Ohio < < <<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> << << <, mlandau@bbn.com (Matt Landau) writes: > This is a crock. The basic point is this: the X11 protocol simply > does not allow me, as an application writer, to decide what parts of > my application belong close to the user (in the server, where they > can provide fast feedback, etc.) and what parts belong in the client. > The only way for me to change this is to write my own server extensions > and only allow my application to run with servers that have my extensions. > In effect, I have to get into the X server business if I want to be > able to do certain things. > Stuff and nonsense. The X11 protocol does *allow* you to do this. You, as an application writer, are free to decide what part of your application belongs close to the user. You, as an application writer, can then write two programs, communicating by whatever means you choose, one of which is generally intended to execute on the same machine as your X server, bringing it about as close as is interesting. I'm not going to defend every aspect of X as perfect, but it seems to me that your point is not that X isn't as good a window system, but that it isn't as good at providing threads, defining communication protocols, being a programming language, and supplying dynamic loading. All quite true. But I don't understand why you don't want all of these things available to the part of your client that isn't coresident with your window system server. When I'm backpacking, I eat my food with a spoon that I bring along. When I'm in more civilized environs, I use nicer utensils. Right now, the operating system environments generally force you to eat with your fingers when you use X, and with your camping spoon when you use NeWS. Once we get around to buying some nice flatware, I'll rejoice that I didn't succumb to the temptation to have a spoon epoxied to my hand. Mark From don Thu Jan 11 22:51:28 1990 Date: Thu, 11 Jan 90 22:51:28 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Record and Playback of events From: amdahl!nsc!pyramid!unify!dgh@ames.arc.nasa.gov (David Harrington) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) In article <132@sleepy.UUCP> darryl@sleepy.UUCP (Darryl Ljunghammar) writes: > >What I would like is an X implemented program to record user events to a file and at some other time read that file and send those old events to the server to distribute to the clients. > >If you don't know of any such program do you know if one would be difficult to write from scratch ? > I am also interested in this capability. Could you please share, or post, any responses you get? TIA. -- David Harrington internet: dgh@unify.UUCP Unify Corporation ...!{csusac,pyramid}!unify!dgh 3870 Rosin Court voice: (916) 920-9092 Sacramento, CA 95834 fax: (916) 921-5340 From don Thu Jan 11 23:13:02 1990 Date: Thu, 11 Jan 90 23:13:02 -0500 To: NeWS-makers@brillig.umd.edu Subject: Re: Common toolkit From: wuarchive!texbell!ficc!peter@decwrl.dec.com (Peter da Silva) Sender: NeWS-makers-request@brillig.umd.edu (Don Hopkins) > Who else is left? NeXT, for one. Most of the large corporations and universities in the country. All of the small ones. All of the private individuals. The Free Software Foundation. Andy Tannenbaum's growing gang of MINIX maniacs. User groups. > If someone wants to make a new toolkit and give it away - > fine. > >But from a UI viewpoint, what does a $5000 DECstation > >buy you that you can't do with a $2000 Mac? > Want a list of a hundred things that are difficult to do with the Mac > interface? Important things? How about 100 things that are easy to do with the Mac interface... starting with the ability to monitor a background activity: something that X toolkit based stuff just can't handle. And how about Microsoft Windows, Intuition, and so on? The Mac is just an example that you're most likely to be familiar with. > Again, if you used both the Mac and some of the better toolkits, if > would be obvious how inadequate the Mac UI is. Even for simple things > like resizing/moving windows, starting up programs, and selecting filenames. No, the Mac is a sort of starting point for me. As you know, I much prefer Intuition. Intuition runs on a machine that's even cheaper than the Mac. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'