From fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 Mon Sep 17 00:00:00 2001 From: Joseph Hunkeler Date: Wed, 8 Jul 2015 20:46:52 -0400 Subject: Initial commit --- vendor/x11iraf/obm/docs/gui.doc/TclQuickRef.html | 208 ++ vendor/x11iraf/obm/docs/gui.doc/alphabetic.html | 39 + vendor/x11iraf/obm/docs/gui.doc/athena.gif | Bin 0 -> 1018 bytes vendor/x11iraf/obm/docs/gui.doc/athena.html | 73 + vendor/x11iraf/obm/docs/gui.doc/blueline.gif | Bin 0 -> 75 bytes vendor/x11iraf/obm/docs/gui.doc/book.p1.ps.gz | Bin 0 -> 201061 bytes vendor/x11iraf/obm/docs/gui.doc/clientclass.html | 75 + vendor/x11iraf/obm/docs/gui.doc/coloredline.gif | Bin 0 -> 5979 bytes vendor/x11iraf/obm/docs/gui.doc/einstein.html | 5 + vendor/x11iraf/obm/docs/gui.doc/example.html | 6 + vendor/x11iraf/obm/docs/gui.doc/exampmap | 30 + vendor/x11iraf/obm/docs/gui.doc/gmc.html | 402 ++++ vendor/x11iraf/obm/docs/gui.doc/gterm.gif | Bin 0 -> 1689 bytes vendor/x11iraf/obm/docs/gui.doc/gtermclass.html | 694 ++++++ vendor/x11iraf/obm/docs/gui.doc/gui.html | 93 + vendor/x11iraf/obm/docs/gui.doc/guiintro.html | 9 + vendor/x11iraf/obm/docs/gui.doc/imbrowse.gif | Bin 0 -> 4642 bytes .../obm/docs/gui.doc/imbrowsemap/controlForm.html | 3 + .../obm/docs/gui.doc/imbrowsemap/dirName.html | 3 + .../obm/docs/gui.doc/imbrowsemap/dirSelect.html | 3 + .../obm/docs/gui.doc/imbrowsemap/headerText.html | 3 + .../obm/docs/gui.doc/imbrowsemap/imageButton.html | 3 + .../x11iraf/obm/docs/gui.doc/imbrowsemap/none.html | 3 + .../obm/docs/gui.doc/imbrowsemap/objView.html | 3 + .../obm/docs/gui.doc/imbrowsemap/panel.html | 3 + .../obm/docs/gui.doc/imbrowsemap/sectionBox.html | 3 + .../obm/docs/gui.doc/imbrowsemap/statusBox.html | 3 + vendor/x11iraf/obm/docs/gui.doc/imtool.gif | Bin 0 -> 13848 bytes vendor/x11iraf/obm/docs/gui.doc/intro.gif | Bin 0 -> 228 bytes vendor/x11iraf/obm/docs/gui.doc/irafgui.gif | Bin 0 -> 1102 bytes vendor/x11iraf/obm/docs/gui.doc/llama.gif | Bin 0 -> 21774 bytes vendor/x11iraf/obm/docs/gui.doc/marker.gif | Bin 0 -> 1297 bytes vendor/x11iraf/obm/docs/gui.doc/newgui.html | 18 + vendor/x11iraf/obm/docs/gui.doc/notyet.html | 5 + vendor/x11iraf/obm/docs/gui.doc/notyet2.html | 5 + vendor/x11iraf/obm/docs/gui.doc/otherwidgets.html | 10 + vendor/x11iraf/obm/docs/gui.doc/params.gif | Bin 0 -> 420 bytes vendor/x11iraf/obm/docs/gui.doc/redline.gif | Bin 0 -> 75 bytes vendor/x11iraf/obm/docs/gui.doc/serverclass.html | 38 + vendor/x11iraf/obm/docs/gui.doc/servercom.html | 375 +++ vendor/x11iraf/obm/docs/gui.doc/softgui.gif | Bin 0 -> 381 bytes vendor/x11iraf/obm/docs/gui.doc/tcl.gif | Bin 0 -> 186 bytes vendor/x11iraf/obm/docs/gui.doc/tcl.html | 7 + .../x11iraf/obm/docs/gui.doc/uiparameterclass.html | 107 + vendor/x11iraf/obm/docs/gui.doc/widgetclass.html | 450 ++++ vendor/x11iraf/obm/docs/gui.doc/widgets.gif | Bin 0 -> 378 bytes vendor/x11iraf/obm/docs/gui.doc/widgets.html | 14 + vendor/x11iraf/obm/docs/gui.doc/ximclient.html | 194 ++ vendor/x11iraf/obm/docs/obm/Client.html | 75 + vendor/x11iraf/obm/docs/obm/Gterm.html | 694 ++++++ vendor/x11iraf/obm/docs/obm/Marker.html | 402 ++++ vendor/x11iraf/obm/docs/obm/Parameter.html | 107 + vendor/x11iraf/obm/docs/obm/Server.html | 38 + vendor/x11iraf/obm/docs/obm/Widget.html | 450 ++++ vendor/x11iraf/obm/docs/obm/alphabetic.html | 39 + vendor/x11iraf/obm/docs/obm/index.html | 2515 ++++++++++++++++++++ vendor/x11iraf/obm/docs/obm/obm.html | 2515 ++++++++++++++++++++ vendor/x11iraf/obm/docs/obm/servercom.html | 375 +++ vendor/x11iraf/obm/docs/tody.paper/todyd.html | 522 ++++ vendor/x11iraf/obm/docs/tody.paper/todyd1.gif | Bin 0 -> 5681 bytes vendor/x11iraf/obm/docs/tody.paper/todyd2.gif | Bin 0 -> 6468 bytes vendor/x11iraf/obm/docs/tody.paper/todyd3.gif | Bin 0 -> 3535 bytes 62 files changed, 10619 insertions(+) create mode 100644 vendor/x11iraf/obm/docs/gui.doc/TclQuickRef.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/alphabetic.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/athena.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/athena.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/blueline.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/book.p1.ps.gz create mode 100644 vendor/x11iraf/obm/docs/gui.doc/clientclass.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/coloredline.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/einstein.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/example.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/exampmap create mode 100644 vendor/x11iraf/obm/docs/gui.doc/gmc.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/gterm.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/gtermclass.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/gui.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/guiintro.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowse.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/controlForm.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirName.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirSelect.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/headerText.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/imageButton.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/none.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/objView.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/panel.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/sectionBox.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/statusBox.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/imtool.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/intro.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/irafgui.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/llama.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/marker.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/newgui.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/notyet.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/notyet2.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/otherwidgets.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/params.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/redline.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/serverclass.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/servercom.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/softgui.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/tcl.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/tcl.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/uiparameterclass.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/widgetclass.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/widgets.gif create mode 100644 vendor/x11iraf/obm/docs/gui.doc/widgets.html create mode 100644 vendor/x11iraf/obm/docs/gui.doc/ximclient.html create mode 100644 vendor/x11iraf/obm/docs/obm/Client.html create mode 100644 vendor/x11iraf/obm/docs/obm/Gterm.html create mode 100644 vendor/x11iraf/obm/docs/obm/Marker.html create mode 100644 vendor/x11iraf/obm/docs/obm/Parameter.html create mode 100644 vendor/x11iraf/obm/docs/obm/Server.html create mode 100644 vendor/x11iraf/obm/docs/obm/Widget.html create mode 100644 vendor/x11iraf/obm/docs/obm/alphabetic.html create mode 100644 vendor/x11iraf/obm/docs/obm/index.html create mode 100644 vendor/x11iraf/obm/docs/obm/obm.html create mode 100644 vendor/x11iraf/obm/docs/obm/servercom.html create mode 100644 vendor/x11iraf/obm/docs/tody.paper/todyd.html create mode 100644 vendor/x11iraf/obm/docs/tody.paper/todyd1.gif create mode 100644 vendor/x11iraf/obm/docs/tody.paper/todyd2.gif create mode 100644 vendor/x11iraf/obm/docs/tody.paper/todyd3.gif (limited to 'vendor/x11iraf/obm/docs') diff --git a/vendor/x11iraf/obm/docs/gui.doc/TclQuickRef.html b/vendor/x11iraf/obm/docs/gui.doc/TclQuickRef.html new file mode 100644 index 00000000..3f41eb29 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/TclQuickRef.html @@ -0,0 +1,208 @@ +Tcl Quick Reference + + +

TCL Quick Reference
+Based on TCL version 6.4
+Jeff Tranter 12-Aug-1992

+ + +
+Basic Language Features
+
+#	comment (continues to end of line)
+" "	allows embedding whitespace in arguments; substitutions made
+{ }	group arguments; substitutions not made
+[ ]	command substitution; replace with result of command
+$var	variable substitution
+;	command separator
+
+
+Backslash Substitution
+
+\b		backspace
+\[		open bracket
+\f		form feed
+\]		close bracket
+\n		newline
+\$		dollar sign
+\r		carriage return
+\	space
+\t		tab
+\;		semi-colon
+\v		vertical tab
+\"		double-quote
+\{		left brace
+\	newline
+\}		right brace
+\\		backslash
+\ddd		octal digits
+
+
+Built-in Variables
+
+env
+errorCode
+errorInfo
+
+
+Operators (in decreasing order of precedence)
+
+- ~ !	unary minus, bit-wise NOT, logical NOT
+* / %	multiply, divide, remainder
++ -	add, subtract
+<< >>	left and right shift
+< > <= >=	boolean comparisons
+== !=	boolean equal, not equa
+&	bit-wise AND
+^	bit-wise exclusive OR
+|	bit-wise inclusive OR
+&&	logical AND
+||	logical OR
+x?y:z	conditional operator
+
+All operators support integers.
+All support floating point except ~, %, <<, >>, &, ^, and |
+Boolean operators can also be used on strings.
+
+
+Regular Expressions
+regex | regex	match either expression
+regex*	match zero or more of regex
+regex+	match one or more of regex
+regex?	match zero or one of regex
+.	any single character (except newline)
+^	match beginning of line
+$	match end of line
+\c	match character c
+c	match character c
+[]	match set of characters
+[a-z]	match range of characters
+[^]	match characters not in range or set
+()	group expressions
+
+
+Keywords
+
+append varName value [value value ...]
+array anymore arrayName searchId
+array donesearch arrayName searchId
+array names arrayName
+array nextelement arrayName searchId
+array size arrayName
+array startsearch arrayName
+break
+case string [in] patList body [patList body ...]
+case string [in] {patList body [patList body ...]
+catch command [varName]
+cd [dirName]
+close fileId
+concat arg [arg ...]
+continue
+error message [info] [code]
+eof fileId
+error $errMsg $savedInfo
+eval arg [arg ...]
+exec arg [arg ...]
+exit [returnCode]
+expr arg
+file atime name
+file dirname name
+file executable name
+file exists name
+file extension name
+file isdirectory name
+file isfile name
+file lstat name varName
+file mtime name
+file owned name
+file readable name
+file readlink name
+file rootname name
+file size name
+file stat  name varName
+file tail name
+file type name
+file writable name
+flush fileId
+for start test next body
+foreach varname list body
+format formatString [arg arg ...]
+gets fileId [varName]
+glob [-nocomplain] filename [filename ...]
+global varname [varname ...]
+history
+history add command [exec]
+history change newValue [event]
+history event [event]
+history info [count]
+history keep count
+history nextid
+history redo [event]
+history substitute old new [event]
+history words selector [event]
+if test [then] trueBody [else] [falseBody]
+incr varName [increment]
+info args procname
+info body procname
+info cmdcount
+info commands [pattern]
+info default procname arg varname
+into variable varname
+info exists varName
+info globals [pattern]
+info level [number]
+info library
+info locals [pattern]
+info procs [pattern]
+info script
+info tclversion
+info vars [pattern]
+join list [joinString]
+lappend varName value [value value ...]
+lindex list index
+linsert list index element [element element ...]
+list arg [arg ...]
+llength list
+lrange list first last
+lreplace list first last [element element ...]
+lsearch list pattern
+lsort list
+open fileName [access]
+proc name args body
+puts fileId string [nonewline]
+pwd
+read fileId
+read fileId nonewline
+read fileId numBytes
+regexp [-indices] [-nocase] exp string [matchVar] [subMatchVar subMatchVar ...]
+regsub [-all] [-nocase] exp string subSpec varName
+rename oldName newName
+return [value]
+scan string format varname1 [varname2 ...]
+seek fileId offset [origin]
+set varname [value]
+source fileName
+split string [splitChars]
+string compare string1 string2
+string first string1 string2
+string index string charIndex
+string last string1 string2
+string length string
+string match pattern string
+string range string first last
+string tolower string
+string toupper string
+string trim string [chars]
+string trimleft string [chars]
+string trimright string [chars]
+tell fileId
+time command [count]
+trace variable name ops command
+trace vdelete name ops command
+trace vinfo name
+unknown cmdName [arg arg ...]
+unset name [name name ...]
+uplevel [level] command [command ...]
+upvar [level] otherVar myVar [otherVar myVar ...]
+while test body
+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/alphabetic.html b/vendor/x11iraf/obm/docs/gui.doc/alphabetic.html new file mode 100644 index 00000000..0c141617 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/alphabetic.html @@ -0,0 +1,39 @@ +Alphabetized list of GUI commands + +
+activate	activate	activeMapping	addCallback	addCallback
+addCallback	addCallback	addEventHandler	append		appInitialize
+assignRaster	bell		call		clearScreen	configure	
+copyPixmap	copyRaster	createBitmap	createCursor	createMarker	
+createMenu	createObjects	createPixmap	createPixmap	createRaster	
+deactivate	deactivate	deleteCallback	deleteCallback	deleteTimedCallback	
+deleteWorkCallback		destroy		destroyMenu	destroyObject	
+destroyRaster	disableMapping	drawAlphaText	drawDialogText	drawMarker	
+drawPolygon	drawPolyline	drawPolymarker	editMenu	enableMapping	
+encodewcs	endDialog	eraseDialog	fitFrame	flip	
+flip		flush		freeColormap	freeMapping	gcmd	
+get		get		getAlphaTextSize		getAttribute
+getAttributes	getCursorPos	getDialogTextSize		getFrame	
+getItem		getLogRes	getMapping	getPhysRes	getPixel	
+getRaster	getRect		getRegion	getResource	getResources	
+getValue	getVertices	gkey		highlight	initMappings	
+isRealized	isSensitive	literal		loadColormap	lower	
+makeCopy	manage		map		markerInit	markpos	
+matchFrames	move		move		nextColormap	nextFrame	
+nextMapping	nextRaster	notify		notify		nRasters	
+pan		popdown		popdown		popup		popup	
+popupSpringLoaded		postActivateCallback		postTimedCallback	
+postWorkCallback		prevFrame	print		queryRaster	
+Quit		raise		rasterInit	readColormap	readPixels	
+realize		redraw		refreshMapping	refreshPixels	reset-server	
+reset		resize		resize		retCursorVal	rotate	
+selectRaster	send		set		set		setAttribute	
+setAttributes	setColorIndex	setColormap	setCursorPos	setCursorType	
+setDataLevel	setFillType	setFrame	setGterm	setLineStyle	
+setLineWidth	setList		setLogRes	setMapping	setPhysRes	
+setPixel	setRaster	setSensitive	setTextRes	setValue	
+setVertices	startDialog	unhighlight	unmanage	unmap	
+unmapPixel	unrealize	userEventHandler		windowColormap	
+writeColormap	writePixels	zoom		zoomAbs	
+
+ diff --git a/vendor/x11iraf/obm/docs/gui.doc/athena.gif b/vendor/x11iraf/obm/docs/gui.doc/athena.gif new file mode 100644 index 00000000..56e74e96 Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/athena.gif differ diff --git a/vendor/x11iraf/obm/docs/gui.doc/athena.html b/vendor/x11iraf/obm/docs/gui.doc/athena.html new file mode 100644 index 00000000..dcd3decf --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/athena.html @@ -0,0 +1,73 @@ +Athena Widgets +

Athena Widgets

+ +

+The Athena widgets were written at MIT. Each of the widget names is a +hypertext link to a page describing the widget and including an example. +

+

Simple Widgets

+
+
Command +
A push button that, when selected, may cause a specific action +to take place. This widget can display a multi-line string or a bitmap image. +
Grip +
A rectangle that, when selected, will cause an action to take +place. +
Label +
A rectangle that may contain one or more lines of text or a bitmap image. +
List +
A list of text strings presented in row column format that may be +individually selected. When an element is selected an action may take place. +
Panner +
A rectangular area containing a slider that may be moved in two +dimensions. Notification of movement may be continuous or discrete. +
Repeater +
A push button that triggers an action at an increasing rate when selected. +
Scrollbar +
A rectangular area containg a thumb that, when slid along one +dimension, may cause a specific action to take place. The Scrollbar may +be oriented horixontall or vertically. +
Simple +
The vase class for most of the simple widgets. Provides a rectangular +area with a settable mouse cursor and special border. +
StripChart +
A real time data graph that will automatically update and scroll. +
Toggle +
A push button [see Command] that contains state information. Toggles +may also be used as radio buttons to implement a "one of many" group of +buttons. +
+

Text Widgets

+
+
Text +
Basic text widget supports edit commands. +
AsciiText +
This widget contains a text widget and also includes AsciiSrc and +and AsciiSink widgets. +
+

Composite and Constraint Widgets

+
+
Box +
This widget will pack its children as tightly as possible in +non-overlapping rows. +
Dialog +
An implementation of a commonly used interaction semantic to +prompt for auxiliary input from the user, such as a filename. +
Form +
A more sophisticated layout widget that allows the children to specify +their positions relative to the other children, or to the edges of the form. +
Paned +
Allows children to be tiled vertically or horizontally. Controls are also +provided to allow the user to dynamically resize the individual panes. +
Porthole +
Allows viewing of a managed child which is as large as, or larger than its +parent, typically under control of a Panner widget. +
Tree +
Provides geometry management of widgets arranged in a directed, acyclic +graph. +
Viewport +
Consists of a frame, one of two scrollbars, and an inner window. The +inner window can contain all the data that is to be displayed. This inner +window will be clipped by the frame with the scrollbars controlling which +section of the inner window is currently visible. +
diff --git a/vendor/x11iraf/obm/docs/gui.doc/blueline.gif b/vendor/x11iraf/obm/docs/gui.doc/blueline.gif new file mode 100644 index 00000000..d911fe03 Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/blueline.gif differ diff --git a/vendor/x11iraf/obm/docs/gui.doc/book.p1.ps.gz b/vendor/x11iraf/obm/docs/gui.doc/book.p1.ps.gz new file mode 100644 index 00000000..360e4950 Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/book.p1.ps.gz differ diff --git a/vendor/x11iraf/obm/docs/gui.doc/clientclass.html b/vendor/x11iraf/obm/docs/gui.doc/clientclass.html new file mode 100644 index 00000000..407c177b --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/clientclass.html @@ -0,0 +1,75 @@ +CLIENT class +

CLIENT class

+

+

+

+The client is the client application, which provides the functionality +underlying the UI. When a message is sent to the client object it usually +results in a message being sent to the client *application*, usually an +external program communicating via IPC, which has little or no knowledge +of the UI. The client application receives and executes commands delivered +by the UI via the client object. Output from the client may or may not +come back to the object manager. That portion of the output which comes +back to the object manager is in the form of assignments of string values +to UI parameter-class objects (another +way of thinking of this is that +messages or events are sent to and acted upon by the parameter objects). +Hence, the client object is output only so far as the client application +is concerned. +

+The Client-class commands are used to send a message to the client. +

+

+                gkey <key>
+                gcmd <command-string>
+             literal <command>
+
+

+or just <command>, e.g., "send client <command>" will work in most cases. +

+GKEY sends an IRAF graphics keystroke. +GCMD sends an +IRAF graphics colon command. LITERAL sends a literal +command string to the +client. The keyword "literal" may optionally be omitted, i.e., "send client +foo" and "send client literal foo" are the same. The keyword "literal" may +be used to ensure that the client command string which follows will not +be interpreted as a Client-class command (such as gkey, gcmd, or literal). +

+

+

gcmd

+

+Send a graphics command string to the client application. +A graphics command string is a graphics cursor value with the key set +to `:' and the command string given as the string part of the cursor +value. The protocol module which posted the client output procedure is +responsible for encoding and sending the cursor command. +

+Usage: +

+

+        gcmd <command-string>
+
+

+

gkey

+

+Send a graphics key event to the client application. +A graphics key event is a graphics cursor value with the key set to some +integer value and a null string part. +

+Usage: +

+

+gkey <key>
+
+

+

literal

+

+Send a literal command to the client application. +

+Usage: +

+

+        literal <command>
+
+ diff --git a/vendor/x11iraf/obm/docs/gui.doc/coloredline.gif b/vendor/x11iraf/obm/docs/gui.doc/coloredline.gif new file mode 100644 index 00000000..f08eb184 Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/coloredline.gif differ diff --git a/vendor/x11iraf/obm/docs/gui.doc/einstein.html b/vendor/x11iraf/obm/docs/gui.doc/einstein.html new file mode 100644 index 00000000..1d6e1927 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/einstein.html @@ -0,0 +1,5 @@ +Einstein +

+ +Yep, that's uncle Albert! +

diff --git a/vendor/x11iraf/obm/docs/gui.doc/example.html b/vendor/x11iraf/obm/docs/gui.doc/example.html new file mode 100644 index 00000000..40b0b4cd --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/example.html @@ -0,0 +1,6 @@ +Example: Imbrowse +

Example: Imbrowse

+ +

+ +

diff --git a/vendor/x11iraf/obm/docs/gui.doc/exampmap b/vendor/x11iraf/obm/docs/gui.doc/exampmap new file mode 100644 index 00000000..d2284a37 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/exampmap @@ -0,0 +1,30 @@ + +default imbrowsemap/none.html + +# The ellipse containing "panel" +rect imbrowsemap/panel.html 287,19 366,56 + +# The ellipse containing "objView" +rect imbrowsemap/objView.html 226,98 312,130 + +# The ellipse containing "controlForm" +rect imbrowsemap/controlForm.html 266,154 382,186 + +# The ellipse containing "headerText" +rect imbrowsemap/headerText.html 336,96 450,130 + +# The ellipse containing "sectionBox" +rect imbrowsemap/sectionBox.html 461,99 577,131 + +# The ellipse containing "statusBox" +rect imbrowsemap/statusBox.html 75,158 202,190 + +# The ellipse containing "dirSelect" +rect imbrowsemap/dirSelect.html 7,280 95,320 + +# The ellipse containing "dirName" +rect imbrowsemap/dirName.html 74,342 167,380 + +# The ellipse containing "imageButton" +rect imbrowsemap/imageButton.html 171,280 298,315 + diff --git a/vendor/x11iraf/obm/docs/gui.doc/gmc.html b/vendor/x11iraf/obm/docs/gui.doc/gmc.html new file mode 100644 index 00000000..9e124846 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/gmc.html @@ -0,0 +1,402 @@ +Graphics Marker class +

Graphics Marker class

+

+

+

+A marker is a graphics object implemented by the Gterm-Image widget. +Markers are not real toolkit widgets, but they act much like widgets and +are interfaced as an object class under the Object Manager. The Marker +class is not a subclass, it is a base class like Widget, but Marker objects +can exist only as children of Gterm widgets. +

+Since markers are not independent widgets but rather part of a Gterm widget +instance, the parent Gterm widget is partially responsible for managing +markers. The Gterm widget implements the following commands for dealing +with markers. +

+

+               createMarker name [attribute-list]
+                 markerInit
+
+

+A new marker is created by sending the createMarker message to the parent +gterm widget. This creates a marker of the given name and type. +The markerInit command, if sent to a gterm widget, destroys any markers +defined for that widget and reinitializes the marker facility. Markers +may also be created by action procedures in response to user input events. +

+A marker may be destroyed by itself in response to an input event (e.g. the +user presses the delete key), by sending the marker the destroy message +to tell it to destroy itself, by sending a markerInit to the parent gterm +widget, or by destroying the marker object (or any parent) with the server +command destroyObject. +

+Once a marker has been created it behaves as an independent object and +receives and executes messages, responds to events, generates callbacks, +and so on. The marker class defines the following commands. +

+

+                makeCopy name
+             addCallback procedure [event [event ...]]
+                  notify [event-type [param [param ...]]]
+                 destroy [nocallback]
+

+                 markpos
+                  redraw [function] [markpos|nomarkpos] [erase|noerase]
+

+                   raise [reference-marker]
+                   lower [reference-marker]
+

+                    move x y
+                  resize width height
+                  rotate angle                # radians
+

+                     set attribute value      # alias for setAttribute
+             value = get attribute            # alias for getAttribute
+

+            setAttribute attribute value
+    value = getAttribute attribute
+           setAttributes attribute-list
+           getAttributes attribute-list
+             setVertices points first npts
+             getVertices points first npts
+

+      region = getRegion [unmap] [coord-type]
+                 getRect dx dy dnx dny
+
+

+Marker positions and dimensions are given in window (raster 0) coordinates. +

+The operators raise, lower, move, resize, and rotate erase the marker, +modify it as indicated, and redraw it with the new attributes. For finer +control over marker attributes one can use [get|set]Attribute[s] and +[get|set]Vertices to edit the markers directly. In this case an auto +redraw is not performed (unless the autoRedraw marker attribute is set). +The usual sequence is a markpos to record the marker position, one or more +setAttribute calls to change marker attributes, then a redraw to erase +the old marker and redraw the new one. Markers have many attributes which +can be set to control things like the position and size, colors, line +widths, fill type and style, font, rubber-band technique, and so on. +Refer to <ObmW/Gterm.h> for a list of marker types and attributes. +

+The marker type may be changed at runtime without destroying the marker. +For example a circle can be changed to an ellipse or a rectangle. This +also works for polygons (the vertex list is preserved and restored when +the marker is changed back to a polygon). +

+The current shape of a marker may be queried with getVertices, which +returns the polygon or polyline vertex list in window coordinates. A more +powerful routine which does something similar is getRegion. This routine +returns a high level description of the region outlined by the marker, +giving the marker type (rectangle, circle, ellipse etc.), center, width +and height, and so on. Any position or dimension information may +optionally be transformed back to the original source raster, if the marker +center is in a region of the window which is the destination of an active +mapping. The unmap option will follow multiple mappings back to the +original mapped source raster. +

+The getRect function returns the parameters of the region outlined by a +rectangle marker in a form convenient for use in a Gterm setMapping call +(this is used to display an image within a marker). +

+Default translations when pointer is over a marker. +default Marker Translations +

+

+        Shift < Btn1Motion >i    m_rotateResize()             
+              < Btn1Motion >    m_moveResize()               
+          Shift < Btn1Down >    m_raise()  m_markpos()       
+                < Btn1Down >    m_raise()  m_markposAdd()    
+                  < Btn1Up >    m_redraw() m_destroyNull()   
+                < Btn2Down >    m_lower()                    
+            < Key > BackSpace   m_deleteDestroy()            
+               < Key > Delete   m_deleteDestroy()            
+                < KeyPress >    m_input()                    
+                  < Motion >    track-cursor()               
+
+

+MARKER class commands. +

+makeCopy +

+Copy a marker. The new marker is initially identical to the +old one, and will not be distinct until, e.g., moved to a new center. +

+Usage: +

+

+         makeCopy name
+
+

+

addCallback

+

+Post a marker callback to be called when the specified +event or events occurs. If no events are listed a Notify callback will +be posted. +

+Usage: +

+

+	addCallback procedure [event [event ...]]
+
+

+

notify

+

+Generate a Marker pseudo-event, causing any posted client +callback procedures to be called. +

+Usage: +

+

+        notify [event-type [param [param ...]]]
+
+

+

destroy

+

+Destroy a marker. Just tell the marker to destroy itself. +All cleanup outside the marker facility relies upon the use of callbacks. +This includes our callback markerDestroyCallback below. +

+Usage: +

+

+        destroy
+
+

+

markpos

+

+Mark the current position of a marker for a later redraw. +

+Usage: +

+

+        markpos
+
+

+Markpos is used to mark the position of a marker before changing any +marker attributes, so that a later "redraw marked" will erase the old +marker rather than the new one. This is necessary, for example, if any +marker attributes are changed which affect the size or position of the +marker. +

+

redraw

+

+Redraw a marker. +

+Usage: +

+

+        redraw [function] [erase|noerase] [markpos|nomarkpos]
+
+

+By default redraw will erase the old marker at the position indicated by +a previous call to markpos, and redraw the marker with the current +attributes using the drawing function copy (copy source to destination). +Hence the usual usage is "markpos ... change marker attributes ... redraw". +Optional arguments may be given to change the drawing function, enable or +disable erase, or force redraw to do a markpos. These arguments may be +given in any order. +

+The drawing functions are as given in the XLIB documentation, minus the +"GX" prefix. The most commonly used functions are "copy" and "xor". +A normal marker redraw uses function=copy. +

+

raise

+

+Raise a marker, i.e., cause it to be drawn on top of other +markers when overlapping markers are drawn. +

+Usage: +

+

+        raise [reference-marker]
+
+

+In a reference marker is named the marker will raise itself above this +marker, otherwise the raised marker becomes the topmost marker. +

+

lower

+

+Lower a marker, i.e., cause it to be drawn beneath other +markers when overlapping markers are drawn. +

+Usage: +

+

+        lower [reference-marker]
+
+

+In a reference marker is named the marker will lower itself beneath this +marker, otherwise the lowered marker becomes the lowest marker. +

+

move

+

+Move a marker. +

+Usage: +

+

+        move x y
+
+

+Move the marker center to the indicated coordinates in the display window. +

+

resize

+

+Resize a marker. +

+Usage: +

+

+         resize width height
+
+

+Resize the marker to the indicated size. By default width and height are +given in pixels. For a text marker one can append "ch" to indicate that +the units are chars in whatever font is in use, e.g., "40ch" or "40 chars" +is an acceptable value for a text marker dimension. +

+

rotate

+

+Rotate a marker. +

+Usage: +

+

+         rotate angle
+
+

+Redraw a marker oriented to the given rotation angle. The angle is +given in radians. +

+

getAttribute

+

+Return the value of a marker attribute. +

+Usage: +

+

+        value = getAttribute attribute-name
+
+

+

setAttribute

+

+Set the value of a marker attribute. +

+Usage: +

+

+        setAttribute attribute-name value
+
+

+

getAttributes

+

+Return the values of a list of marker attributes. +

+Usage: +

+

+          getAttributes attribute-list
+  i.e.    getAttributes {name value [name value ...]}
+    or    getAttributes name value [name value ...]
+
+

+where "value" is the name of the variable in which the attribute value +is to be stored. +

+

setAttributes

+

+Set the values of a list of marker attributes. +

+Usage: +

+

+        setAttributes attribute-list
+  i.e.  setAttributes {name value [name value ...]}
+
+

+where "value" is the new value of the associated marker attribute. +

+

getVertices

+

+Get some or all of the vertices making up the polygon or +polyline representation of a marker. +

+Usage: +

+

+        getVertices points [first npts]
+
+

+The polygon or polyline representation of a marker is returned in the +variable "points", as a string of the form { {x y} {x y} ...}. The first +point is number zero. +

+

setVertices

+

+Set some or all of the vertices making up the polygon or +polyline representation of a marker. +

+Usage: +

+

+        setVertices points [first npts]
+
+

+The polygon or polyline representation of a marker is set using the points +passed in the "points" variable as a string of the form { {x y} {x y} ...}. +If FIRST and NPTS are not specified first is assumed to be zero (the first +point) and NPTS is the length of the points array. +

+

getRegion

+

+Return as a text string a high level description of the +region defined by a marker. +

+Usage: +

+

+        region = getRegion [unmap] [coord-type]
+
+

+The output string defines the marker type and the major marker positional +attributes. The region description formats for the various marker types +follow. +

+

+        text raster x y width height
+        line raster x y x y
+        polyline raster npts { {x y} {x y} ...}
+        rectangle raster x y width height rotangle
+        circle raster x y radius
+        ellipse raster x y width height rotangle
+        polygon raster npts { {x y} {x y} ...}
+
+

+Here, width and height refer to the distance from the marker center to an +edge, not to the width or height of the whole marker. This avoids +ambiguities about where the edge of a marker is if the width is even or +odd. Using the center to edge measurement, the edge is at x +/- width, +y +/- height. +

+If the "unmap" flag is given getRegion will attempt to associate the +marker with a mapped raster, reversing any mappings from the screen back +to the original source raster, and returning the raster number and raster +coordinates and marker sizes. If "unmap" is not given the marker +coordinates will refer to raster 0. Either pixel ("pixel") or NDC +("ndc") coordinates may be returned, pixel coordinates being the default. +

+

getRect

+

+Return the region enclosed by a rectangle marker. The rect is +returned in a form convenient for use as the destination rect in a gterm +widget raster mapping. +

+Usage: +

+

+        getRect dx dy dnx dny
+
+

+The rect is stored in the output arguments. +

diff --git a/vendor/x11iraf/obm/docs/gui.doc/gterm.gif b/vendor/x11iraf/obm/docs/gui.doc/gterm.gif new file mode 100644 index 00000000..042debf5 Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/gterm.gif differ diff --git a/vendor/x11iraf/obm/docs/gui.doc/gtermclass.html b/vendor/x11iraf/obm/docs/gui.doc/gtermclass.html new file mode 100644 index 00000000..5fcdab10 --- /dev/null +++ b/vendor/x11iraf/obm/docs/gui.doc/gtermclass.html @@ -0,0 +1,694 @@ +Gterm-Image widget class +

Gterm-Image widget class (a subclass of Widget).

+

+

+

+The gterm-image widget is a general 2D graphics-imaging widget providing +a wide range of facilities for drawing graphics and text, for image +display, and for graphics interaction. Normally the client communicates +directly with the Gterm widget to draw graphics, download image data, +and so on, using some communications protocol outside the domain of the +object manager. Nonetheless so far as possible the facilities of the Gterm +widget have also been made available to GUI code via the commands listed +here. +

+The Gterm widget adds the following function to the OBM library. +

+

+    ObmPostSetGtermCallback (obm, &setgterm, setgterm_client_data)
+
+

+This is called by a client application to post a procedure to be called +when a gterm widget receives the setGterm command. The calling sequence +for setGterm callback is as follows: +

+

+                   setgterm (client_data, gterm_widget)
+
+

+The purpose of this callback is to tell the client which gterm widget is +the "active" gterm widget. This is used by clients which only support +one active Gterm widget, i.e., which can only direct graphics output to +one Gterm widget at a time. +

+The messages or commands that can be sent to the Gterm widget by GUI +code follow. +

+General commands: +

+

+                   setGterm          # make widget the active Gterm
+

+                   activate
+                 deactivate
+                addCallback procedure-name callback-type
+                      reset
+                      flush
+

+               setCursorPos x y [raster]
+               getCursorPos x y
+              setCursorType cursortype
+                       bell
+
+

+Graphics drawing commands: +

+

+                  setRaster raster
+         raster = getRaster [raster]
+

+                  setLogRes width height (unimplimented)
+                  getLogRes width height (unimplimented)
+                 setPhysRes width height (unimplimented)
+                 getPhysRes width height (unimplimented)
+                 setTextRes rows cols (unimplimented)
+               setDataLevel level (unimplimented)
+               setLineWidth width (unimplimented)
+               setLineStyle style (unimplimented)
+              setColorIndex index (unimplimented)
+                setFillType filltype (unimplimented)
+

+                clearScreen
+               drawPolyline vector (unimplimented)
+             drawPolymarker vector (unimplimented)
+                drawPolygon vector (unimplimented)
+                 drawMarker x y xsize ysize type (unimplimented)
+

+              drawAlphaText x y text (unimplimented)
+           getAlphaTextSize string width height base (unimplimented)
+                startDialog (unimplimented)
+                  endDialog (unimplimented)
+                eraseDialog (unimplimented)
+             drawDialogText x y text (unimplimented)
+          getDialogTextSize string width height base (unimplimented)
+
+

+The coordinates used in the graphics drawing commands are logical +coordinates as defined by setLogRes, in the coordinate system of the +reference drawing raster as defined by setRaster. The default reference +raster is raster zero, the widget's window. Vectors are specified as +a list of points, e.g., { {x y} {x y} ... }. +

+Imaging commands: +

+

+              rasterInit
+            assignRaster raster drawable (unimplimented)
+            createRaster raster type width height depth (unimplimented)
+           destroyRaster raster (unimplimented)
+    exists = queryRaster raster type width height depth (unimplimented)
+     raster = nextRaster [raster] (unimplimented)
+     nrasters = nRasters [nrasters] (unimplimented)
+

+                setPixel raster x y value
+        value = getPixel raster x y
+             writePixels raster pixels encoding x1 y1 nx ny
+              readPixels raster pixels encoding x1 y1 nx ny
+           refreshPixels raster ct x1 y1 nx ny (unimplimented)
+   pixmap = createPixmap src x y width height (unimplimented)
+              copyPixmap pixmap dst x y width height (unimplimented)
+

+ colormap = nextColormap [colormap] (unimplimented)
+            freeColormap colormap (unimplimented)
+           writeColormap colormap first nelem colors (unimplimented)
+            readColormap colormap first nelem colors (unimplimented)
+            loadColormap colormap offset scale
+

+            initMappings (unimplimented)
+   mapping = nextMapping [mapping]
+             freeMapping mapping (unimplimented)
+           enableMapping mapping (unimplimented)
+          disableMapping mapping (unimplimented)
+  active = activeMapping mapping (unimplimented)
+          refreshMapping mapping (unimplimented)
+

+   raster = selectRaster dras dt dx dy rt rx ry [map]
+              unmapPixel sx sy raster rx ry [rz]
+

+              copyRaster rop src  st sx sy snx sny  dst dt dx dy dnx dny (unimplimented)
+              setMapping mapping rop
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+              getMapping mapping rop 
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+

+                    flip mapping axis [axis...]
+
+

+Pixel arrays are long strings consisting either of a sequence of numeric +pixel values separated by whitespace (space or newline), or a hex encoded +sequence of bytes (2 hex digits per 8 bit pixel). Colors are specified +as a list of RGB triplets, e.g., { {R G B} {R G B} ... }. +

+Refer to the documentation for the Gterm widget for a detailed description +of rasters, mappings, and colormaps. +

+Markers: +

+

+               createMarker name [attribute-list]
+                 markerInit
+
+

+New markers may be created with createMarker. Once created, a marker +functions under the Object Manager as a named object of class "marker". +Refer to the marker class for a description of the commands defined for +a marker. +

+gterm Actions List +

+

+        ignore
+        graphics-input
+        graphics-context
+        crosshair
+        track-cursor
+        enter-window
+        leave-window
+        popup-menu     {not implemented}
+        reset
+        m_create
+
+

+Default translations for Gterm window. +Omitted for now: Ctrl ~Meta : popup-menu(tekMenu) +

+default Gterm Translations +

+

+               [Btn1Down]:m_create()                   
+               [Btn2Down]:crosshair(on)                
+             [Btn2Motion]:crosshair(on)                
+                 [Btn2Up]:crosshair(off)               
+   ~Ctrl ~Meta [Btn3Down]:graphics-context()           
+            [EnterWindow]:enter-window()               
+            [LeaveWindow]:leave-window()               
+               [KeyPress]:graphics-input()             
+                 [Motion]:track-cursor()               
+
+

+

+GTERM class commands.
+

+
setGterm

+

+Set the active Gterm widget.  A UI can have more than one
+gterm widget, but due to restrictions on the client-server interface, it
+may be possible for only one to receive client output at any one time (any
+gterm widget can generate input to be sent to the client).  If the client
+has this restriction, the client-server interface code which uses OBM can
+call the ObmPostSetGtermCallback procedure to post a function to be called
+when the UI code calls the setGterm procedure.
+

+Usage:
+

+
+        setGterm
+

+

+
activate

+

+Activate the gterm widget.   This causes the next GIN mode
+setCursorType to warp the pointer into the gterm window.
+

+Usage:
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the gterm widget.   If the cursor has been warped
+into the window by a previous activate/setCursorType GIN mode, this causes
+the cursor to be warped back to where it was previously.
+

+Usage:
+

+
+        deactivate
+

+

+
reset

+

+Reset the gterm widget.  This causes a number of state variables
+affecting graphics drawing options to be set to their default values.
+

+Usage:
+

+
+        reset
+

+

+
flush

+

+Flush any graphics output and synchronize the state of the widget
+with what is shown on the display.
+

+Usage:
+

+
+        flush
+

+

+The gterm widget uses XLIB, which buffers graphics drawing commands and
+automatically sends them to the X server when 1) the buffer fills,
+2) input is requested from the server.  Such buffering of data is necessary
+for efficient operation and it should rarely be necessary to explicitly
+flush graphics output since XLIB does this automatically in most cases.
+An example of when explicitly flushing the ouptut might be necessary is in
+cases where smooth animation is desired and drawing the graphics in batches
+could cause the display to appear "jerky".
+

+
addCallback

+

+Post a callback for a Gterm widget event.
+

+Usage:
+

+
+        addCallback procedure-name [callback-type]
+

+

+The recognized Gterm callbacks are
+

+
+
+        input           Called when the graphics-input action is invoked in
+                        a translation table.  The default Gterm translation
+                        table invokes this action when a KeyPress event occurs
+                        in the Gterm window.
+                        Callback:        widget-name input-type event-data
+
+        resize          Called when the gterm window is resized.
+                        Callback:        widget-name width height
+
+        reset           Called when the "reset" action is invoked.
+                        Callback:        widget-name
+
+
+

+If no callback is specified the default is "input".
+

+Note that in GUI code one can also use the translation table to directly
+invoke GUI procedures without need to use the Gterm input mechanism.  This
+is more flexible but we support the Gterm input callback here for
+applications that use the default translations.
+

+
setCursorPos

+

+Warp the cursor (pointer) to the given coordinates.  This
+is a graphics drawing command and if no raster number is specified the
+current reference drawing raster, as set with setRaster, defines the
+coordinate system.
+

+Usage:
+

+
+        setCursorPos x y [raster]
+

+

+A raster number may optionally given to define the raster coordinate system
+to be used.  raster=0 yields screen coordinates.
+

+
getCursorPos

+

+Get the cursor position (raster 0 or screen coordinates).
+

+Usage:
+

+
+        getCursorPos x y
+

+

+
setCursorType

+

+Set the cursor type.
+

+Usage:
+

+
+        setCursorType cursor-type
+
+        idle        default cursor
+        busy        busy cursor, e.g, when program is busy
+        ginMode     graphics input mode cursor, set when program is
+                    waiting for graphics input
+

+

+
bell

+

+Gterm widget sound output.
+

+Usage:
+

+
+        bell
+

+

+
setRaster

+

+Set the number of the raster to be used to define the drawing
+context (e.g. coordinate system) for graphics and text drawing functions.
+

+Usage:
+

+
+        setRaster raster-number
+

+

+
getRaster

+

+Get the number of the raster which defines the drawing
+context, as set in the last setRaster call.
+

+Usage:
+

+
+        raster = getRaster [raster]
+

+

+If the name of a variable is given the raster number will be stored 
+directly in that variable.
+

+
clearScreen

+

+Clear the "screen", i.e., window.  This action clears the
+drawing window and sets a number of drawing state variables to their default
+values.
+

+Usage:
+

+
+        clearScreen
+

+

+
rasterInit

+

+Initialize the raster subsystem, deleting all rasters and
+mappings and freeing the dynamic part of the colortable.
+

+Usage:
+

+
+        rasterInit
+

+

+
writePixels

+

+Set the values of some subset of the pixels in a raster.
+If any mappings are defined on the affected region and are enabled, any
+destination rasters will be automatically updated as defined by the mapping.
+

+Usage:
+

+
+        writePixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster       The raster number.
+        pixels       The pixel array, encoded as a string.
+        encoding     The pixel encoding.  "numeric" means each pixel is
+                     encoded as a decimal integer delimited by whitespace.
+                     "hex" means the pixel array is hex encoded, 2 bytes
+                     per 8 bit pixel, as a printable text string.  The
+                     two bytes are defined as follows (v = pixel value):
+
+                          byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                          byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                     Whitespace in a hex encoded string is ignored.
+                     Hex encoding reduces the data volume by about a factor
+                     of two (compared to numeric) and is only a factor of
+                     two less space efficient than binary.
+
+        nbits        Number of bits per pixel - currently only 8 bit pixels
+                     are supported.
+
+        x1,y1,nx,ny  Region of the raster to be written.
+

+

+Most real-world image processing applications get the Gterm widget handle
+with setGterm and pass binary data to the widget by calling GtWritePixels
+directly.  This is the most efficient approach for serious image processing
+where large amounts of data are involved.  However, being able to read and
+write raster pixels directly in a GUI can be useful in specialized
+applications, e.g., where the image is computed or modified by the GUI.
+

+
setPixel

+

+Set the value of a single pixel.
+

+Usage:
+

+
+        setPixel raster x y value
+
+        raster   The raster number.
+        x, y     The pixel to be set.
+        value    The pixel value.
+

+

+This routine is more efficient than writePixels for setting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be set.
+

+
readPixels

+

+Get the values of some subset of the pixels in a raster.
+

+Usage:
+

+
+        readPixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster        The raster number.
+        pixels        The pixel array, encoded as a string.
+        encoding      The pixel encoding.  "numeric" means each pixel is
+                      encoded as a decimal integer delimited by whitespace.
+                      "hex" means the pixel array is hex encoded, 2 bytes
+                      per 8 bit pixel, as a printable text string.  The
+                      two bytes are defined as follows (v = pixel value):
+
+                           byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                           byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                      Whitespace in a hex encoded string is ignored.
+                      Hex encoding reduces the data volume by about a factor
+                      of two (compared to numeric) and is only a factor of
+                      two less space efficient than binary.
+
+        nbits         Number of bits per pixel - currently only 8 bit pixels
+                      are supported.
+
+        x1,y1,nx,ny   Region of the raster to be read.
+

+

+Use readPixels to read a block of pixels, and getPixel to get the value
+of a single pixel.
+

+
getPixel

+

+Get the value of a single pixel.
+

+Usage:
+

+
+        getPixel raster x y
+
+        raster      The raster number.
+        x, y        The pixel to be set.
+

+

+This routine is more efficient than readPixels for getting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be read.
+

+
nextMapping

+

+Return the index of the next unused mapping.
+

+Usage:
+

+
+        nextMapping
+

+

+Returns the mapping number as the function value.
+

+
getMapping

+

+Get a mapping.
+

+Usage:
+

+
+        getMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters except the mapping number are output parameters.
+

+
setMapping

+

+Set a mapping.
+

+Usage:
+

+
+        setMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters are input parameters.
+

+
loadColormap

+

+Load a colormap.
+

+Usage:
+

+
+        loadColormap colormap [offset [scale]]
+

+

+The offset and scale parameters may be used to adjust the brightness and
+contrast of the image when the colormap is loaded.  The normalized colormap
+has offset=0.5, scale=1.0.  Colormap zero is the hardware colormap.
+

+
selectRaster

+

+Given the raw screen coordinates SX,SY (or coords in
+any destination raster), determine the mapping and source raster which are
+mapped to that pixel and return the raster and mapping numbers and the
+coordinates of the same pixel in the source raster.
+

+Usage:
+

+
+        raster = selectRaster dras dt dx dy rt rx ry [map]
+

+

+where
+

+
+		dras         display raster
+                dt,rt        coordinate type - "pixel" or "ndc"
+                dx,dy        display raster coordinates (input)
+                rx,ry        source raster coordinates (output)
+                map          mapping selected (output)
+

+

+Note that the coordinates returned by selectRaster are measured (taking
+a line as an example) from zero at the left edge of the first pixel, to 
+"width" at the right edge of the last pixel.  This means that the floating
+point coordinates of the center of raster pixel N will be N + 0.5.  For
+example, if we input screen coordinates (dras=0), x=117, and no mapping
+is in effect, the floating point raster coordinates returned will be 117.5.
+The difference occurs because the input coordinate is a pixel number 
+(integer) while the output coordinate is a floating point coordinate
+measuring the continuously variable location a pixel.  int(x) will convert
+this coordinate to a raster pixel number.
+

+
unmapPixel

+

+unmapPixel is a simplified, less general version of
+selectRaster which will automatically follow graphics pipelines back to
+the original mapped raster.  If desired the raster pixel value can be
+returned as well as the raster number and raster pixel coordinates
+corresponding to a screen (raster 0) pixel.
+

+Usage:
+

+
+        unmapPixel sx sy raster rx ry [rz]
+

+

+where
+

+
+		sx,sy        "screen" (raster 0) coordinates
+                raster       original mapped raster (output)
+                rx,ry        source raster coordinates (output)
+                rz           source raster pixel value (output)
+
+

+By following graphics pipelines back to the original source raster we mean
+the following.  If raster A is mapped to raster B which is mapped to C (the
+screen), given a screen coordinate in the mapped region unmapPixel will
+return the raster number and coordinates for raster A.
+

+
flip

+

+Edit a mapping to flip the mapped subimage in X and/or Y.
+

+Usage:
+

+
+        flip mapping axis [axis]
+

+

+where axis is "x" or "y".  This is a convenience routine for changing only
+the flip portion of a mapping.
+

+
markerInit

+

+Initialize the Marker subsystem for a Gterm widget.
+This destroys all markers and initializes the marker subsystem.
+

+Usage:
+

+
+        markerInit
+

+

+
createMarker

+

+Create a new marker.
+

+Usage:
+

+
+        createMarker name attribute-list
+  e.g.  createMarker name {attribute value [attribute value ...]}
+    or  createMarker name attribute value [attribute value ...]
+
+

+Any marker attribute may be assigned a value when the marker is created.
+Refer to <ObmW/Gterm.h> for a list of marker attribute names.  Often the
+the attributes "type" and "createMode" need to be specified at marker
+create time.
+

+
+        type            The marker type: text, rectangle, circle, etc.
+
+        createMode      A marker should be created with createMode=interactive
+                        if the user is expected to interactively drag out
+                        the marker using the pointer and either the default
+                        or an application specified translation table.  A
+                        marker can also be created interactively using only
+                        the m_create (marker create) action, however m_create
+                        does not allow the marker attributes to be set.
+
+

+There are any number of ways to use a GUI to create a marker under the
+Object Manager, but an example might be using a translation to call a GUI
+procedure which issues the createMarker call.  For example a pointer down
+event could translate as "call(newMarker,$name,$x,$y) m_create()" where
+newMarker is a GUI marker creation procedure which sends a createMarker
+message to the Gterm widget.  The GUI procedure could set the marker
+attributes as desired, possibly using additional GUI components to define
+the marker attributes.  The m_create action will notice that a
+createMarker has been executed and will merely activate the marker and
+give it the pointer focus (i.e. install the marker translations).  The
+user will then use the pointer or keyboard to drag out the marker.
+

+If the marker is created noninteractive the application must set the marker
+position and size using marker attributes.  If the marker is sensitive
+the user can then use the marker's translations to interactively modify
+the marker (resize it, move it, etc.).  All markers which are visible and
+sensitive and which have the necessary translations can be interactively
+modified by the user; the reason for creating a marker in interactive mode
+is to allow the initial marker position and size to be specified
+interactively *when* the marker is created, instead of afterwards.
+

+Any number of attributes may be given when the marker is created.  Most
+marker attributes can also be modified after a marker has been created
+by sending setAttribute messages to the marker.
+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/gui.html b/vendor/x11iraf/obm/docs/gui.doc/gui.html
new file mode 100644
index 00000000..d7e20546
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/gui.html
@@ -0,0 +1,93 @@
+
+
+
+IRAF Object Manager
+
IRAF Object Manager

+

+

+An Object Manager (OBM) user interface (UI) consists of one or more windows
+containing an arbitrary hierarchy of widgets.  These widgets and their
+runtime actions are defined by an interpreted text program uploaded
+by the client application, which does not itself deal directly with
+the window user interface.  Currently, this interpreted program is written
+in Tcl.
+

+The object manager provides a higher level of abstraction for dealing
+with widgets and other UI objects.  The main function of the object
+manager is to deliver messages to UI objects.  Each instance of a widget,
+the client programs, and the OBM itself are
+objects in the UI.  The UI contains other types of objects however,
+including the client object (client application), the server object
+(the object manager itself), and the application specific UI parameters,
+each of which is an object with a callback list of UI procedures to be
+called when the parameter value changes.  All of these UI objects can
+receive messages and take actions as a result.  Messages may come from the
+client application, or as a result of actions executed by the interpreted
+UI code in response to graphics events.
+

+
Object classes:

+

+
+Client           the client application
+Server           the object manager itself
+Widget           widgets
+ParameterUI      control parameter
+Gterm            graphics/imaging widget
+Graphics Markers  marker widgets
+Image Client     imageing widget
+

+Various Xt and Athena widgets
+	{box, shell, label, command, text, list, etc.}
+

+

+To locate specific IRAF GUI commands quickly, here is an
+
+        alphabetized list of IRAF GUI commands
+

+

+Sophisticated graphics applications will download a UI during initialization
+to define a custom graphics user interface.  This is done by sending a
+message to the object manager.  Naive applications assume a simple graphics
+terminal and do not download a UI; in this case, a default UI is created
+for the application when the UI is enabled with ObmEnable.  The default
+UI is a single top level shell window containing a single gterm (graphics
+terminal) widget.
+

+
+        reset-server
+        appInitialize  appname,appclass,resources
+        createObjects  [resource-name]
+        (UI specific code)
+        activate
+

+

+A UI specification consists of a sequence of commands to be executed by
+the server object.  This is downloaded by the client as a message for the
+server object.  The commands should include "reset-server" (this must be
+the first executable command), "appInitialize" (defines the UI objects and
+their resources), and "createObjects" (creates the objects and the widget
+tree), followed by any UI specific commands to define and register UI
+callback procedures.  Finally, "activate" is executed to activate the new
+user interface.
+

+Class descriptors for all UI object classes.  In the following, only the
+class initializer function needs to be set statically, since the class
+initializer function will initialize the remaining fields of the class
+descriptor at run time when the object manager is opened.
+

+
+    Server     Client     Parameter     Gterm      Core
+    Object     Widget     Command       Grip       Label
+    List       Scrollbar  StripChart    Toggle     SimpleMenu
+    Sme        SmeBSB     SmeLine       MenuButton AsciiText
+    Box        Dialog     Form          Paned      Viewport
+
+    Shell
+    OverrideShell
+    WMShell    
+    TransientShell
+    TopLevelShell
+    ApplicationShell
+

+
+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/guiintro.html b/vendor/x11iraf/obm/docs/gui.doc/guiintro.html
new file mode 100644
index 00000000..81511434
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/guiintro.html
@@ -0,0 +1,9 @@
+Introduction and Overview
+
  Introduction and Overview

+
+
Design Philosophy

+

+
Basic Tools

+

+
An Example

+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowse.gif b/vendor/x11iraf/obm/docs/gui.doc/imbrowse.gif
new file mode 100644
index 00000000..af1e7c0a
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/imbrowse.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/controlForm.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/controlForm.html
new file mode 100644
index 00000000..88e74c83
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/controlForm.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the controlForm

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirName.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirName.html
new file mode 100644
index 00000000..4c4b3cb3
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirName.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the dirName

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirSelect.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirSelect.html
new file mode 100644
index 00000000..fe8f8f40
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/dirSelect.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the dirSelect

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/headerText.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/headerText.html
new file mode 100644
index 00000000..a132c5f3
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/headerText.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the headerText

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/imageButton.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/imageButton.html
new file mode 100644
index 00000000..12595f3c
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/imageButton.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the imageButton

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/none.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/none.html
new file mode 100644
index 00000000..9cd7d5e3
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/none.html
@@ -0,0 +1,3 @@
+Example: Imbrowse none
+
  You selected none of the ellipses

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/objView.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/objView.html
new file mode 100644
index 00000000..a830a57a
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/objView.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the objView

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/panel.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/panel.html
new file mode 100644
index 00000000..b6b0ff2e
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/panel.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the panel

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/sectionBox.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/sectionBox.html
new file mode 100644
index 00000000..60895b18
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/sectionBox.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the sectionBox

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/statusBox.html b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/statusBox.html
new file mode 100644
index 00000000..061f5045
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/imbrowsemap/statusBox.html
@@ -0,0 +1,3 @@
+Example: Imbrowse panel
+
  You selected the statusBox

+
diff --git a/vendor/x11iraf/obm/docs/gui.doc/imtool.gif b/vendor/x11iraf/obm/docs/gui.doc/imtool.gif
new file mode 100644
index 00000000..a29811ef
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/imtool.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/intro.gif b/vendor/x11iraf/obm/docs/gui.doc/intro.gif
new file mode 100644
index 00000000..7f7af646
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/intro.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/irafgui.gif b/vendor/x11iraf/obm/docs/gui.doc/irafgui.gif
new file mode 100644
index 00000000..032c72d5
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/irafgui.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/llama.gif b/vendor/x11iraf/obm/docs/gui.doc/llama.gif
new file mode 100644
index 00000000..be0ceef4
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/llama.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/marker.gif b/vendor/x11iraf/obm/docs/gui.doc/marker.gif
new file mode 100644
index 00000000..639b19bd
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/marker.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/newgui.html b/vendor/x11iraf/obm/docs/gui.doc/newgui.html
new file mode 100644
index 00000000..36e7ec1a
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/newgui.html
@@ -0,0 +1,18 @@
+IRAF GUI Documentation
+
    IRAF Graphical User Interfaces

+
+

+This hypertext work is introductory documentation for the IRAF graphical
+user interface facility introduced with IRAF version 2.10.3. Questions
+can be directed, via electronic mail, to iraf.noao.edu or posted to the
+newsgroup adass.iraf.programmer.
+

+
+   An introduction and overview
+
+  The widgets and how they work
+
+    The language used to build GUIs
+
+  Software - GUI communication
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/notyet.html b/vendor/x11iraf/obm/docs/gui.doc/notyet.html
new file mode 100644
index 00000000..9a292a44
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/notyet.html
@@ -0,0 +1,5 @@
+NOTYET
+

+
+The info you requested is not yet available.
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/notyet2.html b/vendor/x11iraf/obm/docs/gui.doc/notyet2.html
new file mode 100644
index 00000000..2a6e3dca
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/notyet2.html
@@ -0,0 +1,5 @@
+NOTYET
+

+
+The info you requested is not yet available.
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/otherwidgets.html b/vendor/x11iraf/obm/docs/gui.doc/otherwidgets.html
new file mode 100644
index 00000000..f477fdc7
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/otherwidgets.html
@@ -0,0 +1,10 @@
+Other Widgets
+
    Other Widgets

+
+

+There are a few more widgets to be aware of, these are the parameter
+widgets, ....
+

+
+Parameter Widget
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/params.gif b/vendor/x11iraf/obm/docs/gui.doc/params.gif
new file mode 100644
index 00000000..053f424b
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/params.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/redline.gif b/vendor/x11iraf/obm/docs/gui.doc/redline.gif
new file mode 100644
index 00000000..574a6c8a
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/redline.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/serverclass.html b/vendor/x11iraf/obm/docs/gui.doc/serverclass.html
new file mode 100644
index 00000000..3fdaec2a
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/serverclass.html
@@ -0,0 +1,38 @@
+SERVER class
+
  SERVER class

+

+

+

+The server, or object manager, is the control center of the user interface.
+The server object provides a Tcl interpreter calling custom object manager
+commands. These are used to define and initialize the user interface, and
+execute UI action procedures at runtime.
+

+
+          reset-server
+         appInitialize  appname,appclass,resources
+         createObjects  [resource-name]
+         destroyObject  object
+              activate
+            deactivate  [unmap]
+

+   value = getResource  resource-name [default-value [class]]
+          getResources  resource-list
+

+            createMenu  menu-name parent item-list
+              editMenu  menu-name parent item-list
+           destroyMenu  menu-name
+

+          createBitmap  name width height data
+          createCursor  name source mask fg_color bg_color x_hot y_hot
+          createPixmap  name width height depth fg_color bg_color data
+

+                 print  arg [arg ...] # debug messages
+                  send  object message
+

+  postActivateCallback  procedure
+id = postTimedCallback  procedure msec [client-data]
+   deleteTimedCallback  id
+ id = postWorkCallback  procedure [client-data]
+    deleteWorkCallback  id
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/servercom.html b/vendor/x11iraf/obm/docs/gui.doc/servercom.html
new file mode 100644
index 00000000..16c4c24e
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/servercom.html
@@ -0,0 +1,375 @@
+
serverReset

+

+The "reset-server" command is implemented as a special case in ServerEvaluate.
+After doing a true reset ServerEvaluate calls Tcl_Eval to evaluate the full
+message which still contains the reset-server command. We want to ignore
+this the second time, so we treat the command here as a no-op.
+

+Usage:
+

+
+        reset-server
+

+

+Note: for reset-server to be recognized by ServerEvaluate and really reset
+things, it must be the first command in a message to the server.
+

+
createObjects

+

+TCL command to create the tree of UI objects comprising the user interface.
+The object tree is defined by a string valued resource. If no resource is
+named the default "objects" resource will be used.
+

+Usage:
+

+
+        createObjects [resource-name]
+

+
destroyObject

+

+Destroy an object and all of its children.
+

+Usage:	
+
+        destroyObject object-name
+

+

+
activate

+Activate the user interface. When called the first time the user interface
+is created and activated, thereafter the UI is merely reactivated (e.g.
+mapped if unmapped).
+

+Usage:	
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the user interface. Optionally unmaps the UI and calls the Obm
+client back to let it know that the UI has been deactivated.
+

+Usage:
+

+
+        deactivate [unmap]
+

+

+
getResource

+

+Get the string value of the specified application resource (window
+system parameter). This allows use of the resource mechanism to supply
+default values for GUI parameters.
+

+Usage:
+

+
+        value = getResource resource-name [class [default-value]]
+

+

+In the simplest case one merely requests a resource by name and the
+string value is returned as the function value. If the resource has
+an entry in the fallback resources for the application (appInitialize
+resource list) then a value is guaranteed to be returned.
+

+If the Class name for the resource is given then a class default value
+will be returned if no entry is found for the name resource instance. This
+is useful when there are a number of resources of the same type (same class).
+If most or all resources in the same class have the same default value one
+need only make one entry for the Class in the application defaults resource
+list. It is up to the application developer to define the class name of a
+resource - the class name can be any string. Examples are "Font", "Cursor",
+etc. By convention the first character of a class name is capitalized, while
+instance names begin with a lower case letter.
+

+If there is an entry for the named resource in the resource list passed to
+appInitialize then a value string is guaranteed to be returned. This will be
+either the appInitialize default, or a value specified by the system or the
+user in an X resources file. If one is not certain a default value is defined
+somewhere, a default value should be specified in the getResource call as
+shown above.
+

+See also getResources, used to get multiple resources in one call.
+

+
getResources

+

+Get the string values of a list of resources.
+

+Usage:
+

+
+        getResources resource-list
+

+

+e.g.
+
+        getResources {
+            { resource [variable class [default-value]]] }
+            { resource [variable class [default-value]]] }
+            (etc.)
+        }
+

+

+
createMenu, editMenu

+

+Create or modify a menu. The editMenu function is an alias for createMenu.
+

+Usage:
+
+        createMenu menu-name parent item-list
+

+

+e.g.,
+
+        createMenu menu-name parent {
+            { label function data [options...] }
+            { label function data [options...] }
+            (etc.)
+        }
+

+

+where
+

+
+        menu-name is the object name for the menu popup shell
+        parent    is the parent widget of the menu shell
+        label     is a menu item label
+        function  is the function to be performed when the menu
+        item      is selected, e.g., f.exec, f.data, f.space, or f.line.
+        data      is function dependent data
+        options   are option-name option-value pairs, as specified
+                  below.
+

+

+In the item list the fields label and option-value may be any Tcl expression.
+Expressions are evaluated in the server context. The data field is a Tcl
+script to be executed when the menu item is selected.
+

+Options are specified as "option option-value". The menu item options are
+as follows.
+

+
+        bitmap       A bitmap to be displayed left justified in the label field
+                     (e.g. to indicate a parameter setting).
+        sensitive    Specifies whether the menu item is active (sensitive=true)
+                     or inactive (sensitive=false, item grayed out).
+        accelerator  Specifies an input translation (accelerator, e.g.,
+                     keyboard event) which can be used to execute the
+                     menu item.
+

+

+The option-value field may be any Tcl expression.
+

+Example:
+

+
+        createMenu fileMenu toplevel {
+            { "File Menu" f.title}
+            { Open f.exec openFile}
+            { Save f.exec saveFile}
+            { Load f.menu loadMenu}
+            { no-label f.line }
+            { Quit f.exec "send client Quit" }
+        }
+

+

+The first createMenu is called for a given menu the menu is created, added
+to the menu list, and all window system widgets are created for the menu.
+Subsequent calls will result in only the changed parts of the menu being
+altered provided the changes are not great. Hence this routine can be called
+to efficiently modify a menu when minor runtime changes occur, e.g., an
+item label or action changes, the item value changes state, and so on,
+without need for the GUI code to know how to make the necessary detailed
+changes to the widgets used to implement the menu.
+

+
destroyMenu

+

+Destroy a menu. This can be used to free up the resources used by a
+menu, e.g., if the menu is not expected to be needed again for a while.
+

+Usage:
+

+
+        destroyMenu menu-name
+

+

+
createBitmap

+

+Create a named bitmap. This replaces any old bitmap of the same name. The
+new bitmap is cached in server memory; when a widget bitmap resource is set,
+the bitmap cache will be searched for the named bitmap before asking Xlib
+to find the bitmap.
+

+Usage:
+

+
+        createBitmap name width height data
+

+

+e.g., 
+

+
+        createBitmap foo 16 16 {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+
createCursor

+

+Create a cursor from bitmap data. The cursor is entered into the server's
+cursor cache and will override any existing entry of the same name.
+

+Usage:
+

+
+        createCursor name source mask fg_color bg_color x_hot y_hot
+

+

+e.g., 
+

+
+        createCursor foo bitmap1 bitmap2 black white 8 8
+

+

+The named bitmaps must be created first with createBitmap.
+

+
createPixmap

+

+Create a named pixmap. This replaces any old pixmap of the same name. The
+new pixmap is cached in server memory; when a widget pixmap resource is set,
+the pixmap cache will be searched for the named pixmap before asking Xlib
+to find the pixmap.
+

+Usage:
+

+
+        createPixmap name width height depth fg_color bg_color data
+

+

+e.g., 
+

+
+        createPixmap foo 16 16 8 black white {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+

+
print

+

+Print a string on the standard output. This is used mainly for debugging
+user interfaces.
+

+Usage:
+

+
+        print arg [arg ...]
+

+

+
send

+

+Send a message to an object. The object interprets the message and returns
+a function value as the string result of the TCL command.
+

+Usage
+

+
+        send <object> <message>
+

+

+
postActivateCallback

+

+Post a callback procedure to be called when the UI is activated. The UI is
+activated when it is first downloaded to server, but it may also be
+activated (reactivated) after the application has exited and is later
+restarted, or when the UI is deactivated and reactivated. Note 
+that the UI state vis-a-vis the external world (client application) may
+no longer be accurate after it has been idle for a time and then reactivated.
+

+Usage:
+

+
+        postActivateCallback <procedure>
+

+

+

+
postTimedCallback

+

+Post a callback to call the named procedure back after a specified delay
+in milliseconds.
+

+Usage:
+

+
+        id = postTimedCallback procedure msec [client-data]
+

+

+After the specified delay the user callback procedure will be called with
+client_data (if given) as the single argument. Only one call will be made;
+the client must repost the callback in each call if the procedure is to be
+repeatedly executed.
+

+An ID value is returned which may be passed to deleteTimedCallback to delete
+the timer.
+

+
deleteTimedCallback

+

+Delete a timer callback procedure. This procedure is typically used to
+break a timer loop, where the timer procedure repeatedly reposts itself at
+the end of each interval.
+

+Usage:
+

+
+        deleteTimedCallback id
+

+

+The ID string is returned by postTimedCallback when a timer is posted.
+

+
postWorkCallback

+

+Post a callback for a procedure to be called when the server is idle.
+Work procedures are used to perform computations in the background while
+the user interface remains active and able to respond to input events.
+This works only if the user work procedure does its job in small increments,
+doing only a small amount of processing in each call. The work procedure
+will be called repeatedly until it returns a status indicating that it has
+finished its task.
+

+Usage:
+

+
+        id = postWorkCallback procedure [client-data]
+

+

+When the server has nothing else to do the user work procedure will be
+called with client_data (if given) as the single argument. The work procedure
+should return the string "done" when all processing is finished, or any other
+string if the procedure is to be called again.
+

+An ID value is returned which may be passed to deleteWorkCallback to delete
+the work procedure.
+

+
deleteWorkCallback

+

+Delete a work callback procedure.
+

+Usage:
+

+
+        deleteWorkCallback id
+

+

+The ID string is returned by postWorkCallback when a work procedure is posted.
diff --git a/vendor/x11iraf/obm/docs/gui.doc/softgui.gif b/vendor/x11iraf/obm/docs/gui.doc/softgui.gif
new file mode 100644
index 00000000..7e287b10
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/softgui.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/tcl.gif b/vendor/x11iraf/obm/docs/gui.doc/tcl.gif
new file mode 100644
index 00000000..804a4afb
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/tcl.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/tcl.html b/vendor/x11iraf/obm/docs/gui.doc/tcl.html
new file mode 100644
index 00000000..259192f2
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/tcl.html
@@ -0,0 +1,7 @@
+Tcl page
+
Tcl page

+
+

+
John Ousterhout's Tcl book (over 700 Kbytes of PostScript)

+

+
Tcl Quick Reference

diff --git a/vendor/x11iraf/obm/docs/gui.doc/uiparameterclass.html b/vendor/x11iraf/obm/docs/gui.doc/uiparameterclass.html
new file mode 100644
index 00000000..fe189fc5
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/uiparameterclass.html
@@ -0,0 +1,107 @@
+UI PARAMETER class
+
  UI PARAMETER class

+

+

+

+The UI parameter class is used for client-UI communications.  The client
+does not control the user interface directly, rather the UI defines a set
+of abstract UI parameters, and during execution the client application
+assigns values to these parameters.  These UI parameters should be thought
+of as describing the runtime state of the client as viewed by the GUI.
+The GUI is free to interpret this state information in any way, including
+ignoring it.  Many GUIs can be written which use the same client state
+as described by the UI parameters.
+

+Assigning a value to a UI parameter causes the new value to be stored, and
+any parameter action procedures registered by the UI to be called.
+The action or actions [if any] taken when a parameter value changes are
+arbitrary, e.g. the action might be something as simple as changing a
+displayed value of a UI widget, or something more complex like displaying
+a popup.
+

+UI Parameter class commands:
+

+
+            getValue
+            setValue  <new-value>
+         addCallback  <procedure-name>
+      deleteCallback  <procedure-name>
+              notify
+

+

+The most common usage is for the GUI to post one or more callbacks for
+each UI parameter.  When the UI parameter value is changed [with setValue,
+e.g. by the client] the GUI callback procedures are called with the old
+and new UI parameter values on the command line.  addCallback is used to
+add a callback procedure, and deleteCallback to delete one.  Multiple
+callbacks may be registered for a single UI parameter.  notify is used
+to simulate a parameter value change, causing any callback procedures to
+be invoked.
+

+The callback procedure is called as follows:
+

+
+	user-procedure param-name {old-value} {new-value}
+

+

+The important thing to note here is that the old and new value strings
+are quoted with braces.  This prevents any interpretation of the string
+by Tcl when the callback is executed, which is necessary because the
+strings can contain arbitrary data.  When Tcl calls the callback the
+first level of braces will be stripped off, leaving old-value and new-value
+each as a single string argument.
+

+

+
setValue

+

+Set the value of a parameter, and notify all clients
+via the posted callback procedures that the parameter value has changed.
+

+Usage:
+

+
+        setValue <new-value>
+

+

+
getValue

+

+Get the value of a parameter.
+

+Usage:
+

+
+        getValue
+

+

+
notify

+

+Notify the registered clients of a parameter as if the
+value had changed.
+

+Usage:
+

+
+        notify
+

+

+
addCallback

+

+Add a callback procedure to the callback list for
+a parameter.
+

+Usage:
+

+
+        addCallback <procedure-name>
+

+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a parameter.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/widgetclass.html b/vendor/x11iraf/obm/docs/gui.doc/widgetclass.html
new file mode 100644
index 00000000..78d534db
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/widgetclass.html
@@ -0,0 +1,450 @@
+WIDGET class
+
  WIDGET class

+

+

+

+The Widget class is the generic or base class for the window system
+toolkit widgets supported by the object manager.  The Widget class
+supports a number of different Xt widget classes using a table driven
+approach to describe each widget.  Any widget may be created, destroyed,
+and manipulated in various ways using only the generic Widget class
+procedures and Widget-specific resources.  The Widget class may be
+subclassed to support complex Widgets that require custom class-specific
+commands for use by the GUI code.
+

+Generic Widget-class commands:
+

+
+                 set <resource-name> <value>
+                 get <resource-name>
+

+         addCallback <procedure-name> []
+      deleteCallback <procedure-name>
+        setSensitive <sensitive>
+         isSensitive
+

+             realize
+           unrealize
+         isRealizeed
+                 map
+               unmap
+              manage child [child ...]
+            unmanage child [child ...]
+               popup [grab-kind]
+             popdown
+   popupSpringLoaded
+

+                move <x> <y>
+              resize <width> <height> <border-width>
+           configure <x> <y> <width> <height> <border-width>
+

+

+The most important Widget commands are set/get resource, and the
+callbacks.  The widget sensitivity can be set and queried using set/get
+resource, but special procedures are provided to make this common operation
+more convenient.
+

+Class specific functions:
+

+
+                 append text                         # text widget
+                setList list [resize]                # list widget
+        value = getItem itemno
+              highlight itemno
+            unhighlight
+

+

+Ideally the widget class should be subclassed for widgets that require
+class-specific functions, but in simple cases involving standard widgets
+the support is built into the widget class code as a special case.
+

+Special actions (used in translations):
+

+
+                call (proc [,arg, ...])
+               popup (menu-name [xoffset [yoffset]])
+             popdown (menu-name)
+

+

+The "call" action is a very general mechanism which allows any GUI procedure
+to be registered with any translation using the X translation table
+mechanism.  The popup and popdown actions are used for popup menus.  The
+menu will be popped up at the event coordinates plus the optional offsets
+if given.
+

+Event handling:
+

+
+     addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+Event callback:
+

+
+    userEventHandler widget event-type time wx wy rx ry other
+

+

+In most cases translations are preferable to events, but a GUI can capture
+raw events if it wishes by adding event handlers.  Nearly all of the X
+event types are supported.  The callback syntax employs a number of
+standard arguments, followed by a number of event-specific arguments.
+

+
addCallback

+

+Add a callback procedure to the callback list for
+a widget.  If no callback name is given, "callback" is assumed.
+

+Usage:
+

+
+        addCallback  [<callback-name>]
+

+

+Specific widgets only support certain types of callbacks.  There is no
+checking that the callback type specified is supported by a widget; the
+wrong type of callback can be registered, but it will never be called.
+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a widget.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
do_userproc (call)

+

+Translation action procedure used to call general user
+action procedures in the interpreter.  The name of the user procedure to
+be called is given as the first argument in the translation.  For example,
+the translation "call(foo,a,b,c)" would cause procedure foo to be called
+with the arguments (a,b,c).  The following arguments are special:
+

+
+        Argument        Replaced by
+

+        $name             object name of widget
+        $time             event->time
+        $x                event->x
+        $y                event->y
+        $x_root           event->x_root
+        $y_root           event->y_root
+

+

+The "user procedure" can be any server procedure.
+

+
do_popup

+

+Popup a menu (or other spring loaded popup) at the location
+of the event which triggered this action.
+

+Usage:
+

+
+        popup(menu-name [xoffset [yoffset]])
+

+

+
do_popdown

+

+Pop down a menu.
+

+Usage:
+

+
+        popdown(menu-name)
+

+

+
set

+

+Set a widget resource.
+

+Usage:
+

+
+        set <resource-name> <value>
+

+

+
get

+

+Get a widget resource value as a string.
+

+Usage:
+

+
+        get <resource-name>
+

+

+
append

+

+Append data to a text widget.
+

+Usage:
+

+
+        append <text>
+

+

+
setList

+

+Set the item list of a list widget.
+

+Usage:
+

+
+        setList list [resize]
+

+

+The list is a simple list of strings, passed as a single string argument to
+setList (quotes, braces, etc. may be used to quote strings containing
+special characters).
+

+
getItem

+

+Get an item in a list widget.
+

+Usage:
+

+
+        value = getItem itemno
+

+

+If ITEMNO is a number the indicated list item is returned, or the string
+"EOF" if the requested item is beyond the end of the list.  Otherwise the
+currently selected item is returned, and the index of the item is returned
+in the output variable ITEMNO.  If no item is currently selected ITEMNO
+will be set to "none" on output.
+

+
highlight

+

+Highlight an item in a list widget.
+

+Usage:
+

+
+        highlight itemno
+

+

+The indicated item of the list is highlighted as if the item had been
+selected by the user.  Any previously highlighted item is unhighlighted.
+

+
unhighlight

+

+Unhighlight the currently highlighted item in a
+list widget.
+

+Usage:
+

+
+        unhighlight
+

+

+Any currently highlighted item in the list widget is unhighlighted.
+

+
realize

+

+Realize a widget.  This activates and assigns windows for
+a widget and all of its descendants.  Realizing a widget does not in itself
+cause it to appear on the screen.
+

+Usage:
+

+
+        realize
+

+

+
unrealize

+

+Unrealize a widget.  This destroys the windows assigned
+to a widget and all of its descendants.
+

+Usage:
+

+
+        unrealize
+

+

+
isRealized

+

+Test whether a widget is realized.
+

+Usage:
+

+
+        isRealized
+

+

+
map

+

+Map a widget.
+

+Usage:
+

+
+        map
+

+

+
unmap

+

+Unmap a widget.
+

+Usage:
+

+
+        unmap
+

+

+
manage

+

+Manage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Managing the
+children makes them appear in the window, possibly causing the other
+children to be rearranged in the window.
+

+Usage:
+

+
+        manage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
unmanage

+

+Unmanage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Unmanaging the
+children makes them disappear from the window and be removed from geometry
+management, possibly causing the other children to be rearranged in the
+window.
+

+Usage:
+

+
+        unmanage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
popup

+

+Popup a shell widget.  If no grab is indicated the popup
+can remain up while other windows accept input.
+

+Usage:
+

+
+        popup [grab-kind]
+

+

+
popdown

+

+Popdown a shell widget.
+

+Usage:
+

+
+        popdown
+

+

+
popupSpringLoaded

+

+Popup a shell widget, e.g., a popup menu.
+This implies an exclusive grab.
+

+Usage:
+

+
+        popupSpringLoaded
+

+

+
move

+

+Move a widget to the given window relative coordinates.
+

+Usage:
+

+
+        move <x> <y>
+

+

+
resize

+

+Resize a widget.
+

+Usage:
+

+
+        resize <width> <height> <border-width>
+

+

+
configure

+

+Configure a widget, i.e., execute a simultaneous
+move and resize.
+

+Usage:
+

+
+        configure <x> <y> <width> <height> <border-width>
+

+

+
setSensitive

+

+Set the sensitivity of a widget.
+

+Usage:
+

+
+        setSensitive <sensitive>
+

+

+
isSensitive

+

+Test the sensitivity of a widget.
+

+Usage:
+

+
+        isSensitive
+

+

+
addEventHandler

+

+Add a custom event handler to a widget.  A list
+of event masks is given to define the classes of events the user supplied
+event handling procedure is to receive.
+

+Usage:
+

+
+        addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+
removeEventHandler

+

+Remove an event handler previously posted
+with addEventHandler, above.
+

+Usage:
+

+
+        removeEventHandler procname
+

+

+
event

+

+Generic event handler called when a widget event handler
+posted by addEventHandler is called.
+

+The user event handler is called as
+

+
+        userEventHandler widget event-type time wx wy rx ry other
+

+

+where "other" is an event-type specific list of fields describing the
+the event.
diff --git a/vendor/x11iraf/obm/docs/gui.doc/widgets.gif b/vendor/x11iraf/obm/docs/gui.doc/widgets.gif
new file mode 100644
index 00000000..17f9371e
Binary files /dev/null and b/vendor/x11iraf/obm/docs/gui.doc/widgets.gif differ
diff --git a/vendor/x11iraf/obm/docs/gui.doc/widgets.html b/vendor/x11iraf/obm/docs/gui.doc/widgets.html
new file mode 100644
index 00000000..af80a997
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/widgets.html
@@ -0,0 +1,14 @@
+The Widgets
+
    Widgets

+
+

+The basic widgets available to the IRAF GUI implimenter are the Athena
+Widgets, the gterm widget, the image display widget, and markers.
+

+
+  Athena widgets     Gterm widget
+
+ Imtool widget        Marker widgets
+
+  Parameters
+

diff --git a/vendor/x11iraf/obm/docs/gui.doc/ximclient.html b/vendor/x11iraf/obm/docs/gui.doc/ximclient.html
new file mode 100644
index 00000000..12eac899
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/gui.doc/ximclient.html
@@ -0,0 +1,194 @@
+XIMCLIENT
+
  XIMCLIENT

+

+

+

+The Ximtool "client" object.  This code implements an OBM client and
+responds to messages sent to the client object by the GUI code executing
+under the object manager.
+

+Client commands:
+

+
+                   setFrame frameno
+         frameno = getFrame [raster]
+                  nextFrame
+                  prevFrame
+                matchFrames [frame]
+                   fitFrame
+
+                setColormap colormap
+             windowColormap offset scale
+                       zoom [mag | xmag ymag [ xcen ycen ]]
+                    zoomAbs [mag | xmag ymag [ xcen ycen ]]
+                        pan xcen ycen
+                       flip axis [axis ...]
+
+
+         wcsstr = encodewcs sx sy sz
+               retCursorVal sx sy [frame [wcs [key [strval]]]]
+
+                       Quit
+

+

+XIMTOOL CLIENT commands.
+

+
Quit

+

+Exit ximtool.
+

+Usage:
+

+
+        Quit
+

+

+
setFrame

+

+Set the frame to be displayed.
+

+Usage:
+

+
+        setFrame 
+

+

+
getFrame

+

+Get the frame number.
+

+Usage:
+

+
+        getFrame [raster]
+

+

+This routine has two forms.  When called with no argument getFrame returns
+the current display frame.  When called with a raster number getFrame
+returns the frame number with which the raster is associated.
+

+
nextFrame

+

+Display the next frame in sequence.
+

+Usage:
+

+
+        nextFrame
+

+

+
prevFrame

+

+Display the previous frame in sequence.
+

+Usage:
+

+
+        prevFrame
+

+

+
matchFrames

+

+Set the enhancement of all frames to match the current
+display frame.
+

+Usage:
+

+
+        matchFrames [frame]
+

+

+
fitFrame

+

+Attempt to make the display window the same size as the frame
+buffer.
+

+Usage:
+

+
+        fitFrame
+

+

+
setColormap

+

+Set the colormap for the current display frame.
+

+Usage:
+

+
+        setColormap 
+

+

+
windowColormap

+

+Set the colormap for the current display frame.
+

+Usage:
+

+
+        windowColormap  
+

+

+
zoom, zoomAbs

+

+Set the zoom factors for the current frame to the given values.
+A zoom factor > 1 enlarges the image, < 1 shrinks the image, 1.0 maps
+one source pixel to one destination pixel.
+

+Usage:
+

+
+        zoom            1 argument
+        zoom            2 arguments
+        zoom            4 arguments
+

+

+When called as "zoom" the magnification is relative to the fixed scaling,
+if any, used to scale the frame to fit the display window at mag=1.0.
+When called as zoomAbs" the magnification given is the actual scale factor
+used to map raster pixels to display pixels.
+

+
pan

+

+Pan the current frame, i.e., change the view center.
+

+Usage:
+

+
+        pan  
+

+

+
flip

+

+Flip the current display frame in the indicated axis or axes.
+

+Usage:
+

+
+        flip [axis [axis ...]]
+

+

+
retCursorVal

+

+Return a cursor value to the ximtool client process.  This
+should be executed by the GUI to terminate a cursor read.
+

+Usage:
+

+
+        retCursorVal sx sy [frame [wcs [key [strval]]]]
+

+

+
encodewcs

+

+Convert raw screen coordinates x,y,z (z=pixel value) to
+world coordinates using the WCS passed to ximtool by the client application
+when the frame was loaded.  The encoded description of the current position
+and pixel value is returned to the GUI as a string value.
+

+Usage:
+

+
+        string = encodewcs sx sy sz
+

+

diff --git a/vendor/x11iraf/obm/docs/obm/Client.html b/vendor/x11iraf/obm/docs/obm/Client.html
new file mode 100644
index 00000000..407c177b
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Client.html
@@ -0,0 +1,75 @@
+CLIENT class
+
  CLIENT class

+

+

+

+The client is the client application, which provides the functionality
+underlying the UI.  When a message is sent to the client object it usually
+results in a message being sent to the client *application*, usually an
+external program communicating via IPC, which has little or no knowledge
+of the UI.  The client application receives and executes commands delivered
+by the UI via the client object.  Output from the client may or may not
+come back to the object manager.  That portion of the output which comes
+back to the object manager is in the form of assignments of string values
+to UI parameter-class objects (another
+way of thinking of this is that
+messages or events are sent to and acted upon by the parameter objects).
+Hence, the client object is output only so far as the client application
+is concerned.
+

+The Client-class commands are used to send a message to the client.
+

+
+                gkey <key>
+                gcmd <command-string>
+             literal <command>
+

+

+or just <command>, e.g., "send client <command>" will work in most cases.
+

+GKEY sends an IRAF graphics keystroke.
+GCMD sends an
+IRAF graphics colon command.  LITERAL sends a literal
+command string to the
+client.  The keyword "literal" may optionally be omitted, i.e., "send client
+foo" and "send client literal foo" are the same.  The keyword "literal" may
+be used to ensure that the client command string which follows will not
+be interpreted as a Client-class command (such as gkey, gcmd, or literal).
+

+

+
gcmd

+

+Send a graphics command string to the client application.
+A graphics command string is a graphics cursor value with the key set
+to `:' and the command string given as the string part of the cursor
+value.  The protocol module which posted the client output procedure is
+responsible for encoding and sending the cursor command.
+

+Usage:
+

+
+        gcmd <command-string>
+

+

+
gkey

+

+Send a graphics key event to the client application.
+A graphics key event is a graphics cursor value with the key set to some
+integer value and a null string part.
+

+Usage:
+

+
+gkey <key>
+

+

+
literal

+

+Send a literal command to the client application.
+

+Usage:
+

+
+        literal <command>
+

+
diff --git a/vendor/x11iraf/obm/docs/obm/Gterm.html b/vendor/x11iraf/obm/docs/obm/Gterm.html
new file mode 100644
index 00000000..5fcdab10
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Gterm.html
@@ -0,0 +1,694 @@
+Gterm-Image widget class
+
  Gterm-Image widget class (a subclass of Widget).

+

+

+

+The gterm-image widget is a general 2D graphics-imaging widget providing
+a wide range of facilities for drawing graphics and text, for image
+display, and for graphics interaction.  Normally the client communicates
+directly with the Gterm widget to draw graphics, download image data,
+and so on, using some communications protocol outside the domain of the
+object manager.  Nonetheless so far as possible the facilities of the Gterm
+widget have also been made available to GUI code via the commands listed
+here.
+

+The Gterm widget adds the following function to the OBM library.
+

+
+    ObmPostSetGtermCallback (obm, &setgterm, setgterm_client_data)
+

+

+This is called by a client application to post a procedure to be called
+when a gterm widget receives the setGterm command.  The calling sequence
+for setGterm callback is as follows:
+

+
+                   setgterm (client_data, gterm_widget)
+

+

+The purpose of this callback is to tell the client which gterm widget is
+the "active" gterm widget.  This is used by clients which only support
+one active Gterm widget, i.e., which can only direct graphics output to
+one Gterm widget at a time.
+

+The messages or commands that can be sent to the Gterm widget by GUI
+code follow.
+

+General commands:
+

+
+                   setGterm          # make widget the active Gterm
+

+                   activate
+                 deactivate
+                addCallback procedure-name callback-type
+                      reset
+                      flush
+

+               setCursorPos x y [raster]
+               getCursorPos x y
+              setCursorType cursortype
+                       bell
+

+

+Graphics drawing commands:
+

+
+                  setRaster raster
+         raster = getRaster [raster]
+

+                  setLogRes width height (unimplimented)
+                  getLogRes width height (unimplimented)
+                 setPhysRes width height (unimplimented)
+                 getPhysRes width height (unimplimented)
+                 setTextRes rows cols (unimplimented)
+               setDataLevel level (unimplimented)
+               setLineWidth width (unimplimented)
+               setLineStyle style (unimplimented)
+              setColorIndex index (unimplimented)
+                setFillType filltype (unimplimented)
+

+                clearScreen
+               drawPolyline vector (unimplimented)
+             drawPolymarker vector (unimplimented)
+                drawPolygon vector (unimplimented)
+                 drawMarker x y xsize ysize type (unimplimented)
+

+              drawAlphaText x y text (unimplimented)
+           getAlphaTextSize string width height base (unimplimented)
+                startDialog (unimplimented)
+                  endDialog (unimplimented)
+                eraseDialog (unimplimented)
+             drawDialogText x y text (unimplimented)
+          getDialogTextSize string width height base (unimplimented)
+

+

+The coordinates used in the graphics drawing commands are logical
+coordinates as defined by setLogRes, in the coordinate system of the
+reference drawing raster as defined by setRaster.  The default reference
+raster is raster zero, the widget's window.  Vectors are specified as
+a list of points, e.g., { {x y} {x y} ... }.
+

+Imaging commands:
+

+
+              rasterInit
+            assignRaster raster drawable (unimplimented)
+            createRaster raster type width height depth (unimplimented)
+           destroyRaster raster (unimplimented)
+    exists = queryRaster raster type width height depth (unimplimented)
+     raster = nextRaster [raster] (unimplimented)
+     nrasters = nRasters [nrasters] (unimplimented)
+

+                setPixel raster x y value
+        value = getPixel raster x y
+             writePixels raster pixels encoding x1 y1 nx ny
+              readPixels raster pixels encoding x1 y1 nx ny
+           refreshPixels raster ct x1 y1 nx ny (unimplimented)
+   pixmap = createPixmap src x y width height (unimplimented)
+              copyPixmap pixmap dst x y width height (unimplimented)
+

+ colormap = nextColormap [colormap] (unimplimented)
+            freeColormap colormap (unimplimented)
+           writeColormap colormap first nelem colors (unimplimented)
+            readColormap colormap first nelem colors (unimplimented)
+            loadColormap colormap offset scale
+

+            initMappings (unimplimented)
+   mapping = nextMapping [mapping]
+             freeMapping mapping (unimplimented)
+           enableMapping mapping (unimplimented)
+          disableMapping mapping (unimplimented)
+  active = activeMapping mapping (unimplimented)
+          refreshMapping mapping (unimplimented)
+

+   raster = selectRaster dras dt dx dy rt rx ry [map]
+              unmapPixel sx sy raster rx ry [rz]
+

+              copyRaster rop src  st sx sy snx sny  dst dt dx dy dnx dny (unimplimented)
+              setMapping mapping rop
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+              getMapping mapping rop 
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+

+                    flip mapping axis [axis...]
+

+

+Pixel arrays are long strings consisting either of a sequence of numeric
+pixel values separated by whitespace (space or newline), or a hex encoded
+sequence of bytes (2 hex digits per 8 bit pixel).  Colors are specified
+as a list of RGB triplets, e.g., { {R G B} {R G B} ... }.
+

+Refer to the documentation for the Gterm widget for a detailed description
+of rasters, mappings, and colormaps.
+

+Markers:
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+New markers may be created with createMarker.  Once created, a marker
+functions under the Object Manager as a named object of class "marker".
+Refer to the marker class for a description of the commands defined for
+a marker.
+

+gterm Actions List
+

+
+        ignore
+        graphics-input
+        graphics-context
+        crosshair
+        track-cursor
+        enter-window
+        leave-window
+        popup-menu     {not implemented}
+        reset
+        m_create
+

+

+Default translations for Gterm window.
+Omitted for now: Ctrl ~Meta : popup-menu(tekMenu)
+

+default Gterm Translations
+

+
+               [Btn1Down]:m_create()                   
+               [Btn2Down]:crosshair(on)                
+             [Btn2Motion]:crosshair(on)                
+                 [Btn2Up]:crosshair(off)               
+   ~Ctrl ~Meta [Btn3Down]:graphics-context()           
+            [EnterWindow]:enter-window()               
+            [LeaveWindow]:leave-window()               
+               [KeyPress]:graphics-input()             
+                 [Motion]:track-cursor()               
+
+

+

+GTERM class commands.
+

+
setGterm

+

+Set the active Gterm widget.  A UI can have more than one
+gterm widget, but due to restrictions on the client-server interface, it
+may be possible for only one to receive client output at any one time (any
+gterm widget can generate input to be sent to the client).  If the client
+has this restriction, the client-server interface code which uses OBM can
+call the ObmPostSetGtermCallback procedure to post a function to be called
+when the UI code calls the setGterm procedure.
+

+Usage:
+

+
+        setGterm
+

+

+
activate

+

+Activate the gterm widget.   This causes the next GIN mode
+setCursorType to warp the pointer into the gterm window.
+

+Usage:
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the gterm widget.   If the cursor has been warped
+into the window by a previous activate/setCursorType GIN mode, this causes
+the cursor to be warped back to where it was previously.
+

+Usage:
+

+
+        deactivate
+

+

+
reset

+

+Reset the gterm widget.  This causes a number of state variables
+affecting graphics drawing options to be set to their default values.
+

+Usage:
+

+
+        reset
+

+

+
flush

+

+Flush any graphics output and synchronize the state of the widget
+with what is shown on the display.
+

+Usage:
+

+
+        flush
+

+

+The gterm widget uses XLIB, which buffers graphics drawing commands and
+automatically sends them to the X server when 1) the buffer fills,
+2) input is requested from the server.  Such buffering of data is necessary
+for efficient operation and it should rarely be necessary to explicitly
+flush graphics output since XLIB does this automatically in most cases.
+An example of when explicitly flushing the ouptut might be necessary is in
+cases where smooth animation is desired and drawing the graphics in batches
+could cause the display to appear "jerky".
+

+
addCallback

+

+Post a callback for a Gterm widget event.
+

+Usage:
+

+
+        addCallback procedure-name [callback-type]
+

+

+The recognized Gterm callbacks are
+

+
+
+        input           Called when the graphics-input action is invoked in
+                        a translation table.  The default Gterm translation
+                        table invokes this action when a KeyPress event occurs
+                        in the Gterm window.
+                        Callback:        widget-name input-type event-data
+
+        resize          Called when the gterm window is resized.
+                        Callback:        widget-name width height
+
+        reset           Called when the "reset" action is invoked.
+                        Callback:        widget-name
+
+
+

+If no callback is specified the default is "input".
+

+Note that in GUI code one can also use the translation table to directly
+invoke GUI procedures without need to use the Gterm input mechanism.  This
+is more flexible but we support the Gterm input callback here for
+applications that use the default translations.
+

+
setCursorPos

+

+Warp the cursor (pointer) to the given coordinates.  This
+is a graphics drawing command and if no raster number is specified the
+current reference drawing raster, as set with setRaster, defines the
+coordinate system.
+

+Usage:
+

+
+        setCursorPos x y [raster]
+

+

+A raster number may optionally given to define the raster coordinate system
+to be used.  raster=0 yields screen coordinates.
+

+
getCursorPos

+

+Get the cursor position (raster 0 or screen coordinates).
+

+Usage:
+

+
+        getCursorPos x y
+

+

+
setCursorType

+

+Set the cursor type.
+

+Usage:
+

+
+        setCursorType cursor-type
+
+        idle        default cursor
+        busy        busy cursor, e.g, when program is busy
+        ginMode     graphics input mode cursor, set when program is
+                    waiting for graphics input
+

+

+
bell

+

+Gterm widget sound output.
+

+Usage:
+

+
+        bell
+

+

+
setRaster

+

+Set the number of the raster to be used to define the drawing
+context (e.g. coordinate system) for graphics and text drawing functions.
+

+Usage:
+

+
+        setRaster raster-number
+

+

+
getRaster

+

+Get the number of the raster which defines the drawing
+context, as set in the last setRaster call.
+

+Usage:
+

+
+        raster = getRaster [raster]
+

+

+If the name of a variable is given the raster number will be stored 
+directly in that variable.
+

+
clearScreen

+

+Clear the "screen", i.e., window.  This action clears the
+drawing window and sets a number of drawing state variables to their default
+values.
+

+Usage:
+

+
+        clearScreen
+

+

+
rasterInit

+

+Initialize the raster subsystem, deleting all rasters and
+mappings and freeing the dynamic part of the colortable.
+

+Usage:
+

+
+        rasterInit
+

+

+
writePixels

+

+Set the values of some subset of the pixels in a raster.
+If any mappings are defined on the affected region and are enabled, any
+destination rasters will be automatically updated as defined by the mapping.
+

+Usage:
+

+
+        writePixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster       The raster number.
+        pixels       The pixel array, encoded as a string.
+        encoding     The pixel encoding.  "numeric" means each pixel is
+                     encoded as a decimal integer delimited by whitespace.
+                     "hex" means the pixel array is hex encoded, 2 bytes
+                     per 8 bit pixel, as a printable text string.  The
+                     two bytes are defined as follows (v = pixel value):
+
+                          byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                          byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                     Whitespace in a hex encoded string is ignored.
+                     Hex encoding reduces the data volume by about a factor
+                     of two (compared to numeric) and is only a factor of
+                     two less space efficient than binary.
+
+        nbits        Number of bits per pixel - currently only 8 bit pixels
+                     are supported.
+
+        x1,y1,nx,ny  Region of the raster to be written.
+

+

+Most real-world image processing applications get the Gterm widget handle
+with setGterm and pass binary data to the widget by calling GtWritePixels
+directly.  This is the most efficient approach for serious image processing
+where large amounts of data are involved.  However, being able to read and
+write raster pixels directly in a GUI can be useful in specialized
+applications, e.g., where the image is computed or modified by the GUI.
+

+
setPixel

+

+Set the value of a single pixel.
+

+Usage:
+

+
+        setPixel raster x y value
+
+        raster   The raster number.
+        x, y     The pixel to be set.
+        value    The pixel value.
+

+

+This routine is more efficient than writePixels for setting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be set.
+

+
readPixels

+

+Get the values of some subset of the pixels in a raster.
+

+Usage:
+

+
+        readPixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster        The raster number.
+        pixels        The pixel array, encoded as a string.
+        encoding      The pixel encoding.  "numeric" means each pixel is
+                      encoded as a decimal integer delimited by whitespace.
+                      "hex" means the pixel array is hex encoded, 2 bytes
+                      per 8 bit pixel, as a printable text string.  The
+                      two bytes are defined as follows (v = pixel value):
+
+                           byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                           byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                      Whitespace in a hex encoded string is ignored.
+                      Hex encoding reduces the data volume by about a factor
+                      of two (compared to numeric) and is only a factor of
+                      two less space efficient than binary.
+
+        nbits         Number of bits per pixel - currently only 8 bit pixels
+                      are supported.
+
+        x1,y1,nx,ny   Region of the raster to be read.
+

+

+Use readPixels to read a block of pixels, and getPixel to get the value
+of a single pixel.
+

+
getPixel

+

+Get the value of a single pixel.
+

+Usage:
+

+
+        getPixel raster x y
+
+        raster      The raster number.
+        x, y        The pixel to be set.
+

+

+This routine is more efficient than readPixels for getting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be read.
+

+
nextMapping

+

+Return the index of the next unused mapping.
+

+Usage:
+

+
+        nextMapping
+

+

+Returns the mapping number as the function value.
+

+
getMapping

+

+Get a mapping.
+

+Usage:
+

+
+        getMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters except the mapping number are output parameters.
+

+
setMapping

+

+Set a mapping.
+

+Usage:
+

+
+        setMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters are input parameters.
+

+
loadColormap

+

+Load a colormap.
+

+Usage:
+

+
+        loadColormap colormap [offset [scale]]
+

+

+The offset and scale parameters may be used to adjust the brightness and
+contrast of the image when the colormap is loaded.  The normalized colormap
+has offset=0.5, scale=1.0.  Colormap zero is the hardware colormap.
+

+
selectRaster

+

+Given the raw screen coordinates SX,SY (or coords in
+any destination raster), determine the mapping and source raster which are
+mapped to that pixel and return the raster and mapping numbers and the
+coordinates of the same pixel in the source raster.
+

+Usage:
+

+
+        raster = selectRaster dras dt dx dy rt rx ry [map]
+

+

+where
+

+
+		dras         display raster
+                dt,rt        coordinate type - "pixel" or "ndc"
+                dx,dy        display raster coordinates (input)
+                rx,ry        source raster coordinates (output)
+                map          mapping selected (output)
+

+

+Note that the coordinates returned by selectRaster are measured (taking
+a line as an example) from zero at the left edge of the first pixel, to 
+"width" at the right edge of the last pixel.  This means that the floating
+point coordinates of the center of raster pixel N will be N + 0.5.  For
+example, if we input screen coordinates (dras=0), x=117, and no mapping
+is in effect, the floating point raster coordinates returned will be 117.5.
+The difference occurs because the input coordinate is a pixel number 
+(integer) while the output coordinate is a floating point coordinate
+measuring the continuously variable location a pixel.  int(x) will convert
+this coordinate to a raster pixel number.
+

+
unmapPixel

+

+unmapPixel is a simplified, less general version of
+selectRaster which will automatically follow graphics pipelines back to
+the original mapped raster.  If desired the raster pixel value can be
+returned as well as the raster number and raster pixel coordinates
+corresponding to a screen (raster 0) pixel.
+

+Usage:
+

+
+        unmapPixel sx sy raster rx ry [rz]
+

+

+where
+

+
+		sx,sy        "screen" (raster 0) coordinates
+                raster       original mapped raster (output)
+                rx,ry        source raster coordinates (output)
+                rz           source raster pixel value (output)
+
+

+By following graphics pipelines back to the original source raster we mean
+the following.  If raster A is mapped to raster B which is mapped to C (the
+screen), given a screen coordinate in the mapped region unmapPixel will
+return the raster number and coordinates for raster A.
+

+
flip

+

+Edit a mapping to flip the mapped subimage in X and/or Y.
+

+Usage:
+

+
+        flip mapping axis [axis]
+

+

+where axis is "x" or "y".  This is a convenience routine for changing only
+the flip portion of a mapping.
+

+
markerInit

+

+Initialize the Marker subsystem for a Gterm widget.
+This destroys all markers and initializes the marker subsystem.
+

+Usage:
+

+
+        markerInit
+

+

+
createMarker

+

+Create a new marker.
+

+Usage:
+

+
+        createMarker name attribute-list
+  e.g.  createMarker name {attribute value [attribute value ...]}
+    or  createMarker name attribute value [attribute value ...]
+
+

+Any marker attribute may be assigned a value when the marker is created.
+Refer to <ObmW/Gterm.h> for a list of marker attribute names.  Often the
+the attributes "type" and "createMode" need to be specified at marker
+create time.
+

+
+        type            The marker type: text, rectangle, circle, etc.
+
+        createMode      A marker should be created with createMode=interactive
+                        if the user is expected to interactively drag out
+                        the marker using the pointer and either the default
+                        or an application specified translation table.  A
+                        marker can also be created interactively using only
+                        the m_create (marker create) action, however m_create
+                        does not allow the marker attributes to be set.
+
+

+There are any number of ways to use a GUI to create a marker under the
+Object Manager, but an example might be using a translation to call a GUI
+procedure which issues the createMarker call.  For example a pointer down
+event could translate as "call(newMarker,$name,$x,$y) m_create()" where
+newMarker is a GUI marker creation procedure which sends a createMarker
+message to the Gterm widget.  The GUI procedure could set the marker
+attributes as desired, possibly using additional GUI components to define
+the marker attributes.  The m_create action will notice that a
+createMarker has been executed and will merely activate the marker and
+give it the pointer focus (i.e. install the marker translations).  The
+user will then use the pointer or keyboard to drag out the marker.
+

+If the marker is created noninteractive the application must set the marker
+position and size using marker attributes.  If the marker is sensitive
+the user can then use the marker's translations to interactively modify
+the marker (resize it, move it, etc.).  All markers which are visible and
+sensitive and which have the necessary translations can be interactively
+modified by the user; the reason for creating a marker in interactive mode
+is to allow the initial marker position and size to be specified
+interactively *when* the marker is created, instead of afterwards.
+

+Any number of attributes may be given when the marker is created.  Most
+marker attributes can also be modified after a marker has been created
+by sending setAttribute messages to the marker.
+
diff --git a/vendor/x11iraf/obm/docs/obm/Marker.html b/vendor/x11iraf/obm/docs/obm/Marker.html
new file mode 100644
index 00000000..9e124846
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Marker.html
@@ -0,0 +1,402 @@
+Graphics Marker class
+
  Graphics Marker class

+

+

+

+A marker is a graphics object implemented by the Gterm-Image widget.
+Markers are not real toolkit widgets, but they act much like widgets and
+are interfaced as an object class under the Object Manager.  The Marker
+class is not a subclass, it is a base class like Widget, but Marker objects
+can exist only as children of Gterm widgets.
+

+Since markers are not independent widgets but rather part of a Gterm widget
+instance, the parent Gterm widget is partially responsible for managing
+markers.  The Gterm widget implements the following commands for dealing
+with markers.
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+A new marker is created by sending the createMarker message to the parent
+gterm widget.  This creates a marker of the given name and type.
+The markerInit command, if sent to a gterm widget, destroys any markers
+defined for that widget and reinitializes the marker facility.  Markers
+may also be created by action procedures in response to user input events.
+

+A marker may be destroyed by itself in response to an input event (e.g. the
+user presses the delete key), by sending the marker the destroy message
+to tell it to destroy itself, by sending a markerInit to the parent gterm
+widget, or by destroying the marker object (or any parent) with the server
+command destroyObject.
+

+Once a marker has been created it behaves as an independent object and
+receives and executes messages, responds to events, generates callbacks,
+and so on.  The marker class defines the following commands.
+

+
+                makeCopy name
+             addCallback procedure [event [event ...]]
+                  notify [event-type [param [param ...]]]
+                 destroy [nocallback]
+

+                 markpos
+                  redraw [function] [markpos|nomarkpos] [erase|noerase]
+

+                   raise [reference-marker]
+                   lower [reference-marker]
+

+                    move x y
+                  resize width height
+                  rotate angle                # radians
+

+                     set attribute value      # alias for setAttribute
+             value = get attribute            # alias for getAttribute
+

+            setAttribute attribute value
+    value = getAttribute attribute
+           setAttributes attribute-list
+           getAttributes attribute-list
+             setVertices points first npts
+             getVertices points first npts
+

+      region = getRegion [unmap] [coord-type]
+                 getRect dx dy dnx dny
+

+

+Marker positions and dimensions are given in window (raster 0) coordinates. 
+

+The operators raise, lower, move, resize, and rotate erase the marker,
+modify it as indicated, and redraw it with the new attributes.  For finer
+control over marker attributes one can use [get|set]Attribute[s] and
+[get|set]Vertices to edit the markers directly.  In this case an auto
+redraw is not performed (unless the autoRedraw marker attribute is set).
+The usual sequence is a markpos to record the marker position, one or more
+setAttribute calls to change marker attributes, then a redraw to erase
+the old marker and redraw the new one.  Markers have many attributes which
+can be set to control things like the position and size, colors, line
+widths, fill type and style, font, rubber-band technique, and so on.
+Refer to <ObmW/Gterm.h> for a list of marker types and attributes.
+

+The marker type may be changed at runtime without destroying the marker.
+For example a circle can be changed to an ellipse or a rectangle.  This
+also works for polygons (the vertex list is preserved and restored when
+the marker is changed back to a polygon).
+

+The current shape of a marker may be queried with getVertices, which
+returns the polygon or polyline vertex list in window coordinates.  A more
+powerful routine which does something similar is getRegion.  This routine
+returns a high level description of the region outlined by the marker,
+giving the marker type (rectangle, circle, ellipse etc.), center, width
+and height, and so on.  Any position or dimension information may
+optionally be transformed back to the original source raster, if the marker
+center is in a region of the window which is the destination of an active
+mapping.  The unmap option will follow multiple mappings back to the
+original mapped source raster.
+

+The getRect function returns the parameters of the region outlined by a
+rectangle marker in a form convenient for use in a Gterm setMapping call
+(this is used to display an image within a marker).
+

+Default translations when pointer is over a marker.
+default Marker Translations
+

+
+        Shift < Btn1Motion >i    m_rotateResize()             
+              < Btn1Motion >    m_moveResize()               
+          Shift < Btn1Down >    m_raise()  m_markpos()       
+                < Btn1Down >    m_raise()  m_markposAdd()    
+                  < Btn1Up >    m_redraw() m_destroyNull()   
+                < Btn2Down >    m_lower()                    
+            < Key > BackSpace   m_deleteDestroy()            
+               < Key > Delete   m_deleteDestroy()            
+                < KeyPress >    m_input()                    
+                  < Motion >    track-cursor()               
+

+

+MARKER class commands.
+

+makeCopy
+

+Copy a marker.  The new marker is initially identical to the
+old one, and will not be distinct until, e.g., moved to a new center.
+

+Usage:
+

+
+         makeCopy name
+

+

+
addCallback

+

+Post a marker callback to be called when the specified
+event or events occurs.  If no events are listed a Notify callback will
+be posted.
+

+Usage:
+

+
+	addCallback procedure [event [event ...]]
+

+

+
notify

+

+Generate a Marker pseudo-event, causing any posted client
+callback procedures to be called.
+

+Usage:
+

+
+        notify [event-type [param [param ...]]]
+

+

+
destroy

+

+Destroy a marker.  Just tell the marker to destroy itself.
+All cleanup outside the marker facility relies upon the use of callbacks.
+This includes our callback markerDestroyCallback below.
+

+Usage:
+

+
+        destroy
+

+

+
markpos

+

+Mark the current position of a marker for a later redraw.
+

+Usage:
+

+
+        markpos
+

+

+Markpos is used to mark the position of a marker before changing any
+marker attributes, so that a later "redraw marked" will erase the old
+marker rather than the new one.  This is necessary, for example, if any
+marker attributes are changed which affect the size or position of the
+marker.
+

+
redraw

+

+Redraw a marker.
+

+Usage:
+

+
+        redraw [function] [erase|noerase] [markpos|nomarkpos]
+

+

+By default redraw will erase the old marker at the position indicated by
+a previous call to markpos, and redraw the marker with the current
+attributes using the drawing function copy (copy source to destination).
+Hence the usual usage is "markpos ... change marker attributes ... redraw".
+Optional arguments may be given to change the drawing function, enable or
+disable erase, or force redraw to do a markpos.  These arguments may be
+given in any order.
+

+The drawing functions are as given in the XLIB documentation, minus the
+"GX" prefix.  The most commonly used functions are "copy" and "xor".
+A normal marker redraw uses function=copy.
+

+
raise

+

+Raise a marker, i.e., cause it to be drawn on top of other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        raise [reference-marker]
+

+

+In a reference marker is named the marker will raise itself above this
+marker, otherwise the raised marker becomes the topmost marker.
+

+
lower

+

+Lower a marker, i.e., cause it to be drawn beneath other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        lower [reference-marker]
+

+

+In a reference marker is named the marker will lower itself beneath this
+marker, otherwise the lowered marker becomes the lowest marker.
+

+
move

+

+Move a marker.
+

+Usage:
+

+
+        move x y
+

+

+Move the marker center to the indicated coordinates in the display window.
+

+
resize

+

+Resize a marker.
+

+Usage:
+

+
+         resize width height
+

+

+Resize the marker to the indicated size.  By default width and height are
+given in pixels.  For a text marker one can append "ch" to indicate that
+the units are chars in whatever font is in use, e.g., "40ch" or "40 chars"
+is an acceptable value for a text marker dimension.
+

+
rotate

+

+Rotate a marker.
+

+Usage:
+

+
+         rotate angle
+

+

+Redraw a marker oriented to the given rotation angle.  The angle is
+given in radians.
+

+
getAttribute

+

+Return the value of a marker attribute.
+

+Usage:
+

+
+        value = getAttribute attribute-name
+

+

+
setAttribute

+

+Set the value of a marker attribute.
+

+Usage:
+

+
+        setAttribute attribute-name value
+

+

+
getAttributes

+

+Return the values of a list of marker attributes.
+

+Usage:
+

+
+          getAttributes attribute-list
+  i.e.    getAttributes {name value [name value ...]}
+    or    getAttributes name value [name value ...]
+

+

+where "value" is the name of the variable in which the attribute value 
+is to be stored.
+

+
setAttributes

+

+Set the values of a list of marker attributes.
+

+Usage:
+

+
+        setAttributes attribute-list
+  i.e.  setAttributes {name value [name value ...]}
+

+

+where "value" is the new value of the associated marker attribute.
+

+
getVertices

+

+Get some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        getVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is returned in the
+variable "points", as a string of the form { {x y} {x y} ...}.  The first
+point is number zero.
+

+
setVertices

+

+Set some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        setVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is set using the points
+passed in the "points" variable as a string of the form { {x y} {x y} ...}.
+If FIRST and NPTS are not specified first is assumed to be zero (the first
+point) and NPTS is the length of the points array.
+

+
getRegion

+

+Return as a text string a high level description of the
+region defined by a marker.
+

+Usage:
+

+
+        region = getRegion [unmap] [coord-type]
+

+

+The output string defines the marker type and the major marker positional
+attributes.  The region description formats for the various marker types
+follow.
+

+
+        text raster x y width height
+        line raster x y x y
+        polyline raster npts { {x y} {x y} ...}
+        rectangle raster x y width height rotangle
+        circle raster x y radius
+        ellipse raster x y width height rotangle
+        polygon raster npts { {x y} {x y} ...}
+

+

+Here, width and height refer to the distance from the marker center to an
+edge, not to the width or height of the whole marker.  This avoids
+ambiguities about where the edge of a marker is if the width is even or
+odd.  Using the center to edge measurement, the edge is at x +/- width,
+y +/- height.
+

+If the "unmap" flag is given getRegion will attempt to associate the
+marker with a mapped raster, reversing any mappings from the screen back
+to the original source raster, and returning the raster number and raster
+coordinates and marker sizes.  If "unmap" is not given the marker
+coordinates will refer to raster 0.  Either pixel ("pixel") or NDC
+("ndc") coordinates may be returned, pixel coordinates being the default.
+

+
getRect

+

+Return the region enclosed by a rectangle marker.  The rect is
+returned in a form convenient for use as the destination rect in a gterm
+widget raster mapping.
+

+Usage:
+

+
+        getRect dx dy dnx dny
+

+

+The rect is stored in the output arguments.
+

diff --git a/vendor/x11iraf/obm/docs/obm/Parameter.html b/vendor/x11iraf/obm/docs/obm/Parameter.html
new file mode 100644
index 00000000..fe189fc5
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Parameter.html
@@ -0,0 +1,107 @@
+UI PARAMETER class
+
  UI PARAMETER class

+

+

+

+The UI parameter class is used for client-UI communications.  The client
+does not control the user interface directly, rather the UI defines a set
+of abstract UI parameters, and during execution the client application
+assigns values to these parameters.  These UI parameters should be thought
+of as describing the runtime state of the client as viewed by the GUI.
+The GUI is free to interpret this state information in any way, including
+ignoring it.  Many GUIs can be written which use the same client state
+as described by the UI parameters.
+

+Assigning a value to a UI parameter causes the new value to be stored, and
+any parameter action procedures registered by the UI to be called.
+The action or actions [if any] taken when a parameter value changes are
+arbitrary, e.g. the action might be something as simple as changing a
+displayed value of a UI widget, or something more complex like displaying
+a popup.
+

+UI Parameter class commands:
+

+
+            getValue
+            setValue  <new-value>
+         addCallback  <procedure-name>
+      deleteCallback  <procedure-name>
+              notify
+

+

+The most common usage is for the GUI to post one or more callbacks for
+each UI parameter.  When the UI parameter value is changed [with setValue,
+e.g. by the client] the GUI callback procedures are called with the old
+and new UI parameter values on the command line.  addCallback is used to
+add a callback procedure, and deleteCallback to delete one.  Multiple
+callbacks may be registered for a single UI parameter.  notify is used
+to simulate a parameter value change, causing any callback procedures to
+be invoked.
+

+The callback procedure is called as follows:
+

+
+	user-procedure param-name {old-value} {new-value}
+

+

+The important thing to note here is that the old and new value strings
+are quoted with braces.  This prevents any interpretation of the string
+by Tcl when the callback is executed, which is necessary because the
+strings can contain arbitrary data.  When Tcl calls the callback the
+first level of braces will be stripped off, leaving old-value and new-value
+each as a single string argument.
+

+

+
setValue

+

+Set the value of a parameter, and notify all clients
+via the posted callback procedures that the parameter value has changed.
+

+Usage:
+

+
+        setValue <new-value>
+

+

+
getValue

+

+Get the value of a parameter.
+

+Usage:
+

+
+        getValue
+

+

+
notify

+

+Notify the registered clients of a parameter as if the
+value had changed.
+

+Usage:
+

+
+        notify
+

+

+
addCallback

+

+Add a callback procedure to the callback list for
+a parameter.
+

+Usage:
+

+
+        addCallback <procedure-name>
+

+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a parameter.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

diff --git a/vendor/x11iraf/obm/docs/obm/Server.html b/vendor/x11iraf/obm/docs/obm/Server.html
new file mode 100644
index 00000000..3fdaec2a
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Server.html
@@ -0,0 +1,38 @@
+SERVER class
+
  SERVER class

+

+

+

+The server, or object manager, is the control center of the user interface.
+The server object provides a Tcl interpreter calling custom object manager
+commands. These are used to define and initialize the user interface, and
+execute UI action procedures at runtime.
+

+
+          reset-server
+         appInitialize  appname,appclass,resources
+         createObjects  [resource-name]
+         destroyObject  object
+              activate
+            deactivate  [unmap]
+

+   value = getResource  resource-name [default-value [class]]
+          getResources  resource-list
+

+            createMenu  menu-name parent item-list
+              editMenu  menu-name parent item-list
+           destroyMenu  menu-name
+

+          createBitmap  name width height data
+          createCursor  name source mask fg_color bg_color x_hot y_hot
+          createPixmap  name width height depth fg_color bg_color data
+

+                 print  arg [arg ...] # debug messages
+                  send  object message
+

+  postActivateCallback  procedure
+id = postTimedCallback  procedure msec [client-data]
+   deleteTimedCallback  id
+ id = postWorkCallback  procedure [client-data]
+    deleteWorkCallback  id
+

diff --git a/vendor/x11iraf/obm/docs/obm/Widget.html b/vendor/x11iraf/obm/docs/obm/Widget.html
new file mode 100644
index 00000000..78d534db
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/Widget.html
@@ -0,0 +1,450 @@
+WIDGET class
+
  WIDGET class

+

+

+

+The Widget class is the generic or base class for the window system
+toolkit widgets supported by the object manager.  The Widget class
+supports a number of different Xt widget classes using a table driven
+approach to describe each widget.  Any widget may be created, destroyed,
+and manipulated in various ways using only the generic Widget class
+procedures and Widget-specific resources.  The Widget class may be
+subclassed to support complex Widgets that require custom class-specific
+commands for use by the GUI code.
+

+Generic Widget-class commands:
+

+
+                 set <resource-name> <value>
+                 get <resource-name>
+

+         addCallback <procedure-name> []
+      deleteCallback <procedure-name>
+        setSensitive <sensitive>
+         isSensitive
+

+             realize
+           unrealize
+         isRealizeed
+                 map
+               unmap
+              manage child [child ...]
+            unmanage child [child ...]
+               popup [grab-kind]
+             popdown
+   popupSpringLoaded
+

+                move <x> <y>
+              resize <width> <height> <border-width>
+           configure <x> <y> <width> <height> <border-width>
+

+

+The most important Widget commands are set/get resource, and the
+callbacks.  The widget sensitivity can be set and queried using set/get
+resource, but special procedures are provided to make this common operation
+more convenient.
+

+Class specific functions:
+

+
+                 append text                         # text widget
+                setList list [resize]                # list widget
+        value = getItem itemno
+              highlight itemno
+            unhighlight
+

+

+Ideally the widget class should be subclassed for widgets that require
+class-specific functions, but in simple cases involving standard widgets
+the support is built into the widget class code as a special case.
+

+Special actions (used in translations):
+

+
+                call (proc [,arg, ...])
+               popup (menu-name [xoffset [yoffset]])
+             popdown (menu-name)
+

+

+The "call" action is a very general mechanism which allows any GUI procedure
+to be registered with any translation using the X translation table
+mechanism.  The popup and popdown actions are used for popup menus.  The
+menu will be popped up at the event coordinates plus the optional offsets
+if given.
+

+Event handling:
+

+
+     addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+Event callback:
+

+
+    userEventHandler widget event-type time wx wy rx ry other
+

+

+In most cases translations are preferable to events, but a GUI can capture
+raw events if it wishes by adding event handlers.  Nearly all of the X
+event types are supported.  The callback syntax employs a number of
+standard arguments, followed by a number of event-specific arguments.
+

+
addCallback

+

+Add a callback procedure to the callback list for
+a widget.  If no callback name is given, "callback" is assumed.
+

+Usage:
+

+
+        addCallback  [<callback-name>]
+

+

+Specific widgets only support certain types of callbacks.  There is no
+checking that the callback type specified is supported by a widget; the
+wrong type of callback can be registered, but it will never be called.
+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a widget.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
do_userproc (call)

+

+Translation action procedure used to call general user
+action procedures in the interpreter.  The name of the user procedure to
+be called is given as the first argument in the translation.  For example,
+the translation "call(foo,a,b,c)" would cause procedure foo to be called
+with the arguments (a,b,c).  The following arguments are special:
+

+
+        Argument        Replaced by
+

+        $name             object name of widget
+        $time             event->time
+        $x                event->x
+        $y                event->y
+        $x_root           event->x_root
+        $y_root           event->y_root
+

+

+The "user procedure" can be any server procedure.
+

+
do_popup

+

+Popup a menu (or other spring loaded popup) at the location
+of the event which triggered this action.
+

+Usage:
+

+
+        popup(menu-name [xoffset [yoffset]])
+

+

+
do_popdown

+

+Pop down a menu.
+

+Usage:
+

+
+        popdown(menu-name)
+

+

+
set

+

+Set a widget resource.
+

+Usage:
+

+
+        set <resource-name> <value>
+

+

+
get

+

+Get a widget resource value as a string.
+

+Usage:
+

+
+        get <resource-name>
+

+

+
append

+

+Append data to a text widget.
+

+Usage:
+

+
+        append <text>
+

+

+
setList

+

+Set the item list of a list widget.
+

+Usage:
+

+
+        setList list [resize]
+

+

+The list is a simple list of strings, passed as a single string argument to
+setList (quotes, braces, etc. may be used to quote strings containing
+special characters).
+

+
getItem

+

+Get an item in a list widget.
+

+Usage:
+

+
+        value = getItem itemno
+

+

+If ITEMNO is a number the indicated list item is returned, or the string
+"EOF" if the requested item is beyond the end of the list.  Otherwise the
+currently selected item is returned, and the index of the item is returned
+in the output variable ITEMNO.  If no item is currently selected ITEMNO
+will be set to "none" on output.
+

+
highlight

+

+Highlight an item in a list widget.
+

+Usage:
+

+
+        highlight itemno
+

+

+The indicated item of the list is highlighted as if the item had been
+selected by the user.  Any previously highlighted item is unhighlighted.
+

+
unhighlight

+

+Unhighlight the currently highlighted item in a
+list widget.
+

+Usage:
+

+
+        unhighlight
+

+

+Any currently highlighted item in the list widget is unhighlighted.
+

+
realize

+

+Realize a widget.  This activates and assigns windows for
+a widget and all of its descendants.  Realizing a widget does not in itself
+cause it to appear on the screen.
+

+Usage:
+

+
+        realize
+

+

+
unrealize

+

+Unrealize a widget.  This destroys the windows assigned
+to a widget and all of its descendants.
+

+Usage:
+

+
+        unrealize
+

+

+
isRealized

+

+Test whether a widget is realized.
+

+Usage:
+

+
+        isRealized
+

+

+
map

+

+Map a widget.
+

+Usage:
+

+
+        map
+

+

+
unmap

+

+Unmap a widget.
+

+Usage:
+

+
+        unmap
+

+

+
manage

+

+Manage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Managing the
+children makes them appear in the window, possibly causing the other
+children to be rearranged in the window.
+

+Usage:
+

+
+        manage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
unmanage

+

+Unmanage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Unmanaging the
+children makes them disappear from the window and be removed from geometry
+management, possibly causing the other children to be rearranged in the
+window.
+

+Usage:
+

+
+        unmanage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
popup

+

+Popup a shell widget.  If no grab is indicated the popup
+can remain up while other windows accept input.
+

+Usage:
+

+
+        popup [grab-kind]
+

+

+
popdown

+

+Popdown a shell widget.
+

+Usage:
+

+
+        popdown
+

+

+
popupSpringLoaded

+

+Popup a shell widget, e.g., a popup menu.
+This implies an exclusive grab.
+

+Usage:
+

+
+        popupSpringLoaded
+

+

+
move

+

+Move a widget to the given window relative coordinates.
+

+Usage:
+

+
+        move <x> <y>
+

+

+
resize

+

+Resize a widget.
+

+Usage:
+

+
+        resize <width> <height> <border-width>
+

+

+
configure

+

+Configure a widget, i.e., execute a simultaneous
+move and resize.
+

+Usage:
+

+
+        configure <x> <y> <width> <height> <border-width>
+

+

+
setSensitive

+

+Set the sensitivity of a widget.
+

+Usage:
+

+
+        setSensitive <sensitive>
+

+

+
isSensitive

+

+Test the sensitivity of a widget.
+

+Usage:
+

+
+        isSensitive
+

+

+
addEventHandler

+

+Add a custom event handler to a widget.  A list
+of event masks is given to define the classes of events the user supplied
+event handling procedure is to receive.
+

+Usage:
+

+
+        addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+
removeEventHandler

+

+Remove an event handler previously posted
+with addEventHandler, above.
+

+Usage:
+

+
+        removeEventHandler procname
+

+

+
event

+

+Generic event handler called when a widget event handler
+posted by addEventHandler is called.
+

+The user event handler is called as
+

+
+        userEventHandler widget event-type time wx wy rx ry other
+

+

+where "other" is an event-type specific list of fields describing the
+the event.
diff --git a/vendor/x11iraf/obm/docs/obm/alphabetic.html b/vendor/x11iraf/obm/docs/obm/alphabetic.html
new file mode 100644
index 00000000..0c141617
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/alphabetic.html
@@ -0,0 +1,39 @@
+Alphabetized list of GUI commands
+
+
+activate	activate	activeMapping	addCallback	addCallback
+addCallback	addCallback	addEventHandler	append		appInitialize
+assignRaster	bell		call		clearScreen	configure	
+copyPixmap	copyRaster	createBitmap	createCursor	createMarker	
+createMenu	createObjects	createPixmap	createPixmap	createRaster	
+deactivate	deactivate	deleteCallback	deleteCallback	deleteTimedCallback	
+deleteWorkCallback		destroy		destroyMenu	destroyObject	
+destroyRaster	disableMapping	drawAlphaText	drawDialogText	drawMarker	
+drawPolygon	drawPolyline	drawPolymarker	editMenu	enableMapping	
+encodewcs	endDialog	eraseDialog	fitFrame	flip	
+flip		flush		freeColormap	freeMapping	gcmd	
+get		get		getAlphaTextSize		getAttribute
+getAttributes	getCursorPos	getDialogTextSize		getFrame	
+getItem		getLogRes	getMapping	getPhysRes	getPixel	
+getRaster	getRect		getRegion	getResource	getResources	
+getValue	getVertices	gkey		highlight	initMappings	
+isRealized	isSensitive	literal		loadColormap	lower	
+makeCopy	manage		map		markerInit	markpos	
+matchFrames	move		move		nextColormap	nextFrame	
+nextMapping	nextRaster	notify		notify		nRasters	
+pan		popdown		popdown		popup		popup	
+popupSpringLoaded		postActivateCallback		postTimedCallback	
+postWorkCallback		prevFrame	print		queryRaster	
+Quit		raise		rasterInit	readColormap	readPixels	
+realize		redraw		refreshMapping	refreshPixels	reset-server	
+reset		resize		resize		retCursorVal	rotate	
+selectRaster	send		set		set		setAttribute	
+setAttributes	setColorIndex	setColormap	setCursorPos	setCursorType	
+setDataLevel	setFillType	setFrame	setGterm	setLineStyle	
+setLineWidth	setList		setLogRes	setMapping	setPhysRes	
+setPixel	setRaster	setSensitive	setTextRes	setValue	
+setVertices	startDialog	unhighlight	unmanage	unmap	
+unmapPixel	unrealize	userEventHandler		windowColormap	
+writeColormap	writePixels	zoom		zoomAbs	
+

+
diff --git a/vendor/x11iraf/obm/docs/obm/index.html b/vendor/x11iraf/obm/docs/obm/index.html
new file mode 100644
index 00000000..b7e531ca
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/index.html
@@ -0,0 +1,2515 @@
+
+
+IRAF Object Manager Tutorial
+
+

+
IRAF Object Manager Tutorial

+

+

+
+
Contents

+
+
+

+
+
+
1.  Introduction

+

+An Object Manager (OBM) user interface (UI) consists of one or more windows
+containing an arbitrary hierarchy of widgets.  These widgets and their
+runtime actions are defined by an interpreted text program uploaded
+by the client application, which does not itself deal directly with the
+window user interface.  This interpreted program is currently written
+as a Tcl script.
+

+The OBM provides a high level abstraction for dealing with widgets and
+other UI objects.  The main function of the object manager is to deliver
+messages to UI objects.  Each instance of a widget is an object in the
+interface.  The UI contains other types of objects as well, including the
+client object (client application), the server object (the object manager
+itself), and the application specific UI parameters, each of which is an
+object with a callback list of procedures to be called when the parameter
+value changes.  All of these UI objects can receive messages and take actions
+as a result.  Messages may come from the client application, or as a result
+of actions executed by the interpreted UI code in response to graphics events.
+

+

+
+
2.  System Architecture

+

+For a complete description of the OBM system architecture see Tody, D,
+ADASS Proceedings 1994.  A postscript version of this
+paper is also vailable.
+

+

+

+
+
3.  The Client Process

+

+	The primary advantage of the OBM architecture over traditional GUI
+design is the separation of the user interface from the executable client
+code, meaning that either can be completely rewritten or developed separately
+without affecting the other so long as the messaging between the two
+remains the same.  The client itself is responsible for initializing the OBM
+toolkit and uploading the UI definition file, after that it usually enters
+an event loop of some kind (e.g. an iraf graphics cursor loop, or X event
+handler) to process actions defined in the client callbacks.
+

+	It's important that the client program maintain the state of the
+application rather than the UI file.  For example, a text widget in the
+interface may instruct the client to load a file, however if this cannot
+be done the interface should not have independently reset labels or
+whatever assuming the action was done at all.  Instead, the client program
+uses the Parameter Class objects in the interface to update the state of
+the GUI as a result of some action (whose origins may not have been in the
+GUI at all).  So for example a sequence of events could be something like
+
+
      
+
    •  User selects a widget in the interface, it's callback sends a
+	message to the client directing some action be taken
+
    •  Client receives the message and performs an action in the client
+
    •  If action fails, (optionally) notify GUI of failure (e.g. send a
+	message to an 'alert' parameter to popup a dialog box, beep the
+	terminal, etc)
+
    •  If action succeeds, notify GUI of new state (e.g. send a message
+	to the 'filename' Parameter object containing the new file name).
+
    •  Callback on the 'filename' parameter then updates the status bar
+	widget with the name of the new active file.
+

+
+

+	The messaging between the client and UI depend on the details of how
+the client is implemented.  In general any callback procedure in the UI can
+send a message to any other object in the interface, but the client should
+generally communicate only via the Parameter objects to avoid side effects
+and maintain a clear separation between the UI and the client code.
+
+
+
3.1  IRAF Graphics Task

+
+
+
3.1.1  XGterm

+
+
+
3.2  Standalone Task

+
+
+
3.3  OBM Shell

+

+	The obmsh is a unix shell interpreter for GUI scripts.  It is
+a minimal standalone client with a single callback to exit the application,
+otherwise it's only job is to activate the GUI file.  Any messages sent to
+the client (except a 'quit') are simply absorbed by the client
+

+	Despite the apparent lack of functionality this is sometimes all
+that is required for an interface that can operate independently.  Remember
+that the Tcl scripting language has it's own facilities for file I/O, 
+process execution, etc, all of which are still available in the GUI.  In
+the case of IRAF tasks it's an interface violation to use these facilities
+directly, however they still allow for the easy creation of a GUI which 
+requires no real underlying client (e.g. a tcl debug shell, a calculator
+application, task launcher, etc).
+
+
+
3.4  Named External Clients

+
+

+

+

+

+
+
4.  UI Definition File

+

+A UI definition consists of a sequence of commands to be executed by the
+server object using Tcl is used as an embedded interpreter within the OBM.
+The Tcl script contains several required OBM-specific functions (in
+addition to the user-defined callbacks) which is uploaded by the client
+as a message for the server object.  
+
+    reset-server
+    appInitialize  appName appClass Resources
+    createObjects  [name]
+    activate
+

+

+All UI files must begin with a reset-server command to initialize
+the OBM.  An appInitialize call is then made to define all of the
+widgets and resources used in the interface, initializing the interface
+used by the application.  The createObjects function then actually
+creates the widgets in the server, more specifically it creates the widgets
+defined by the named objects resource.  Lastly, the activate
+call is used to activate the interface, i.e. put it on the screen.
+
+

+
+
4.1  Example

+A complete "hello, world" GUI definition might look something like:
+
+     1)    reset-server
+     2)    appInitialize hello Hello {
+     3)        *objects:\
+     4)            toplevel     Form       helloForm\
+     5)            helloForm    Label      helloLabel\
+     6)            helloForm    Command    quitButton
+     7)
+     8)        *background:               	gray
+     9)        *helloLabel.label:         	Hello, world!
+    10)        *quitButton.fromHoriz:     	helloLabel
+    11)        *quitButton.label:         	Quit
+    12)    }
+    13)
+    14)    createObjects
+    15)    activate
+    16)
+    17)    proc Quit args { 
+    18)	     send client gkey q
+    19)      deactivate unmap
+    20)    } ; send quitButton addCallback Quit
+

+
+where a line-by-line analysis of the GUI shows:
+
+

+
Line 1: 
- The reset-server command must be the first line in
+the UI file since it's primary purpose is to initialize the OBM (i.e. a
+call to the ObmInitialize() procedure).  Subsequent calls (in the
+same UI file or a different UI) are effectively a no-op.
+
Lines 2-12: 
- The appInitialize command defines the widgets
+and resources to be used in the interface.  The first argument gives the
+name of the application, the second argument is the application class name
+for purposes of specifying resources in the environment, and the last 
+argument is a Tcl list (hence the braces) of resources for the application.
+

+The primary purpose of the call is to initialize the X11 part of the system
+by defining the application context and the list of fallback resources.  The
+objects resource is a required element listing the widget hierarchy
+to be used.  Remaining resources are used to specify labels, colors, layout,
+etc and serve as an app-defaults file for the GUI, interacting with the
+normal resource database in the usual way.  For example, a user's .Xdefaults
+file may specify a "font" resource, unless this is overridden in 
+some way in the UI file this is the font that will be used.  Resources may
+be specified with either "loose" (i.e. the '*') or "tight" (i.e. the '.')
+bindings with as much detail as is needed.
+
Line 14: 
- The createObjects command is what actually calls
+each widget's Initialize() method to create the widget in the application
+and in the X11 server.  
+

+With no argument, the default value used is simply
+the objects resource.  However, it's possible to specify a named
+argument and make repeated calls to createObjects to build any number
+widget trees prior to activating the interface.  This can be useful for
+example to specify a "main_objects" resource contains all the widgets for
+the main panel, and a "help_objects" specfiying widgets used for the UI
+help panel, which makes the definition file easier to organize.  In the
+past however UI files were written with a single long list (easily many 
+hundreds of lines) of objects followed by an even longer list of their
+resources under a single appInitialize call, creating a monolithic
+and unmanageably GUI definition file.  Later on we'll see how complex GUIs
+can be divided into separate pieces making it easier to reuse code and
+manage the interface more efficiently.
+
Line 15: 
- The activate command is what creates the interface
+on the screen, i.e. it calls the Realize() method for each widget to
+instantiate it in the server and draw the window.
+
Lines 17-19: 
- Lastly we have the user-defined callback procedures.
+On line 17 we define a procedure Quit which we use to shut down the
+interface and client application.  The body of the procedure first sends the
+client object the graphics keystroke 'q' to shut down the client, then calls
+the deactivate command to close the interface.  On the last line 
+we send a message to the quitButton widget telling it to add this
+procedure to it's callback list, so when the Button is selected this
+procedure will be called as a result.
+

+

+

+
+
+
5.  Widget Toolkit

+

+

+

+
+
+
5.  Object Classes

+

+The following OBM object classes are currently defined:
+
+    Client		The Client application
+    Server		The OBM itself
+    Gterm		Gterm graphics/imaging widget class
+    HTML		HTML widget class
+    Markers		Gterm markers class
+    Widget		General widget class
+    Parameter		UI Parameter class
+

+    Various Xt and Athena widgets
+    		{box, shell, label, command, text, list, etc.}
+    Misc Other X11 Widgets
+    		{Layout, Tabs, ListTree, etc}
+

+

+OBM client applications will upload a UI during initialization to define a
+custom graphics user interface.  This is done by sending a message to the
+object manager.  Non-GUI applications assume a simple graphics
+terminal and do not upload a UI; instead, a default UI is created
+for the application consisting of a single top level shell containing a
+Gterm (Tek 4012 graphics/imaging) widget.
+

+
+

+
+
+
5.1 Client

+

+The client is the client application, which provides the functionality
+underlying the UI.  When a message is sent to the client object it usually
+results in a message being sent to the client *application*, usually an
+external program communicating via IPC, which has little or no knowledge
+of the UI.  The client application receives and executes commands delivered
+by the UI via the client object.  Output from the client may or may not
+come back to the object manager.  That portion of the output which comes
+back to the object manager is in the form of assignments of string values
+to UI Parameter class objects (another way of thinking
+of this is that messages or events are sent to and acted upon by the parameter
+objects).  Hence, the client object is output only so far as the client
+application is concerned.
+

+The Client-class commands are used to send a message to the client.
+

+
+                gkey <key>
+                gcmd <command-string>
+             literal <command>
+

+

+or just <command>, e.g., "send client <command>" will work in most cases.
+

+GKEY sends an IRAF graphics keystroke.
+GCMD sends an
+IRAF graphics colon command.  LITERAL sends a literal
+command string to the
+client.  The keyword "literal" may optionally be omitted, i.e., "send client
+foo" and "send client literal foo" are the same.  The keyword "literal" may
+be used to ensure that the client command string which follows will not
+be interpreted as a Client-class command (such as gkey, gcmd, or literal).
+

+
+
5.1.1 Command Summary

+

+
gcmd

+

+Send a graphics command string to the client application.
+A graphics command string is a graphics cursor value with the key set
+to `:' and the command string given as the string part of the cursor
+value.  The protocol module which posted the client output procedure is
+responsible for encoding and sending the cursor command.
+

+Usage:
+

+
+        gcmd <command-string>
+

+

+
gkey

+

+Send a graphics key event to the client application.
+A graphics key event is a graphics cursor value with the key set to some
+integer value and a null string part.
+

+Usage:
+

+
+gkey <key>
+

+

+
literal

+

+Send a literal command to the client application.
+

+Usage:
+

+
+        literal <command>
+

+
+

+
+
+
6.2 Server

+

+The server, or object manager, is the control center of the user interface.
+The server object provides a Tcl interpreter calling custom object manager
+commands. These are used to define and initialize the user interface, and
+execute UI action procedures at runtime.
+

+
+          reset-server
+         appInitialize  appname,appclass,resources
+         createObjects  [resource-name]
+         destroyObject  object
+              activate
+            deactivate  [unmap]
+

+   value = getResource  resource-name [default-value [class]]
+          getResources  resource-list
+

+            createMenu  menu-name parent item-list
+              editMenu  menu-name parent item-list
+           destroyMenu  menu-name
+

+          createBitmap  name width height data
+          createCursor  name source mask fg_color bg_color x_hot y_hot
+          createPixmap  name width height depth fg_color bg_color data
+

+                 print  arg [arg ...] # debug messages
+                  send  object message
+

+  postActivateCallback  procedure
+id = postTimedCallback  procedure msec [client-data]
+   deleteTimedCallback  id
+ id = postWorkCallback  procedure [client-data]
+    deleteWorkCallback  id
+

+
+
+
6.2.1 Command Summary

+

+
serverReset

+

+The "reset-server" command is implemented as a special case in ServerEvaluate.
+After doing a true reset ServerEvaluate calls Tcl_Eval to evaluate the full
+message which still contains the reset-server command. We want to ignore
+this the second time, so we treat the command here as a no-op.
+

+Usage:
+

+
+        reset-server
+

+

+Note: for reset-server to be recognized by ServerEvaluate and really reset
+things, it must be the first command in a message to the server.
+

+
createObjects

+

+TCL command to create the tree of UI objects comprising the user interface.
+The object tree is defined by a string valued resource. If no resource is
+named the default "objects" resource will be used.
+

+Usage:
+

+
+        createObjects [resource-name]
+

+
destroyObject

+

+Destroy an object and all of its children.
+

+Usage:	
+
+        destroyObject object-name
+

+

+
activate

+Activate the user interface. When called the first time the user interface
+is created and activated, thereafter the UI is merely reactivated (e.g.
+mapped if unmapped).
+

+Usage:	
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the user interface. Optionally unmaps the UI and calls the Obm
+client back to let it know that the UI has been deactivated.
+

+Usage:
+

+
+        deactivate [unmap]
+

+

+
getResource

+

+Get the string value of the specified application resource (window
+system parameter). This allows use of the resource mechanism to supply
+default values for GUI parameters.
+

+Usage:
+

+
+        value = getResource resource-name [class [default-value]]
+

+

+In the simplest case one merely requests a resource by name and the
+string value is returned as the function value. If the resource has
+an entry in the fallback resources for the application (appInitialize
+resource list) then a value is guaranteed to be returned.
+

+If the Class name for the resource is given then a class default value
+will be returned if no entry is found for the name resource instance. This
+is useful when there are a number of resources of the same type (same class).
+If most or all resources in the same class have the same default value one
+need only make one entry for the Class in the application defaults resource
+list. It is up to the application developer to define the class name of a
+resource - the class name can be any string. Examples are "Font", "Cursor",
+etc. By convention the first character of a class name is capitalized, while
+instance names begin with a lower case letter.
+

+If there is an entry for the named resource in the resource list passed to
+appInitialize then a value string is guaranteed to be returned. This will be
+either the appInitialize default, or a value specified by the system or the
+user in an X resources file. If one is not certain a default value is defined
+somewhere, a default value should be specified in the getResource call as
+shown above.
+

+See also getResources, used to get multiple resources in one call.
+

+
getResources

+

+Get the string values of a list of resources.
+

+Usage:
+

+
+        getResources resource-list
+

+

+e.g.
+
+        getResources {
+            { resource [variable class [default-value]]] }
+            { resource [variable class [default-value]]] }
+            (etc.)
+        }
+

+

+
createMenu, editMenu

+

+Create or modify a menu. The editMenu function is an alias for createMenu.
+

+Usage:
+
+        createMenu menu-name parent item-list
+

+

+e.g.,
+
+        createMenu menu-name parent {
+            { label function data [options...] }
+            { label function data [options...] }
+            (etc.)
+        }
+

+

+where
+

+
+        menu-name is the object name for the menu popup shell
+        parent    is the parent widget of the menu shell
+        label     is a menu item label
+        function  is the function to be performed when the menu
+        item      is selected, e.g., f.exec, f.data, f.space, or f.line.
+        data      is function dependent data
+        options   are option-name option-value pairs, as specified
+                  below.
+

+

+In the item list the fields label and option-value may be any Tcl expression.
+Expressions are evaluated in the server context. The data field is a Tcl
+script to be executed when the menu item is selected.
+

+Options are specified as "option option-value". The menu item options are
+as follows.
+

+
+        bitmap       A bitmap to be displayed left justified in the label field
+                     (e.g. to indicate a parameter setting).
+        sensitive    Specifies whether the menu item is active (sensitive=true)
+                     or inactive (sensitive=false, item grayed out).
+        accelerator  Specifies an input translation (accelerator, e.g.,
+                     keyboard event) which can be used to execute the
+                     menu item.
+

+

+The option-value field may be any Tcl expression.
+

+Example:
+

+
+        createMenu fileMenu toplevel {
+            { "File Menu" f.title}
+            { Open f.exec openFile}
+            { Save f.exec saveFile}
+            { Load f.menu loadMenu}
+            { no-label f.line }
+            { Quit f.exec "send client Quit" }
+        }
+

+

+The first createMenu is called for a given menu the menu is created, added
+to the menu list, and all window system widgets are created for the menu.
+Subsequent calls will result in only the changed parts of the menu being
+altered provided the changes are not great. Hence this routine can be called
+to efficiently modify a menu when minor runtime changes occur, e.g., an
+item label or action changes, the item value changes state, and so on,
+without need for the GUI code to know how to make the necessary detailed
+changes to the widgets used to implement the menu.
+

+
destroyMenu

+

+Destroy a menu. This can be used to free up the resources used by a
+menu, e.g., if the menu is not expected to be needed again for a while.
+

+Usage:
+

+
+        destroyMenu menu-name
+

+

+
createBitmap

+

+Create a named bitmap. This replaces any old bitmap of the same name. The
+new bitmap is cached in server memory; when a widget bitmap resource is set,
+the bitmap cache will be searched for the named bitmap before asking Xlib
+to find the bitmap.
+

+Usage:
+

+
+        createBitmap name width height data
+

+

+e.g., 
+

+
+        createBitmap foo 16 16 {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+
createCursor

+

+Create a cursor from bitmap data. The cursor is entered into the server's
+cursor cache and will override any existing entry of the same name.
+

+Usage:
+

+
+        createCursor name source mask fg_color bg_color x_hot y_hot
+

+

+e.g., 
+

+
+        createCursor foo bitmap1 bitmap2 black white 8 8
+

+

+The named bitmaps must be created first with createBitmap.
+

+
createPixmap

+

+Create a named pixmap. This replaces any old pixmap of the same name. The
+new pixmap is cached in server memory; when a widget pixmap resource is set,
+the pixmap cache will be searched for the named pixmap before asking Xlib
+to find the pixmap.
+

+Usage:
+

+
+        createPixmap name width height depth fg_color bg_color data
+

+

+e.g., 
+

+
+        createPixmap foo 16 16 8 black white {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+

+
print

+

+Print a string on the standard output. This is used mainly for debugging
+user interfaces.
+

+Usage:
+

+
+        print arg [arg ...]
+

+

+
send

+

+Send a message to an object. The object interprets the message and returns
+a function value as the string result of the TCL command.
+

+Usage
+

+
+        send <object> <message>
+

+

+
postActivateCallback

+

+Post a callback procedure to be called when the UI is activated. The UI is
+activated when it is first downloaded to server, but it may also be
+activated (reactivated) after the application has exited and is later
+restarted, or when the UI is deactivated and reactivated. Note 
+that the UI state vis-a-vis the external world (client application) may
+no longer be accurate after it has been idle for a time and then reactivated.
+

+Usage:
+

+
+        postActivateCallback <procedure>
+

+

+

+
postTimedCallback

+

+Post a callback to call the named procedure back after a specified delay
+in milliseconds.
+

+Usage:
+

+
+        id = postTimedCallback procedure msec [client-data]
+

+

+After the specified delay the user callback procedure will be called with
+client_data (if given) as the single argument. Only one call will be made;
+the client must repost the callback in each call if the procedure is to be
+repeatedly executed.
+

+An ID value is returned which may be passed to deleteTimedCallback to delete
+the timer.
+

+
deleteTimedCallback

+

+Delete a timer callback procedure. This procedure is typically used to
+break a timer loop, where the timer procedure repeatedly reposts itself at
+the end of each interval.
+

+Usage:
+

+
+        deleteTimedCallback id
+

+

+The ID string is returned by postTimedCallback when a timer is posted.
+

+
postWorkCallback

+

+Post a callback for a procedure to be called when the server is idle.
+Work procedures are used to perform computations in the background while
+the user interface remains active and able to respond to input events.
+This works only if the user work procedure does its job in small increments,
+doing only a small amount of processing in each call. The work procedure
+will be called repeatedly until it returns a status indicating that it has
+finished its task.
+

+Usage:
+

+
+        id = postWorkCallback procedure [client-data]
+

+

+When the server has nothing else to do the user work procedure will be
+called with client_data (if given) as the single argument. The work procedure
+should return the string "done" when all processing is finished, or any other
+string if the procedure is to be called again.
+

+An ID value is returned which may be passed to deleteWorkCallback to delete
+the work procedure.
+

+
deleteWorkCallback

+

+Delete a work callback procedure.
+

+Usage:
+

+
+        deleteWorkCallback id
+

+

+The ID string is returned by postWorkCallback when a work procedure is posted.
+
+

+
+
+
6.3 Gterm

+

+The gterm-image widget is a general 2D graphics-imaging widget providing
+a wide range of facilities for drawing graphics and text, for image
+display, and for graphics interaction.  Normally the client communicates
+directly with the Gterm widget to draw graphics, download image data,
+and so on, using some communications protocol outside the domain of the
+object manager.  Nonetheless so far as possible the facilities of the Gterm
+widget have also been made available to GUI code via the commands listed
+here.
+

+The Gterm widget adds the following function to the OBM library.
+

+
+    ObmPostSetGtermCallback (obm, &setgterm, setgterm_client_data)
+

+

+This is called by a client application to post a procedure to be called
+when a gterm widget receives the setGterm command.  The calling sequence
+for setGterm callback is as follows:
+

+
+                   setgterm (client_data, gterm_widget)
+

+

+The purpose of this callback is to tell the client which gterm widget is
+the "active" gterm widget.  This is used by clients which only support
+one active Gterm widget, i.e., which can only direct graphics output to
+one Gterm widget at a time.
+

+The messages or commands that can be sent to the Gterm widget by GUI
+code follow.
+

+General commands:
+

+
+                   setGterm          # make widget the active Gterm
+

+                   activate
+                 deactivate
+                addCallback procedure-name callback-type
+                      reset
+                      flush
+

+               setCursorPos x y [raster]
+               getCursorPos x y
+              setCursorType cursortype
+                       bell
+

+

+Graphics drawing commands:
+

+
+                  setRaster raster
+         raster = getRaster [raster]
+

+                  setLogRes width height
+                  getLogRes width height
+                 setPhysRes width height
+                 getPhysRes width height
+                 setTextRes rows cols
+               setDataLevel level
+               setLineWidth width
+               setLineStyle style
+              setColorIndex index
+                setFillType filltype
+

+                clearScreen
+               drawPolyline vector
+             drawPolymarker vector
+                drawPolygon vector
+                 drawMarker x y xsize ysize type
+

+              drawAlphaText x y text
+           getAlphaTextSize string width height base
+                startDialog
+                  endDialog
+                eraseDialog
+             drawDialogText x y text
+          getDialogTextSize string width height base
+

+

+The coordinates used in the graphics drawing commands are logical
+coordinates as defined by setLogRes, in the coordinate system of the
+reference drawing raster as defined by setRaster.  The default reference
+raster is raster zero, the widget's window.  Vectors are specified as
+a list of points, e.g., { {x y} {x y} ... }.
+

+Imaging commands:
+

+
+              rasterInit
+            assignRaster raster drawable
+            createRaster raster type width height depth
+           destroyRaster raster
+    exists = queryRaster raster type width height depth
+     raster = nextRaster [raster]
+     nrasters = nRasters [nrasters]
+

+                setPixel raster x y value
+        value = getPixel raster x y
+             writePixels raster pixels encoding x1 y1 nx ny
+              readPixels raster pixels encoding x1 y1 nx ny
+           refreshPixels raster ct x1 y1 nx ny
+   pixmap = createPixmap src x y width height
+              copyPixmap pixmap dst x y width height
+

+ colormap = nextColormap [colormap]
+            freeColormap colormap
+           writeColormap colormap first nelem colors
+            readColormap colormap first nelem colors
+            loadColormap colormap offset scale
+

+            initMappings
+   mapping = nextMapping [mapping]
+             freeMapping mapping
+           enableMapping mapping
+          disableMapping mapping
+  active = activeMapping mapping
+          refreshMapping mapping
+

+   raster = selectRaster dras dt dx dy rt rx ry [map]
+              unmapPixel sx sy raster rx ry [rz]
+

+              copyRaster rop src  st sx sy snx sny  dst dt dx dy dnx dny
+              setMapping mapping rop
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+              getMapping mapping rop 
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+

+                    flip mapping axis [axis...]
+

+

+Pixel arrays are long strings consisting either of a sequence of numeric
+pixel values separated by whitespace (space or newline), or a hex encoded
+sequence of bytes (2 hex digits per 8 bit pixel).  Colors are specified
+as a list of RGB triplets, e.g., { {R G B} {R G B} ... }.
+

+Refer to the documentation for the Gterm widget for a detailed description
+of rasters, mappings, and colormaps.
+

+Markers:
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+New markers may be created with createMarker.  Once created, a marker
+functions under the Object Manager as a named object of class "marker".
+Refer to the marker class for a description of the commands defined for
+a marker.
+

+gterm Actions List
+

+
+        ignore
+        graphics-input
+        graphics-context
+        crosshair
+        track-cursor
+        enter-window
+        leave-window
+        popup-menu     {not implemented}
+        reset
+        m_create
+

+

+Default translations for Gterm window.
+Omitted for now: Ctrl ~Meta : popup-menu(tekMenu)
+

+default Gterm Translations
+

+
+               [Btn1Down]:m_create()                   
+               [Btn2Down]:crosshair(on)                
+             [Btn2Motion]:crosshair(on)                
+                 [Btn2Up]:crosshair(off)               
+   ~Ctrl ~Meta [Btn3Down]:graphics-context()           
+            [EnterWindow]:enter-window()               
+            [LeaveWindow]:leave-window()               
+               [KeyPress]:graphics-input()             
+                 [Motion]:track-cursor()               
+

+

+

+
+
6.3.1 GTERM class commands

+

+
setGterm

+

+Set the active Gterm widget.  A UI can have more than one
+gterm widget, but due to restrictions on the client-server interface, it
+may be possible for only one to receive client output at any one time (any
+gterm widget can generate input to be sent to the client).  If the client
+has this restriction, the client-server interface code which uses OBM can
+call the ObmPostSetGtermCallback procedure to post a function to be called
+when the UI code calls the setGterm procedure.
+

+Usage:
+

+
+        setGterm
+

+

+
activate

+

+Activate the gterm widget.   This causes the next GIN mode
+setCursorType to warp the pointer into the gterm window.
+

+Usage:
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the gterm widget.   If the cursor has been warped
+into the window by a previous activate/setCursorType GIN mode, this causes
+the cursor to be warped back to where it was previously.
+

+Usage:
+

+
+        deactivate
+

+

+
reset

+

+Reset the gterm widget.  This causes a number of state variables
+affecting graphics drawing options to be set to their default values.
+

+Usage:
+

+
+        reset
+

+

+
flush

+

+Flush any graphics output and synchronize the state of the widget
+with what is shown on the display.
+

+Usage:
+

+
+        flush
+

+

+The gterm widget uses XLIB, which buffers graphics drawing commands and
+automatically sends them to the X server when 1) the buffer fills,
+2) input is requested from the server.  Such buffering of data is necessary
+for efficient operation and it should rarely be necessary to explicitly
+flush graphics output since XLIB does this automatically in most cases.
+An example of when explicitly flushing the ouptut might be necessary is in
+cases where smooth animation is desired and drawing the graphics in batches
+could cause the display to appear "jerky".
+

+
addCallback

+

+Post a callback for a Gterm widget event.
+

+Usage:
+

+
+        addCallback procedure-name [callback-type]
+

+

+The recognized Gterm callbacks are
+

+
+
+        input           Called when the graphics-input action is invoked in
+                        a translation table.  The default Gterm translation
+                        table invokes this action when a KeyPress event occurs
+                        in the Gterm window.
+                        Callback:        widget-name input-type event-data
+
+        resize          Called when the gterm window is resized.
+                        Callback:        widget-name width height
+
+        reset           Called when the "reset" action is invoked.
+                        Callback:        widget-name
+
+

+

+If no callback is specified the default is "input".
+

+Note that in GUI code one can also use the translation table to directly
+invoke GUI procedures without need to use the Gterm input mechanism.  This
+is more flexible but we support the Gterm input callback here for
+applications that use the default translations.
+

+
setCursorPos

+

+Warp the cursor (pointer) to the given coordinates.  This
+is a graphics drawing command and if no raster number is specified the
+current reference drawing raster, as set with setRaster, defines the
+coordinate system.
+

+Usage:
+

+
+        setCursorPos x y [raster]
+

+

+A raster number may optionally given to define the raster coordinate system
+to be used.  raster=0 yields screen coordinates.
+

+
getCursorPos

+

+Get the cursor position (raster 0 or screen coordinates).
+

+Usage:
+

+
+        getCursorPos x y
+

+

+
setCursorType

+

+Set the cursor type.
+

+Usage:
+

+
+        setCursorType cursor-type
+
+        idle        default cursor
+        busy        busy cursor, e.g, when program is busy
+        ginMode     graphics input mode cursor, set when program is
+                    waiting for graphics input
+

+

+
bell

+

+Gterm widget sound output.
+

+Usage:
+

+
+        bell
+

+

+
setRaster

+

+Set the number of the raster to be used to define the drawing
+context (e.g. coordinate system) for graphics and text drawing functions.
+

+Usage:
+

+
+        setRaster raster-number
+

+

+
getRaster

+

+Get the number of the raster which defines the drawing
+context, as set in the last setRaster call.
+

+Usage:
+

+
+        raster = getRaster [raster]
+

+

+If the name of a variable is given the raster number will be stored 
+directly in that variable.
+

+
clearScreen

+

+Clear the "screen", i.e., window.  This action clears the
+drawing window and sets a number of drawing state variables to their default
+values.
+

+Usage:
+

+
+        clearScreen
+

+

+
rasterInit

+

+Initialize the raster subsystem, deleting all rasters and
+mappings and freeing the dynamic part of the colortable.
+

+Usage:
+

+
+        rasterInit
+

+

+
writePixels

+

+Set the values of some subset of the pixels in a raster.
+If any mappings are defined on the affected region and are enabled, any
+destination rasters will be automatically updated as defined by the mapping.
+

+Usage:
+

+
+        writePixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster       The raster number.
+        pixels       The pixel array, encoded as a string.
+        encoding     The pixel encoding.  "numeric" means each pixel is
+                     encoded as a decimal integer delimited by whitespace.
+                     "hex" means the pixel array is hex encoded, 2 bytes
+                     per 8 bit pixel, as a printable text string.  The
+                     two bytes are defined as follows (v = pixel value):
+
+                          byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                          byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                     Whitespace in a hex encoded string is ignored.
+                     Hex encoding reduces the data volume by about a factor
+                     of two (compared to numeric) and is only a factor of
+                     two less space efficient than binary.
+
+        nbits        Number of bits per pixel - currently only 8 bit pixels
+                     are supported.
+
+        x1,y1,nx,ny  Region of the raster to be written.
+

+

+Most real-world image processing applications get the Gterm widget handle
+with setGterm and pass binary data to the widget by calling GtWritePixels
+directly.  This is the most efficient approach for serious image processing
+where large amounts of data are involved.  However, being able to read and
+write raster pixels directly in a GUI can be useful in specialized
+applications, e.g., where the image is computed or modified by the GUI.
+

+
setPixel

+

+Set the value of a single pixel.
+

+Usage:
+

+
+        setPixel raster x y value
+
+        raster   The raster number.
+        x, y     The pixel to be set.
+        value    The pixel value.
+

+

+This routine is more efficient than writePixels for setting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be set.
+

+
readPixels

+

+Get the values of some subset of the pixels in a raster.
+

+Usage:
+

+
+        readPixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster        The raster number.
+        pixels        The pixel array, encoded as a string.
+        encoding      The pixel encoding.  "numeric" means each pixel is
+                      encoded as a decimal integer delimited by whitespace.
+                      "hex" means the pixel array is hex encoded, 2 bytes
+                      per 8 bit pixel, as a printable text string.  The
+                      two bytes are defined as follows (v = pixel value):
+
+                           byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                           byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                      Whitespace in a hex encoded string is ignored.
+                      Hex encoding reduces the data volume by about a factor
+                      of two (compared to numeric) and is only a factor of
+                      two less space efficient than binary.
+
+        nbits         Number of bits per pixel - currently only 8 bit pixels
+                      are supported.
+
+        x1,y1,nx,ny   Region of the raster to be read.
+

+

+Use readPixels to read a block of pixels, and getPixel to get the value
+of a single pixel.
+

+
getPixel

+

+Get the value of a single pixel.
+

+Usage:
+

+
+        getPixel raster x y
+
+        raster      The raster number.
+        x, y        The pixel to be set.
+

+

+This routine is more efficient than readPixels for getting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be read.
+

+
nextMapping

+

+Return the index of the next unused mapping.
+

+Usage:
+

+
+        nextMapping
+

+

+Returns the mapping number as the function value.
+

+
getMapping

+

+Get a mapping.
+

+Usage:
+

+
+        getMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters except the mapping number are output parameters.
+

+
setMapping

+

+Set a mapping.
+

+Usage:
+

+
+        setMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters are input parameters.
+

+
loadColormap

+

+Load a colormap.
+

+Usage:
+

+
+        loadColormap colormap [offset [scale]]
+

+

+The offset and scale parameters may be used to adjust the brightness and
+contrast of the image when the colormap is loaded.  The normalized colormap
+has offset=0.5, scale=1.0.  Colormap zero is the hardware colormap.
+

+
selectRaster

+

+Given the raw screen coordinates SX,SY (or coords in
+any destination raster), determine the mapping and source raster which are
+mapped to that pixel and return the raster and mapping numbers and the
+coordinates of the same pixel in the source raster.
+

+Usage:
+

+
+        raster = selectRaster dras dt dx dy rt rx ry [map]
+

+

+where
+

+
+		dras         display raster
+                dt,rt        coordinate type - "pixel" or "ndc"
+                dx,dy        display raster coordinates (input)
+                rx,ry        source raster coordinates (output)
+                map          mapping selected (output)
+

+

+Note that the coordinates returned by selectRaster are measured (taking
+a line as an example) from zero at the left edge of the first pixel, to 
+"width" at the right edge of the last pixel.  This means that the floating
+point coordinates of the center of raster pixel N will be N + 0.5.  For
+example, if we input screen coordinates (dras=0), x=117, and no mapping
+is in effect, the floating point raster coordinates returned will be 117.5.
+The difference occurs because the input coordinate is a pixel number 
+(integer) while the output coordinate is a floating point coordinate
+measuring the continuously variable location a pixel.  int(x) will convert
+this coordinate to a raster pixel number.
+

+
unmapPixel

+

+unmapPixel is a simplified, less general version of
+selectRaster which will automatically follow graphics pipelines back to
+the original mapped raster.  If desired the raster pixel value can be
+returned as well as the raster number and raster pixel coordinates
+corresponding to a screen (raster 0) pixel.
+

+Usage:
+

+
+        unmapPixel sx sy raster rx ry [rz]
+

+

+where
+

+
+		sx,sy        "screen" (raster 0) coordinates
+                raster       original mapped raster (output)
+                rx,ry        source raster coordinates (output)
+                rz           source raster pixel value (output)
+
+

+By following graphics pipelines back to the original source raster we mean
+the following.  If raster A is mapped to raster B which is mapped to C (the
+screen), given a screen coordinate in the mapped region unmapPixel will
+return the raster number and coordinates for raster A.
+

+
flip

+

+Edit a mapping to flip the mapped subimage in X and/or Y.
+

+Usage:
+

+
+        flip mapping axis [axis]
+

+

+where axis is "x" or "y".  This is a convenience routine for changing only
+the flip portion of a mapping.
+

+
markerInit

+

+Initialize the Marker subsystem for a Gterm widget.
+This destroys all markers and initializes the marker subsystem.
+

+Usage:
+

+
+        markerInit
+

+

+
createMarker

+

+Create a new marker.
+

+Usage:
+

+
+        createMarker name attribute-list
+  e.g.  createMarker name {attribute value [attribute value ...]}
+    or  createMarker name attribute value [attribute value ...]
+
+

+Any marker attribute may be assigned a value when the marker is created.
+Refer to <ObmW/Gterm.h> for a list of marker attribute names.  Often the
+the attributes "type" and "createMode" need to be specified at marker
+create time.
+

+
+        type            The marker type: text, rectangle, circle, etc.
+
+        createMode      A marker should be created with createMode=interactive
+                        if the user is expected to interactively drag out
+                        the marker using the pointer and either the default
+                        or an application specified translation table.  A
+                        marker can also be created interactively using only
+                        the m_create (marker create) action, however m_create
+                        does not allow the marker attributes to be set.
+
+

+There are any number of ways to use a GUI to create a marker under the
+Object Manager, but an example might be using a translation to call a GUI
+procedure which issues the createMarker call.  For example a pointer down
+event could translate as "call(newMarker,$name,$x,$y) m_create()" where
+newMarker is a GUI marker creation procedure which sends a createMarker
+message to the Gterm widget.  The GUI procedure could set the marker
+attributes as desired, possibly using additional GUI components to define
+the marker attributes.  The m_create action will notice that a
+createMarker has been executed and will merely activate the marker and
+give it the pointer focus (i.e. install the marker translations).  The
+user will then use the pointer or keyboard to drag out the marker.
+

+If the marker is created noninteractive the application must set the marker
+position and size using marker attributes.  If the marker is sensitive
+the user can then use the marker's translations to interactively modify
+the marker (resize it, move it, etc.).  All markers which are visible and
+sensitive and which have the necessary translations can be interactively
+modified by the user; the reason for creating a marker in interactive mode
+is to allow the initial marker position and size to be specified
+interactively *when* the marker is created, instead of afterwards.
+

+Any number of attributes may be given when the marker is created.  Most
+marker attributes can also be modified after a marker has been created
+by sending setAttribute messages to the marker.
+
+

+
+
+
6.4 HTML

+
+The HTML (hypertext markup language) widget displays a block of HTML
+formatted text, the "document" to be displayed.  The text consists of a
+mixture of text to be displayed and embedded formatting directives.  The
+text may also contain "hot links" pointing to other HTML-formatted
+documents.
+
+
+               setText text [target [header_text [footer_text]]]
+        text = getText [format [font]]
+         retestAnchors
+ 
+     id = positionToId x y
+          idToPosition id x y
+      anchorToPosition name x y
+       id = anchorToId name
+                gotoId id
+ 
+          n = getHRefs list
+      n = getImageSrcs list
+          n = getLinks list
+ 
+          setSelection start end
+   text = getSelection start end
+        clearSelection
+ 
+            searchText pattern start end [direction [search_type]]
+ 
+           addCallback procedure-name [callback-type]
+        deleteCallback procedure-name [callback-type]
+

+ 
+The possible callback types and their callback arguments are as follows.
+  
+
+       anchor          widget cbtype event text href element_id
+       testAnchor      widget cbtype href
+       submitForm      widget cbtype event attrs href method enctype encentity
+       link            widget cbtype href role
+       pointerMotion   widget cbtype href
+

+ 
+See the comments below for further details on the callback types and their
+arguments.
+
+

+
+
6.4.1 Command Summary

+

+
+

+
+
+
6.5 Markers

+

+A marker is a graphics object implemented by the Gterm-Image widget.
+Markers are not real toolkit widgets, but they act much like widgets and
+are interfaced as an object class under the Object Manager.  The Marker
+class is not a subclass, it is a base class like Widget, but Marker objects
+can exist only as children of Gterm widgets.
+

+Since markers are not independent widgets but rather part of a Gterm widget
+instance, the parent Gterm widget is partially responsible for managing
+markers.  The Gterm widget implements the following commands for dealing
+with markers.
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+A new marker is created by sending the createMarker message to the parent
+gterm widget.  This creates a marker of the given name and type.
+The markerInit command, if sent to a gterm widget, destroys any markers
+defined for that widget and reinitializes the marker facility.  Markers
+may also be created by action procedures in response to user input events.
+

+A marker may be destroyed by itself in response to an input event (e.g. the
+user presses the delete key), by sending the marker the destroy message
+to tell it to destroy itself, by sending a markerInit to the parent gterm
+widget, or by destroying the marker object (or any parent) with the server
+command destroyObject.
+

+Once a marker has been created it behaves as an independent object and
+receives and executes messages, responds to events, generates callbacks,
+and so on.  The marker class defines the following commands.
+

+
+                makeCopy name
+             addCallback procedure [event [event ...]]
+                  notify [event-type [param [param ...]]]
+                 destroy [nocallback]
+

+                 markpos
+                  redraw [function] [markpos|nomarkpos] [erase|noerase]
+

+                   raise [reference-marker]
+                   lower [reference-marker]
+

+                    move x y
+                  resize width height
+                  rotate angle                # radians
+

+                     set attribute value      # alias for setAttribute
+             value = get attribute            # alias for getAttribute
+

+            setAttribute attribute value
+    value = getAttribute attribute
+           setAttributes attribute-list
+           getAttributes attribute-list
+             setVertices points first npts
+             getVertices points first npts
+

+      region = getRegion [unmap] [coord-type]
+                 getRect dx dy dnx dny
+

+

+Marker positions and dimensions are given in window (raster 0) coordinates. 
+

+The operators raise, lower, move, resize, and rotate erase the marker,
+modify it as indicated, and redraw it with the new attributes.  For finer
+control over marker attributes one can use [get|set]Attribute[s] and
+[get|set]Vertices to edit the markers directly.  In this case an auto
+redraw is not performed (unless the autoRedraw marker attribute is set).
+The usual sequence is a markpos to record the marker position, one or more
+setAttribute calls to change marker attributes, then a redraw to erase
+the old marker and redraw the new one.  Markers have many attributes which
+can be set to control things like the position and size, colors, line
+widths, fill type and style, font, rubber-band technique, and so on.
+Refer to <ObmW/Gterm.h> for a list of marker types and attributes.
+

+The marker type may be changed at runtime without destroying the marker.
+For example a circle can be changed to an ellipse or a rectangle.  This
+also works for polygons (the vertex list is preserved and restored when
+the marker is changed back to a polygon).
+

+The current shape of a marker may be queried with getVertices, which
+returns the polygon or polyline vertex list in window coordinates.  A more
+powerful routine which does something similar is getRegion.  This routine
+returns a high level description of the region outlined by the marker,
+giving the marker type (rectangle, circle, ellipse etc.), center, width
+and height, and so on.  Any position or dimension information may
+optionally be transformed back to the original source raster, if the marker
+center is in a region of the window which is the destination of an active
+mapping.  The unmap option will follow multiple mappings back to the
+original mapped source raster.
+

+The getRect function returns the parameters of the region outlined by a
+rectangle marker in a form convenient for use in a Gterm setMapping call
+(this is used to display an image within a marker).
+

+Default translations when pointer is over a marker.
+default Marker Translations
+

+
+        Shift <Btn1Motion>    m_rotateResize()             
+              <Btn1Motion>    m_moveResize()               
+          Shift <Btn1Down>    m_raise()  m_markpos()       
+                <Btn1Down>    m_raise()  m_markposAdd()    
+                  <Btn1Up>    m_redraw() m_destroyNull()   
+                <Btn2Down>    m_lower()                    
+            <Key> BackSpace   m_deleteDestroy()            
+               <Key> Delete   m_deleteDestroy()            
+                <KeyPress>    m_input()                    
+                  <Motion>    track-cursor()               
+

+

+
+
6.5.1  Command Summary

+

+
makeCopy

+

+Copy a marker.  The new marker is initially identical to the
+old one, and will not be distinct until, e.g., moved to a new center.
+

+Usage:
+

+
+         makeCopy name
+

+

+
addCallback

+

+Post a marker callback to be called when the specified
+event or events occurs.  If no events are listed a Notify callback will
+be posted.
+

+Usage:
+

+
+	addCallback procedure [event [event ...]]
+

+

+
notify

+

+Generate a Marker pseudo-event, causing any posted client
+callback procedures to be called.
+

+Usage:
+

+
+        notify [event-type [param [param ...]]]
+

+

+
destroy

+

+Destroy a marker.  Just tell the marker to destroy itself.
+All cleanup outside the marker facility relies upon the use of callbacks.
+This includes our callback markerDestroyCallback below.
+

+Usage:
+

+
+        destroy
+

+

+
markpos

+

+Mark the current position of a marker for a later redraw.
+

+Usage:
+

+
+        markpos
+

+

+Markpos is used to mark the position of a marker before changing any
+marker attributes, so that a later "redraw marked" will erase the old
+marker rather than the new one.  This is necessary, for example, if any
+marker attributes are changed which affect the size or position of the
+marker.
+

+
redraw

+

+Redraw a marker.
+

+Usage:
+

+
+        redraw [function] [erase|noerase] [markpos|nomarkpos]
+

+

+By default redraw will erase the old marker at the position indicated by
+a previous call to markpos, and redraw the marker with the current
+attributes using the drawing function copy (copy source to destination).
+Hence the usual usage is "markpos ... change marker attributes ... redraw".
+Optional arguments may be given to change the drawing function, enable or
+disable erase, or force redraw to do a markpos.  These arguments may be
+given in any order.
+

+The drawing functions are as given in the XLIB documentation, minus the
+"GX" prefix.  The most commonly used functions are "copy" and "xor".
+A normal marker redraw uses function=copy.
+

+
raise

+

+Raise a marker, i.e., cause it to be drawn on top of other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        raise [reference-marker]
+

+

+In a reference marker is named the marker will raise itself above this
+marker, otherwise the raised marker becomes the topmost marker.
+

+
lower

+

+Lower a marker, i.e., cause it to be drawn beneath other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        lower [reference-marker]
+

+

+In a reference marker is named the marker will lower itself beneath this
+marker, otherwise the lowered marker becomes the lowest marker.
+

+
move

+

+Move a marker.
+

+Usage:
+

+
+        move x y
+

+

+Move the marker center to the indicated coordinates in the display window.
+

+
resize

+

+Resize a marker.
+

+Usage:
+

+
+         resize width height
+

+

+Resize the marker to the indicated size.  By default width and height are
+given in pixels.  For a text marker one can append "ch" to indicate that
+the units are chars in whatever font is in use, e.g., "40ch" or "40 chars"
+is an acceptable value for a text marker dimension.
+

+
rotate

+

+Rotate a marker.
+

+Usage:
+

+
+         rotate angle
+

+

+Redraw a marker oriented to the given rotation angle.  The angle is
+given in radians.
+

+
getAttribute

+

+Return the value of a marker attribute.
+

+Usage:
+

+
+        value = getAttribute attribute-name
+

+

+
setAttribute

+

+Set the value of a marker attribute.
+

+Usage:
+

+
+        setAttribute attribute-name value
+

+

+
getAttributes

+

+Return the values of a list of marker attributes.
+

+Usage:
+

+
+          getAttributes attribute-list
+  i.e.    getAttributes {name value [name value ...]}
+    or    getAttributes name value [name value ...]
+

+

+where "value" is the name of the variable in which the attribute value 
+is to be stored.
+

+
setAttributes

+

+Set the values of a list of marker attributes.
+

+Usage:
+

+
+        setAttributes attribute-list
+  i.e.  setAttributes {name value [name value ...]}
+

+

+where "value" is the new value of the associated marker attribute.
+

+
getVertices

+

+Get some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        getVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is returned in the
+variable "points", as a string of the form { {x y} {x y} ...}.  The first
+point is number zero.
+

+
setVertices

+

+Set some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        setVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is set using the points
+passed in the "points" variable as a string of the form { {x y} {x y} ...}.
+If FIRST and NPTS are not specified first is assumed to be zero (the first
+point) and NPTS is the length of the points array.
+

+
getRegion

+

+Return as a text string a high level description of the
+region defined by a marker.
+

+Usage:
+

+
+        region = getRegion [unmap] [coord-type]
+

+

+The output string defines the marker type and the major marker positional
+attributes.  The region description formats for the various marker types
+follow.
+

+
+        text raster x y width height
+        line raster x y x y
+        polyline raster npts { {x y} {x y} ...}
+        rectangle raster x y width height rotangle
+        circle raster x y radius
+        ellipse raster x y width height rotangle
+        polygon raster npts { {x y} {x y} ...}
+

+

+Here, width and height refer to the distance from the marker center to an
+edge, not to the width or height of the whole marker.  This avoids
+ambiguities about where the edge of a marker is if the width is even or
+odd.  Using the center to edge measurement, the edge is at x +/- width,
+y +/- height.
+

+If the "unmap" flag is given getRegion will attempt to associate the
+marker with a mapped raster, reversing any mappings from the screen back
+to the original source raster, and returning the raster number and raster
+coordinates and marker sizes.  If "unmap" is not given the marker
+coordinates will refer to raster 0.  Either pixel ("pixel") or NDC
+("ndc") coordinates may be returned, pixel coordinates being the default.
+

+
getRect

+

+Return the region enclosed by a rectangle marker.  The rect is
+returned in a form convenient for use as the destination rect in a gterm
+widget raster mapping.
+

+Usage:
+

+
+        getRect dx dy dnx dny
+

+

+The rect is stored in the output arguments.
+

+
+

+
+
+
6.6 Widget

+

+The Widget class is the generic or base class for the window system
+toolkit widgets supported by the object manager.  The Widget class
+supports a number of different Xt widget classes using a table driven
+approach to describe each widget.  Any widget may be created, destroyed,
+and manipulated in various ways using only the generic Widget class
+procedures and Widget-specific resources.  The Widget class may be
+subclassed to support complex Widgets that require custom class-specific
+commands for use by the GUI code.
+

+Generic Widget-class commands:
+

+
+                 set <resource-name> <value>
+                 get <resource-name>
+

+         addCallback <procedure-name> []
+      deleteCallback <procedure-name>
+        setSensitive <sensitive>
+         isSensitive
+

+             realize
+           unrealize
+         isRealizeed
+                 map
+               unmap
+              manage child [child ...]
+            unmanage child [child ...]
+               popup [grab-kind]
+             popdown
+   popupSpringLoaded
+

+                move <x> <y>
+              resize <width> <height> <border-width>
+           configure <x> <y> <width> <height> <border-width>
+

+

+The most important Widget commands are set/get resource, and the
+callbacks.  The widget sensitivity can be set and queried using set/get
+resource, but special procedures are provided to make this common operation
+more convenient.
+

+Class specific functions:
+

+
+                 append text                         # text widget
+                setList list [resize]                # list widget
+        value = getItem itemno
+              highlight itemno
+            unhighlight
+

+

+Ideally the widget class should be subclassed for widgets that require
+class-specific functions, but in simple cases involving standard widgets
+the support is built into the widget class code as a special case.
+

+Special actions (used in translations):
+

+
+                call (proc [,arg, ...])
+               popup (menu-name [xoffset [yoffset]])
+             popdown (menu-name)
+

+

+The "call" action is a very general mechanism which allows any GUI procedure
+to be registered with any translation using the X translation table
+mechanism.  The popup and popdown actions are used for popup menus.  The
+menu will be popped up at the event coordinates plus the optional offsets
+if given.
+

+Event handling:
+

+
+     addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+Event callback:
+

+
+    userEventHandler widget event-type time wx wy rx ry other
+

+

+In most cases translations are preferable to events, but a GUI can capture
+raw events if it wishes by adding event handlers.  Nearly all of the X
+event types are supported.  The callback syntax employs a number of
+standard arguments, followed by a number of event-specific arguments.
+

+
addCallback

+

+Add a callback procedure to the callback list for
+a widget.  If no callback name is given, "callback" is assumed.
+

+Usage:
+

+
+        addCallback  [<callback-name>]
+

+

+Specific widgets only support certain types of callbacks.  There is no
+checking that the callback type specified is supported by a widget; the
+wrong type of callback can be registered, but it will never be called.
+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a widget.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
do_userproc (call)

+

+Translation action procedure used to call general user
+action procedures in the interpreter.  The name of the user procedure to
+be called is given as the first argument in the translation.  For example,
+the translation "call(foo,a,b,c)" would cause procedure foo to be called
+with the arguments (a,b,c).  The following arguments are special:
+

+
+        Argument        Replaced by
+

+        $name             object name of widget
+        $time             event->time
+        $x                event->x
+        $y                event->y
+        $x_root           event->x_root
+        $y_root           event->y_root
+

+

+The "user procedure" can be any server procedure.
+

+
do_popup

+

+Popup a menu (or other spring loaded popup) at the location
+of the event which triggered this action.
+

+Usage:
+

+
+        popup(menu-name [xoffset [yoffset]])
+

+

+
do_popdown

+

+Pop down a menu.
+

+Usage:
+

+
+        popdown(menu-name)
+

+

+
set

+

+Set a widget resource.
+

+Usage:
+

+
+        set <resource-name> <value>
+

+

+
get

+

+Get a widget resource value as a string.
+

+Usage:
+

+
+        get <resource-name>
+

+

+
append

+

+Append data to a text widget.
+

+Usage:
+

+
+        append <text>
+

+

+
setList

+

+Set the item list of a list widget.
+

+Usage:
+

+
+        setList list [resize]
+

+

+The list is a simple list of strings, passed as a single string argument to
+setList (quotes, braces, etc. may be used to quote strings containing
+special characters).
+

+
getItem

+

+Get an item in a list widget.
+

+Usage:
+

+
+        value = getItem itemno
+

+

+If ITEMNO is a number the indicated list item is returned, or the string
+"EOF" if the requested item is beyond the end of the list.  Otherwise the
+currently selected item is returned, and the index of the item is returned
+in the output variable ITEMNO.  If no item is currently selected ITEMNO
+will be set to "none" on output.
+

+
highlight

+

+Highlight an item in a list widget.
+

+Usage:
+

+
+        highlight itemno
+

+

+The indicated item of the list is highlighted as if the item had been
+selected by the user.  Any previously highlighted item is unhighlighted.
+

+
unhighlight

+

+Unhighlight the currently highlighted item in a
+list widget.
+

+Usage:
+

+
+        unhighlight
+

+

+Any currently highlighted item in the list widget is unhighlighted.
+

+
realize

+

+Realize a widget.  This activates and assigns windows for
+a widget and all of its descendants.  Realizing a widget does not in itself
+cause it to appear on the screen.
+

+Usage:
+

+
+        realize
+

+

+
unrealize

+

+Unrealize a widget.  This destroys the windows assigned
+to a widget and all of its descendants.
+

+Usage:
+

+
+        unrealize
+

+

+
isRealized

+

+Test whether a widget is realized.
+

+Usage:
+

+
+        isRealized
+

+

+
map

+

+Map a widget.
+

+Usage:
+

+
+        map
+

+

+
unmap

+

+Unmap a widget.
+

+Usage:
+

+
+        unmap
+

+

+
manage

+

+Manage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Managing the
+children makes them appear in the window, possibly causing the other
+children to be rearranged in the window.
+

+Usage:
+

+
+        manage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
unmanage

+

+Unmanage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Unmanaging the
+children makes them disappear from the window and be removed from geometry
+management, possibly causing the other children to be rearranged in the
+window.
+

+Usage:
+

+
+        unmanage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
popup

+

+Popup a shell widget.  If no grab is indicated the popup
+can remain up while other windows accept input.
+

+Usage:
+

+
+        popup [grab-kind]
+

+

+
popdown

+

+Popdown a shell widget.
+

+Usage:
+

+
+        popdown
+

+

+
popupSpringLoaded

+

+Popup a shell widget, e.g., a popup menu.
+This implies an exclusive grab.
+

+Usage:
+

+
+        popupSpringLoaded
+

+

+
move

+

+Move a widget to the given window relative coordinates.
+

+Usage:
+

+
+        move <x> <y>
+

+

+
resize

+

+Resize a widget.
+

+Usage:
+

+
+        resize <width> <height> <border-width>
+

+

+
configure

+

+Configure a widget, i.e., execute a simultaneous
+move and resize.
+

+Usage:
+

+
+        configure <x> <y> <width> <height> <border-width>
+

+

+
setSensitive

+

+Set the sensitivity of a widget.
+

+Usage:
+

+
+        setSensitive <sensitive>
+

+

+
isSensitive

+

+Test the sensitivity of a widget.
+

+Usage:
+

+
+        isSensitive
+

+

+
addEventHandler

+

+Add a custom event handler to a widget.  A list
+of event masks is given to define the classes of events the user supplied
+event handling procedure is to receive.
+

+Usage:
+

+
+        addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+
removeEventHandler

+

+Remove an event handler previously posted
+with addEventHandler, above.
+

+Usage:
+

+
+        removeEventHandler procname
+

+

+
event

+

+Generic event handler called when a widget event handler
+posted by addEventHandler is called.
+

+The user event handler is called as
+

+
+        userEventHandler widget event-type time wx wy rx ry other
+

+

+where "other" is an event-type specific list of fields describing the
+the event.
+

+
+
+
6.7 Parameter

+

+The UI parameter class is used for client-UI communications.  The client
+does not control the user interface directly, rather the UI defines a set
+of abstract UI parameters, and during execution the client application
+assigns values to these parameters.  These UI parameters should be thought
+of as describing the runtime state of the client as viewed by the GUI.
+The GUI is free to interpret this state information in any way, including
+ignoring it.  Many GUIs can be written which use the same client state
+as described by the UI parameters.
+

+Assigning a value to a UI parameter causes the new value to be stored, and
+any parameter action procedures registered by the UI to be called.
+The action or actions [if any] taken when a parameter value changes are
+arbitrary, e.g. the action might be something as simple as changing a
+displayed value of a UI widget, or something more complex like displaying
+a popup.
+

+
UI Parameter class commands:

+

+
+            getValue
+            setValue  <new-value>
+         addCallback  <procedure-name>
+      deleteCallback  <procedure-name>
+              notify
+

+

+The most common usage is for the GUI to post one or more callbacks for
+each UI parameter.  When the UI parameter value is changed [with setValue,
+e.g. by the client] the GUI callback procedures are called with the old
+and new UI parameter values on the command line.  addCallback is used to
+add a callback procedure, and deleteCallback to delete one.  Multiple
+callbacks may be registered for a single UI parameter.  notify is used
+to simulate a parameter value change, causing any callback procedures to
+be invoked.
+

+The callback procedure is called as follows:
+

+
+	user-procedure param-name {old-value} {new-value}
+

+

+The important thing to note here is that the old and new value strings
+are quoted with braces.  This prevents any interpretation of the string
+by Tcl when the callback is executed, which is necessary because the
+strings can contain arbitrary data.  When Tcl calls the callback the
+first level of braces will be stripped off, leaving old-value and new-value
+each as a single string argument.
+

+

+
setValue

+

+Set the value of a parameter, and notify all clients
+via the posted callback procedures that the parameter value has changed.
+

+Usage:
+

+
+        setValue <new-value>
+

+

+
getValue

+

+Get the value of a parameter.
+

+Usage:
+

+
+        getValue
+

+

+
notify

+

+Notify the registered clients of a parameter as if the
+value had changed.
+

+Usage:
+

+
+        notify
+

+

+
addCallback

+

+Add a callback procedure to the callback list for
+a parameter.
+

+Usage:
+

+
+        addCallback <procedure-name>
+

+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a parameter.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
+

+
+
diff --git a/vendor/x11iraf/obm/docs/obm/obm.html b/vendor/x11iraf/obm/docs/obm/obm.html
new file mode 100644
index 00000000..b7e531ca
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/obm.html
@@ -0,0 +1,2515 @@
+
+
+IRAF Object Manager Tutorial
+
+

+
IRAF Object Manager Tutorial

+

+

+
+
Contents

+
+
+

+
+
+
1.  Introduction

+

+An Object Manager (OBM) user interface (UI) consists of one or more windows
+containing an arbitrary hierarchy of widgets.  These widgets and their
+runtime actions are defined by an interpreted text program uploaded
+by the client application, which does not itself deal directly with the
+window user interface.  This interpreted program is currently written
+as a Tcl script.
+

+The OBM provides a high level abstraction for dealing with widgets and
+other UI objects.  The main function of the object manager is to deliver
+messages to UI objects.  Each instance of a widget is an object in the
+interface.  The UI contains other types of objects as well, including the
+client object (client application), the server object (the object manager
+itself), and the application specific UI parameters, each of which is an
+object with a callback list of procedures to be called when the parameter
+value changes.  All of these UI objects can receive messages and take actions
+as a result.  Messages may come from the client application, or as a result
+of actions executed by the interpreted UI code in response to graphics events.
+

+

+
+
2.  System Architecture

+

+For a complete description of the OBM system architecture see Tody, D,
+ADASS Proceedings 1994.  A postscript version of this
+paper is also vailable.
+

+

+

+
+
3.  The Client Process

+

+	The primary advantage of the OBM architecture over traditional GUI
+design is the separation of the user interface from the executable client
+code, meaning that either can be completely rewritten or developed separately
+without affecting the other so long as the messaging between the two
+remains the same.  The client itself is responsible for initializing the OBM
+toolkit and uploading the UI definition file, after that it usually enters
+an event loop of some kind (e.g. an iraf graphics cursor loop, or X event
+handler) to process actions defined in the client callbacks.
+

+	It's important that the client program maintain the state of the
+application rather than the UI file.  For example, a text widget in the
+interface may instruct the client to load a file, however if this cannot
+be done the interface should not have independently reset labels or
+whatever assuming the action was done at all.  Instead, the client program
+uses the Parameter Class objects in the interface to update the state of
+the GUI as a result of some action (whose origins may not have been in the
+GUI at all).  So for example a sequence of events could be something like
+
+
      
+
    •  User selects a widget in the interface, it's callback sends a
+	message to the client directing some action be taken
+
    •  Client receives the message and performs an action in the client
+
    •  If action fails, (optionally) notify GUI of failure (e.g. send a
+	message to an 'alert' parameter to popup a dialog box, beep the
+	terminal, etc)
+
    •  If action succeeds, notify GUI of new state (e.g. send a message
+	to the 'filename' Parameter object containing the new file name).
+
    •  Callback on the 'filename' parameter then updates the status bar
+	widget with the name of the new active file.
+

+
+

+	The messaging between the client and UI depend on the details of how
+the client is implemented.  In general any callback procedure in the UI can
+send a message to any other object in the interface, but the client should
+generally communicate only via the Parameter objects to avoid side effects
+and maintain a clear separation between the UI and the client code.
+
+
+
3.1  IRAF Graphics Task

+
+
+
3.1.1  XGterm

+
+
+
3.2  Standalone Task

+
+
+
3.3  OBM Shell

+

+	The obmsh is a unix shell interpreter for GUI scripts.  It is
+a minimal standalone client with a single callback to exit the application,
+otherwise it's only job is to activate the GUI file.  Any messages sent to
+the client (except a 'quit') are simply absorbed by the client
+

+	Despite the apparent lack of functionality this is sometimes all
+that is required for an interface that can operate independently.  Remember
+that the Tcl scripting language has it's own facilities for file I/O, 
+process execution, etc, all of which are still available in the GUI.  In
+the case of IRAF tasks it's an interface violation to use these facilities
+directly, however they still allow for the easy creation of a GUI which 
+requires no real underlying client (e.g. a tcl debug shell, a calculator
+application, task launcher, etc).
+
+
+
3.4  Named External Clients

+
+

+

+

+

+
+
4.  UI Definition File

+

+A UI definition consists of a sequence of commands to be executed by the
+server object using Tcl is used as an embedded interpreter within the OBM.
+The Tcl script contains several required OBM-specific functions (in
+addition to the user-defined callbacks) which is uploaded by the client
+as a message for the server object.  
+
+    reset-server
+    appInitialize  appName appClass Resources
+    createObjects  [name]
+    activate
+

+

+All UI files must begin with a reset-server command to initialize
+the OBM.  An appInitialize call is then made to define all of the
+widgets and resources used in the interface, initializing the interface
+used by the application.  The createObjects function then actually
+creates the widgets in the server, more specifically it creates the widgets
+defined by the named objects resource.  Lastly, the activate
+call is used to activate the interface, i.e. put it on the screen.
+
+

+
+
4.1  Example

+A complete "hello, world" GUI definition might look something like:
+
+     1)    reset-server
+     2)    appInitialize hello Hello {
+     3)        *objects:\
+     4)            toplevel     Form       helloForm\
+     5)            helloForm    Label      helloLabel\
+     6)            helloForm    Command    quitButton
+     7)
+     8)        *background:               	gray
+     9)        *helloLabel.label:         	Hello, world!
+    10)        *quitButton.fromHoriz:     	helloLabel
+    11)        *quitButton.label:         	Quit
+    12)    }
+    13)
+    14)    createObjects
+    15)    activate
+    16)
+    17)    proc Quit args { 
+    18)	     send client gkey q
+    19)      deactivate unmap
+    20)    } ; send quitButton addCallback Quit
+

+
+where a line-by-line analysis of the GUI shows:
+
+

+
Line 1: 
- The reset-server command must be the first line in
+the UI file since it's primary purpose is to initialize the OBM (i.e. a
+call to the ObmInitialize() procedure).  Subsequent calls (in the
+same UI file or a different UI) are effectively a no-op.
+
Lines 2-12: 
- The appInitialize command defines the widgets
+and resources to be used in the interface.  The first argument gives the
+name of the application, the second argument is the application class name
+for purposes of specifying resources in the environment, and the last 
+argument is a Tcl list (hence the braces) of resources for the application.
+

+The primary purpose of the call is to initialize the X11 part of the system
+by defining the application context and the list of fallback resources.  The
+objects resource is a required element listing the widget hierarchy
+to be used.  Remaining resources are used to specify labels, colors, layout,
+etc and serve as an app-defaults file for the GUI, interacting with the
+normal resource database in the usual way.  For example, a user's .Xdefaults
+file may specify a "font" resource, unless this is overridden in 
+some way in the UI file this is the font that will be used.  Resources may
+be specified with either "loose" (i.e. the '*') or "tight" (i.e. the '.')
+bindings with as much detail as is needed.
+
Line 14: 
- The createObjects command is what actually calls
+each widget's Initialize() method to create the widget in the application
+and in the X11 server.  
+

+With no argument, the default value used is simply
+the objects resource.  However, it's possible to specify a named
+argument and make repeated calls to createObjects to build any number
+widget trees prior to activating the interface.  This can be useful for
+example to specify a "main_objects" resource contains all the widgets for
+the main panel, and a "help_objects" specfiying widgets used for the UI
+help panel, which makes the definition file easier to organize.  In the
+past however UI files were written with a single long list (easily many 
+hundreds of lines) of objects followed by an even longer list of their
+resources under a single appInitialize call, creating a monolithic
+and unmanageably GUI definition file.  Later on we'll see how complex GUIs
+can be divided into separate pieces making it easier to reuse code and
+manage the interface more efficiently.
+
Line 15: 
- The activate command is what creates the interface
+on the screen, i.e. it calls the Realize() method for each widget to
+instantiate it in the server and draw the window.
+
Lines 17-19: 
- Lastly we have the user-defined callback procedures.
+On line 17 we define a procedure Quit which we use to shut down the
+interface and client application.  The body of the procedure first sends the
+client object the graphics keystroke 'q' to shut down the client, then calls
+the deactivate command to close the interface.  On the last line 
+we send a message to the quitButton widget telling it to add this
+procedure to it's callback list, so when the Button is selected this
+procedure will be called as a result.
+

+

+

+
+
+
5.  Widget Toolkit

+

+

+

+
+
+
5.  Object Classes

+

+The following OBM object classes are currently defined:
+
+    Client		The Client application
+    Server		The OBM itself
+    Gterm		Gterm graphics/imaging widget class
+    HTML		HTML widget class
+    Markers		Gterm markers class
+    Widget		General widget class
+    Parameter		UI Parameter class
+

+    Various Xt and Athena widgets
+    		{box, shell, label, command, text, list, etc.}
+    Misc Other X11 Widgets
+    		{Layout, Tabs, ListTree, etc}
+

+

+OBM client applications will upload a UI during initialization to define a
+custom graphics user interface.  This is done by sending a message to the
+object manager.  Non-GUI applications assume a simple graphics
+terminal and do not upload a UI; instead, a default UI is created
+for the application consisting of a single top level shell containing a
+Gterm (Tek 4012 graphics/imaging) widget.
+

+
+

+
+
+
5.1 Client

+

+The client is the client application, which provides the functionality
+underlying the UI.  When a message is sent to the client object it usually
+results in a message being sent to the client *application*, usually an
+external program communicating via IPC, which has little or no knowledge
+of the UI.  The client application receives and executes commands delivered
+by the UI via the client object.  Output from the client may or may not
+come back to the object manager.  That portion of the output which comes
+back to the object manager is in the form of assignments of string values
+to UI Parameter class objects (another way of thinking
+of this is that messages or events are sent to and acted upon by the parameter
+objects).  Hence, the client object is output only so far as the client
+application is concerned.
+

+The Client-class commands are used to send a message to the client.
+

+
+                gkey <key>
+                gcmd <command-string>
+             literal <command>
+

+

+or just <command>, e.g., "send client <command>" will work in most cases.
+

+GKEY sends an IRAF graphics keystroke.
+GCMD sends an
+IRAF graphics colon command.  LITERAL sends a literal
+command string to the
+client.  The keyword "literal" may optionally be omitted, i.e., "send client
+foo" and "send client literal foo" are the same.  The keyword "literal" may
+be used to ensure that the client command string which follows will not
+be interpreted as a Client-class command (such as gkey, gcmd, or literal).
+

+
+
5.1.1 Command Summary

+

+
gcmd

+

+Send a graphics command string to the client application.
+A graphics command string is a graphics cursor value with the key set
+to `:' and the command string given as the string part of the cursor
+value.  The protocol module which posted the client output procedure is
+responsible for encoding and sending the cursor command.
+

+Usage:
+

+
+        gcmd <command-string>
+

+

+
gkey

+

+Send a graphics key event to the client application.
+A graphics key event is a graphics cursor value with the key set to some
+integer value and a null string part.
+

+Usage:
+

+
+gkey <key>
+

+

+
literal

+

+Send a literal command to the client application.
+

+Usage:
+

+
+        literal <command>
+

+
+

+
+
+
6.2 Server

+

+The server, or object manager, is the control center of the user interface.
+The server object provides a Tcl interpreter calling custom object manager
+commands. These are used to define and initialize the user interface, and
+execute UI action procedures at runtime.
+

+
+          reset-server
+         appInitialize  appname,appclass,resources
+         createObjects  [resource-name]
+         destroyObject  object
+              activate
+            deactivate  [unmap]
+

+   value = getResource  resource-name [default-value [class]]
+          getResources  resource-list
+

+            createMenu  menu-name parent item-list
+              editMenu  menu-name parent item-list
+           destroyMenu  menu-name
+

+          createBitmap  name width height data
+          createCursor  name source mask fg_color bg_color x_hot y_hot
+          createPixmap  name width height depth fg_color bg_color data
+

+                 print  arg [arg ...] # debug messages
+                  send  object message
+

+  postActivateCallback  procedure
+id = postTimedCallback  procedure msec [client-data]
+   deleteTimedCallback  id
+ id = postWorkCallback  procedure [client-data]
+    deleteWorkCallback  id
+

+
+
+
6.2.1 Command Summary

+

+
serverReset

+

+The "reset-server" command is implemented as a special case in ServerEvaluate.
+After doing a true reset ServerEvaluate calls Tcl_Eval to evaluate the full
+message which still contains the reset-server command. We want to ignore
+this the second time, so we treat the command here as a no-op.
+

+Usage:
+

+
+        reset-server
+

+

+Note: for reset-server to be recognized by ServerEvaluate and really reset
+things, it must be the first command in a message to the server.
+

+
createObjects

+

+TCL command to create the tree of UI objects comprising the user interface.
+The object tree is defined by a string valued resource. If no resource is
+named the default "objects" resource will be used.
+

+Usage:
+

+
+        createObjects [resource-name]
+

+
destroyObject

+

+Destroy an object and all of its children.
+

+Usage:	
+
+        destroyObject object-name
+

+

+
activate

+Activate the user interface. When called the first time the user interface
+is created and activated, thereafter the UI is merely reactivated (e.g.
+mapped if unmapped).
+

+Usage:	
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the user interface. Optionally unmaps the UI and calls the Obm
+client back to let it know that the UI has been deactivated.
+

+Usage:
+

+
+        deactivate [unmap]
+

+

+
getResource

+

+Get the string value of the specified application resource (window
+system parameter). This allows use of the resource mechanism to supply
+default values for GUI parameters.
+

+Usage:
+

+
+        value = getResource resource-name [class [default-value]]
+

+

+In the simplest case one merely requests a resource by name and the
+string value is returned as the function value. If the resource has
+an entry in the fallback resources for the application (appInitialize
+resource list) then a value is guaranteed to be returned.
+

+If the Class name for the resource is given then a class default value
+will be returned if no entry is found for the name resource instance. This
+is useful when there are a number of resources of the same type (same class).
+If most or all resources in the same class have the same default value one
+need only make one entry for the Class in the application defaults resource
+list. It is up to the application developer to define the class name of a
+resource - the class name can be any string. Examples are "Font", "Cursor",
+etc. By convention the first character of a class name is capitalized, while
+instance names begin with a lower case letter.
+

+If there is an entry for the named resource in the resource list passed to
+appInitialize then a value string is guaranteed to be returned. This will be
+either the appInitialize default, or a value specified by the system or the
+user in an X resources file. If one is not certain a default value is defined
+somewhere, a default value should be specified in the getResource call as
+shown above.
+

+See also getResources, used to get multiple resources in one call.
+

+
getResources

+

+Get the string values of a list of resources.
+

+Usage:
+

+
+        getResources resource-list
+

+

+e.g.
+
+        getResources {
+            { resource [variable class [default-value]]] }
+            { resource [variable class [default-value]]] }
+            (etc.)
+        }
+

+

+
createMenu, editMenu

+

+Create or modify a menu. The editMenu function is an alias for createMenu.
+

+Usage:
+
+        createMenu menu-name parent item-list
+

+

+e.g.,
+
+        createMenu menu-name parent {
+            { label function data [options...] }
+            { label function data [options...] }
+            (etc.)
+        }
+

+

+where
+

+
+        menu-name is the object name for the menu popup shell
+        parent    is the parent widget of the menu shell
+        label     is a menu item label
+        function  is the function to be performed when the menu
+        item      is selected, e.g., f.exec, f.data, f.space, or f.line.
+        data      is function dependent data
+        options   are option-name option-value pairs, as specified
+                  below.
+

+

+In the item list the fields label and option-value may be any Tcl expression.
+Expressions are evaluated in the server context. The data field is a Tcl
+script to be executed when the menu item is selected.
+

+Options are specified as "option option-value". The menu item options are
+as follows.
+

+
+        bitmap       A bitmap to be displayed left justified in the label field
+                     (e.g. to indicate a parameter setting).
+        sensitive    Specifies whether the menu item is active (sensitive=true)
+                     or inactive (sensitive=false, item grayed out).
+        accelerator  Specifies an input translation (accelerator, e.g.,
+                     keyboard event) which can be used to execute the
+                     menu item.
+

+

+The option-value field may be any Tcl expression.
+

+Example:
+

+
+        createMenu fileMenu toplevel {
+            { "File Menu" f.title}
+            { Open f.exec openFile}
+            { Save f.exec saveFile}
+            { Load f.menu loadMenu}
+            { no-label f.line }
+            { Quit f.exec "send client Quit" }
+        }
+

+

+The first createMenu is called for a given menu the menu is created, added
+to the menu list, and all window system widgets are created for the menu.
+Subsequent calls will result in only the changed parts of the menu being
+altered provided the changes are not great. Hence this routine can be called
+to efficiently modify a menu when minor runtime changes occur, e.g., an
+item label or action changes, the item value changes state, and so on,
+without need for the GUI code to know how to make the necessary detailed
+changes to the widgets used to implement the menu.
+

+
destroyMenu

+

+Destroy a menu. This can be used to free up the resources used by a
+menu, e.g., if the menu is not expected to be needed again for a while.
+

+Usage:
+

+
+        destroyMenu menu-name
+

+

+
createBitmap

+

+Create a named bitmap. This replaces any old bitmap of the same name. The
+new bitmap is cached in server memory; when a widget bitmap resource is set,
+the bitmap cache will be searched for the named bitmap before asking Xlib
+to find the bitmap.
+

+Usage:
+

+
+        createBitmap name width height data
+

+

+e.g., 
+

+
+        createBitmap foo 16 16 {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+
createCursor

+

+Create a cursor from bitmap data. The cursor is entered into the server's
+cursor cache and will override any existing entry of the same name.
+

+Usage:
+

+
+        createCursor name source mask fg_color bg_color x_hot y_hot
+

+

+e.g., 
+

+
+        createCursor foo bitmap1 bitmap2 black white 8 8
+

+

+The named bitmaps must be created first with createBitmap.
+

+
createPixmap

+

+Create a named pixmap. This replaces any old pixmap of the same name. The
+new pixmap is cached in server memory; when a widget pixmap resource is set,
+the pixmap cache will be searched for the named pixmap before asking Xlib
+to find the pixmap.
+

+Usage:
+

+
+        createPixmap name width height depth fg_color bg_color data
+

+

+e.g., 
+

+
+        createPixmap foo 16 16 8 black white {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+

+
print

+

+Print a string on the standard output. This is used mainly for debugging
+user interfaces.
+

+Usage:
+

+
+        print arg [arg ...]
+

+

+
send

+

+Send a message to an object. The object interprets the message and returns
+a function value as the string result of the TCL command.
+

+Usage
+

+
+        send <object> <message>
+

+

+
postActivateCallback

+

+Post a callback procedure to be called when the UI is activated. The UI is
+activated when it is first downloaded to server, but it may also be
+activated (reactivated) after the application has exited and is later
+restarted, or when the UI is deactivated and reactivated. Note 
+that the UI state vis-a-vis the external world (client application) may
+no longer be accurate after it has been idle for a time and then reactivated.
+

+Usage:
+

+
+        postActivateCallback <procedure>
+

+

+

+
postTimedCallback

+

+Post a callback to call the named procedure back after a specified delay
+in milliseconds.
+

+Usage:
+

+
+        id = postTimedCallback procedure msec [client-data]
+

+

+After the specified delay the user callback procedure will be called with
+client_data (if given) as the single argument. Only one call will be made;
+the client must repost the callback in each call if the procedure is to be
+repeatedly executed.
+

+An ID value is returned which may be passed to deleteTimedCallback to delete
+the timer.
+

+
deleteTimedCallback

+

+Delete a timer callback procedure. This procedure is typically used to
+break a timer loop, where the timer procedure repeatedly reposts itself at
+the end of each interval.
+

+Usage:
+

+
+        deleteTimedCallback id
+

+

+The ID string is returned by postTimedCallback when a timer is posted.
+

+
postWorkCallback

+

+Post a callback for a procedure to be called when the server is idle.
+Work procedures are used to perform computations in the background while
+the user interface remains active and able to respond to input events.
+This works only if the user work procedure does its job in small increments,
+doing only a small amount of processing in each call. The work procedure
+will be called repeatedly until it returns a status indicating that it has
+finished its task.
+

+Usage:
+

+
+        id = postWorkCallback procedure [client-data]
+

+

+When the server has nothing else to do the user work procedure will be
+called with client_data (if given) as the single argument. The work procedure
+should return the string "done" when all processing is finished, or any other
+string if the procedure is to be called again.
+

+An ID value is returned which may be passed to deleteWorkCallback to delete
+the work procedure.
+

+
deleteWorkCallback

+

+Delete a work callback procedure.
+

+Usage:
+

+
+        deleteWorkCallback id
+

+

+The ID string is returned by postWorkCallback when a work procedure is posted.
+
+

+
+
+
6.3 Gterm

+

+The gterm-image widget is a general 2D graphics-imaging widget providing
+a wide range of facilities for drawing graphics and text, for image
+display, and for graphics interaction.  Normally the client communicates
+directly with the Gterm widget to draw graphics, download image data,
+and so on, using some communications protocol outside the domain of the
+object manager.  Nonetheless so far as possible the facilities of the Gterm
+widget have also been made available to GUI code via the commands listed
+here.
+

+The Gterm widget adds the following function to the OBM library.
+

+
+    ObmPostSetGtermCallback (obm, &setgterm, setgterm_client_data)
+

+

+This is called by a client application to post a procedure to be called
+when a gterm widget receives the setGterm command.  The calling sequence
+for setGterm callback is as follows:
+

+
+                   setgterm (client_data, gterm_widget)
+

+

+The purpose of this callback is to tell the client which gterm widget is
+the "active" gterm widget.  This is used by clients which only support
+one active Gterm widget, i.e., which can only direct graphics output to
+one Gterm widget at a time.
+

+The messages or commands that can be sent to the Gterm widget by GUI
+code follow.
+

+General commands:
+

+
+                   setGterm          # make widget the active Gterm
+

+                   activate
+                 deactivate
+                addCallback procedure-name callback-type
+                      reset
+                      flush
+

+               setCursorPos x y [raster]
+               getCursorPos x y
+              setCursorType cursortype
+                       bell
+

+

+Graphics drawing commands:
+

+
+                  setRaster raster
+         raster = getRaster [raster]
+

+                  setLogRes width height
+                  getLogRes width height
+                 setPhysRes width height
+                 getPhysRes width height
+                 setTextRes rows cols
+               setDataLevel level
+               setLineWidth width
+               setLineStyle style
+              setColorIndex index
+                setFillType filltype
+

+                clearScreen
+               drawPolyline vector
+             drawPolymarker vector
+                drawPolygon vector
+                 drawMarker x y xsize ysize type
+

+              drawAlphaText x y text
+           getAlphaTextSize string width height base
+                startDialog
+                  endDialog
+                eraseDialog
+             drawDialogText x y text
+          getDialogTextSize string width height base
+

+

+The coordinates used in the graphics drawing commands are logical
+coordinates as defined by setLogRes, in the coordinate system of the
+reference drawing raster as defined by setRaster.  The default reference
+raster is raster zero, the widget's window.  Vectors are specified as
+a list of points, e.g., { {x y} {x y} ... }.
+

+Imaging commands:
+

+
+              rasterInit
+            assignRaster raster drawable
+            createRaster raster type width height depth
+           destroyRaster raster
+    exists = queryRaster raster type width height depth
+     raster = nextRaster [raster]
+     nrasters = nRasters [nrasters]
+

+                setPixel raster x y value
+        value = getPixel raster x y
+             writePixels raster pixels encoding x1 y1 nx ny
+              readPixels raster pixels encoding x1 y1 nx ny
+           refreshPixels raster ct x1 y1 nx ny
+   pixmap = createPixmap src x y width height
+              copyPixmap pixmap dst x y width height
+

+ colormap = nextColormap [colormap]
+            freeColormap colormap
+           writeColormap colormap first nelem colors
+            readColormap colormap first nelem colors
+            loadColormap colormap offset scale
+

+            initMappings
+   mapping = nextMapping [mapping]
+             freeMapping mapping
+           enableMapping mapping
+          disableMapping mapping
+  active = activeMapping mapping
+          refreshMapping mapping
+

+   raster = selectRaster dras dt dx dy rt rx ry [map]
+              unmapPixel sx sy raster rx ry [rz]
+

+              copyRaster rop src  st sx sy snx sny  dst dt dx dy dnx dny
+              setMapping mapping rop
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+              getMapping mapping rop 
+                         src st sx sy snx sny  dst dt dx dy dnx dny
+

+                    flip mapping axis [axis...]
+

+

+Pixel arrays are long strings consisting either of a sequence of numeric
+pixel values separated by whitespace (space or newline), or a hex encoded
+sequence of bytes (2 hex digits per 8 bit pixel).  Colors are specified
+as a list of RGB triplets, e.g., { {R G B} {R G B} ... }.
+

+Refer to the documentation for the Gterm widget for a detailed description
+of rasters, mappings, and colormaps.
+

+Markers:
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+New markers may be created with createMarker.  Once created, a marker
+functions under the Object Manager as a named object of class "marker".
+Refer to the marker class for a description of the commands defined for
+a marker.
+

+gterm Actions List
+

+
+        ignore
+        graphics-input
+        graphics-context
+        crosshair
+        track-cursor
+        enter-window
+        leave-window
+        popup-menu     {not implemented}
+        reset
+        m_create
+

+

+Default translations for Gterm window.
+Omitted for now: Ctrl ~Meta : popup-menu(tekMenu)
+

+default Gterm Translations
+

+
+               [Btn1Down]:m_create()                   
+               [Btn2Down]:crosshair(on)                
+             [Btn2Motion]:crosshair(on)                
+                 [Btn2Up]:crosshair(off)               
+   ~Ctrl ~Meta [Btn3Down]:graphics-context()           
+            [EnterWindow]:enter-window()               
+            [LeaveWindow]:leave-window()               
+               [KeyPress]:graphics-input()             
+                 [Motion]:track-cursor()               
+

+

+

+
+
6.3.1 GTERM class commands

+

+
setGterm

+

+Set the active Gterm widget.  A UI can have more than one
+gterm widget, but due to restrictions on the client-server interface, it
+may be possible for only one to receive client output at any one time (any
+gterm widget can generate input to be sent to the client).  If the client
+has this restriction, the client-server interface code which uses OBM can
+call the ObmPostSetGtermCallback procedure to post a function to be called
+when the UI code calls the setGterm procedure.
+

+Usage:
+

+
+        setGterm
+

+

+
activate

+

+Activate the gterm widget.   This causes the next GIN mode
+setCursorType to warp the pointer into the gterm window.
+

+Usage:
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the gterm widget.   If the cursor has been warped
+into the window by a previous activate/setCursorType GIN mode, this causes
+the cursor to be warped back to where it was previously.
+

+Usage:
+

+
+        deactivate
+

+

+
reset

+

+Reset the gterm widget.  This causes a number of state variables
+affecting graphics drawing options to be set to their default values.
+

+Usage:
+

+
+        reset
+

+

+
flush

+

+Flush any graphics output and synchronize the state of the widget
+with what is shown on the display.
+

+Usage:
+

+
+        flush
+

+

+The gterm widget uses XLIB, which buffers graphics drawing commands and
+automatically sends them to the X server when 1) the buffer fills,
+2) input is requested from the server.  Such buffering of data is necessary
+for efficient operation and it should rarely be necessary to explicitly
+flush graphics output since XLIB does this automatically in most cases.
+An example of when explicitly flushing the ouptut might be necessary is in
+cases where smooth animation is desired and drawing the graphics in batches
+could cause the display to appear "jerky".
+

+
addCallback

+

+Post a callback for a Gterm widget event.
+

+Usage:
+

+
+        addCallback procedure-name [callback-type]
+

+

+The recognized Gterm callbacks are
+

+
+
+        input           Called when the graphics-input action is invoked in
+                        a translation table.  The default Gterm translation
+                        table invokes this action when a KeyPress event occurs
+                        in the Gterm window.
+                        Callback:        widget-name input-type event-data
+
+        resize          Called when the gterm window is resized.
+                        Callback:        widget-name width height
+
+        reset           Called when the "reset" action is invoked.
+                        Callback:        widget-name
+
+

+

+If no callback is specified the default is "input".
+

+Note that in GUI code one can also use the translation table to directly
+invoke GUI procedures without need to use the Gterm input mechanism.  This
+is more flexible but we support the Gterm input callback here for
+applications that use the default translations.
+

+
setCursorPos

+

+Warp the cursor (pointer) to the given coordinates.  This
+is a graphics drawing command and if no raster number is specified the
+current reference drawing raster, as set with setRaster, defines the
+coordinate system.
+

+Usage:
+

+
+        setCursorPos x y [raster]
+

+

+A raster number may optionally given to define the raster coordinate system
+to be used.  raster=0 yields screen coordinates.
+

+
getCursorPos

+

+Get the cursor position (raster 0 or screen coordinates).
+

+Usage:
+

+
+        getCursorPos x y
+

+

+
setCursorType

+

+Set the cursor type.
+

+Usage:
+

+
+        setCursorType cursor-type
+
+        idle        default cursor
+        busy        busy cursor, e.g, when program is busy
+        ginMode     graphics input mode cursor, set when program is
+                    waiting for graphics input
+

+

+
bell

+

+Gterm widget sound output.
+

+Usage:
+

+
+        bell
+

+

+
setRaster

+

+Set the number of the raster to be used to define the drawing
+context (e.g. coordinate system) for graphics and text drawing functions.
+

+Usage:
+

+
+        setRaster raster-number
+

+

+
getRaster

+

+Get the number of the raster which defines the drawing
+context, as set in the last setRaster call.
+

+Usage:
+

+
+        raster = getRaster [raster]
+

+

+If the name of a variable is given the raster number will be stored 
+directly in that variable.
+

+
clearScreen

+

+Clear the "screen", i.e., window.  This action clears the
+drawing window and sets a number of drawing state variables to their default
+values.
+

+Usage:
+

+
+        clearScreen
+

+

+
rasterInit

+

+Initialize the raster subsystem, deleting all rasters and
+mappings and freeing the dynamic part of the colortable.
+

+Usage:
+

+
+        rasterInit
+

+

+
writePixels

+

+Set the values of some subset of the pixels in a raster.
+If any mappings are defined on the affected region and are enabled, any
+destination rasters will be automatically updated as defined by the mapping.
+

+Usage:
+

+
+        writePixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster       The raster number.
+        pixels       The pixel array, encoded as a string.
+        encoding     The pixel encoding.  "numeric" means each pixel is
+                     encoded as a decimal integer delimited by whitespace.
+                     "hex" means the pixel array is hex encoded, 2 bytes
+                     per 8 bit pixel, as a printable text string.  The
+                     two bytes are defined as follows (v = pixel value):
+
+                          byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                          byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                     Whitespace in a hex encoded string is ignored.
+                     Hex encoding reduces the data volume by about a factor
+                     of two (compared to numeric) and is only a factor of
+                     two less space efficient than binary.
+
+        nbits        Number of bits per pixel - currently only 8 bit pixels
+                     are supported.
+
+        x1,y1,nx,ny  Region of the raster to be written.
+

+

+Most real-world image processing applications get the Gterm widget handle
+with setGterm and pass binary data to the widget by calling GtWritePixels
+directly.  This is the most efficient approach for serious image processing
+where large amounts of data are involved.  However, being able to read and
+write raster pixels directly in a GUI can be useful in specialized
+applications, e.g., where the image is computed or modified by the GUI.
+

+
setPixel

+

+Set the value of a single pixel.
+

+Usage:
+

+
+        setPixel raster x y value
+
+        raster   The raster number.
+        x, y     The pixel to be set.
+        value    The pixel value.
+

+

+This routine is more efficient than writePixels for setting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be set.
+

+
readPixels

+

+Get the values of some subset of the pixels in a raster.
+

+Usage:
+

+
+        readPixels raster pixels encoding nbits x1 y1 nx ny
+
+        raster        The raster number.
+        pixels        The pixel array, encoded as a string.
+        encoding      The pixel encoding.  "numeric" means each pixel is
+                      encoded as a decimal integer delimited by whitespace.
+                      "hex" means the pixel array is hex encoded, 2 bytes
+                      per 8 bit pixel, as a printable text string.  The
+                      two bytes are defined as follows (v = pixel value):
+
+                           byte1 = ((v >> 4) & 017) in hex [0-9A-F]
+                           byte2 = ((v     ) & 017) in hex [0-9A-F]
+                        
+                      Whitespace in a hex encoded string is ignored.
+                      Hex encoding reduces the data volume by about a factor
+                      of two (compared to numeric) and is only a factor of
+                      two less space efficient than binary.
+
+        nbits         Number of bits per pixel - currently only 8 bit pixels
+                      are supported.
+
+        x1,y1,nx,ny   Region of the raster to be read.
+

+

+Use readPixels to read a block of pixels, and getPixel to get the value
+of a single pixel.
+

+
getPixel

+

+Get the value of a single pixel.
+

+Usage:
+

+
+        getPixel raster x y
+
+        raster      The raster number.
+        x, y        The pixel to be set.
+

+

+This routine is more efficient than readPixels for getting the value of
+a single pixel, but is a lot less efficient if a block of pixels are to
+be read.
+

+
nextMapping

+

+Return the index of the next unused mapping.
+

+Usage:
+

+
+        nextMapping
+

+

+Returns the mapping number as the function value.
+

+
getMapping

+

+Get a mapping.
+

+Usage:
+

+
+        getMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters except the mapping number are output parameters.
+

+
setMapping

+

+Set a mapping.
+

+Usage:
+

+
+        setMapping mapping rop src st sx sy snx sny dst dt dx dy dnx dny
+

+

+All parameters are input parameters.
+

+
loadColormap

+

+Load a colormap.
+

+Usage:
+

+
+        loadColormap colormap [offset [scale]]
+

+

+The offset and scale parameters may be used to adjust the brightness and
+contrast of the image when the colormap is loaded.  The normalized colormap
+has offset=0.5, scale=1.0.  Colormap zero is the hardware colormap.
+

+
selectRaster

+

+Given the raw screen coordinates SX,SY (or coords in
+any destination raster), determine the mapping and source raster which are
+mapped to that pixel and return the raster and mapping numbers and the
+coordinates of the same pixel in the source raster.
+

+Usage:
+

+
+        raster = selectRaster dras dt dx dy rt rx ry [map]
+

+

+where
+

+
+		dras         display raster
+                dt,rt        coordinate type - "pixel" or "ndc"
+                dx,dy        display raster coordinates (input)
+                rx,ry        source raster coordinates (output)
+                map          mapping selected (output)
+

+

+Note that the coordinates returned by selectRaster are measured (taking
+a line as an example) from zero at the left edge of the first pixel, to 
+"width" at the right edge of the last pixel.  This means that the floating
+point coordinates of the center of raster pixel N will be N + 0.5.  For
+example, if we input screen coordinates (dras=0), x=117, and no mapping
+is in effect, the floating point raster coordinates returned will be 117.5.
+The difference occurs because the input coordinate is a pixel number 
+(integer) while the output coordinate is a floating point coordinate
+measuring the continuously variable location a pixel.  int(x) will convert
+this coordinate to a raster pixel number.
+

+
unmapPixel

+

+unmapPixel is a simplified, less general version of
+selectRaster which will automatically follow graphics pipelines back to
+the original mapped raster.  If desired the raster pixel value can be
+returned as well as the raster number and raster pixel coordinates
+corresponding to a screen (raster 0) pixel.
+

+Usage:
+

+
+        unmapPixel sx sy raster rx ry [rz]
+

+

+where
+

+
+		sx,sy        "screen" (raster 0) coordinates
+                raster       original mapped raster (output)
+                rx,ry        source raster coordinates (output)
+                rz           source raster pixel value (output)
+
+

+By following graphics pipelines back to the original source raster we mean
+the following.  If raster A is mapped to raster B which is mapped to C (the
+screen), given a screen coordinate in the mapped region unmapPixel will
+return the raster number and coordinates for raster A.
+

+
flip

+

+Edit a mapping to flip the mapped subimage in X and/or Y.
+

+Usage:
+

+
+        flip mapping axis [axis]
+

+

+where axis is "x" or "y".  This is a convenience routine for changing only
+the flip portion of a mapping.
+

+
markerInit

+

+Initialize the Marker subsystem for a Gterm widget.
+This destroys all markers and initializes the marker subsystem.
+

+Usage:
+

+
+        markerInit
+

+

+
createMarker

+

+Create a new marker.
+

+Usage:
+

+
+        createMarker name attribute-list
+  e.g.  createMarker name {attribute value [attribute value ...]}
+    or  createMarker name attribute value [attribute value ...]
+
+

+Any marker attribute may be assigned a value when the marker is created.
+Refer to <ObmW/Gterm.h> for a list of marker attribute names.  Often the
+the attributes "type" and "createMode" need to be specified at marker
+create time.
+

+
+        type            The marker type: text, rectangle, circle, etc.
+
+        createMode      A marker should be created with createMode=interactive
+                        if the user is expected to interactively drag out
+                        the marker using the pointer and either the default
+                        or an application specified translation table.  A
+                        marker can also be created interactively using only
+                        the m_create (marker create) action, however m_create
+                        does not allow the marker attributes to be set.
+
+

+There are any number of ways to use a GUI to create a marker under the
+Object Manager, but an example might be using a translation to call a GUI
+procedure which issues the createMarker call.  For example a pointer down
+event could translate as "call(newMarker,$name,$x,$y) m_create()" where
+newMarker is a GUI marker creation procedure which sends a createMarker
+message to the Gterm widget.  The GUI procedure could set the marker
+attributes as desired, possibly using additional GUI components to define
+the marker attributes.  The m_create action will notice that a
+createMarker has been executed and will merely activate the marker and
+give it the pointer focus (i.e. install the marker translations).  The
+user will then use the pointer or keyboard to drag out the marker.
+

+If the marker is created noninteractive the application must set the marker
+position and size using marker attributes.  If the marker is sensitive
+the user can then use the marker's translations to interactively modify
+the marker (resize it, move it, etc.).  All markers which are visible and
+sensitive and which have the necessary translations can be interactively
+modified by the user; the reason for creating a marker in interactive mode
+is to allow the initial marker position and size to be specified
+interactively *when* the marker is created, instead of afterwards.
+

+Any number of attributes may be given when the marker is created.  Most
+marker attributes can also be modified after a marker has been created
+by sending setAttribute messages to the marker.
+
+

+
+
+
6.4 HTML

+
+The HTML (hypertext markup language) widget displays a block of HTML
+formatted text, the "document" to be displayed.  The text consists of a
+mixture of text to be displayed and embedded formatting directives.  The
+text may also contain "hot links" pointing to other HTML-formatted
+documents.
+
+
+               setText text [target [header_text [footer_text]]]
+        text = getText [format [font]]
+         retestAnchors
+ 
+     id = positionToId x y
+          idToPosition id x y
+      anchorToPosition name x y
+       id = anchorToId name
+                gotoId id
+ 
+          n = getHRefs list
+      n = getImageSrcs list
+          n = getLinks list
+ 
+          setSelection start end
+   text = getSelection start end
+        clearSelection
+ 
+            searchText pattern start end [direction [search_type]]
+ 
+           addCallback procedure-name [callback-type]
+        deleteCallback procedure-name [callback-type]
+

+ 
+The possible callback types and their callback arguments are as follows.
+  
+
+       anchor          widget cbtype event text href element_id
+       testAnchor      widget cbtype href
+       submitForm      widget cbtype event attrs href method enctype encentity
+       link            widget cbtype href role
+       pointerMotion   widget cbtype href
+

+ 
+See the comments below for further details on the callback types and their
+arguments.
+
+

+
+
6.4.1 Command Summary

+

+
+

+
+
+
6.5 Markers

+

+A marker is a graphics object implemented by the Gterm-Image widget.
+Markers are not real toolkit widgets, but they act much like widgets and
+are interfaced as an object class under the Object Manager.  The Marker
+class is not a subclass, it is a base class like Widget, but Marker objects
+can exist only as children of Gterm widgets.
+

+Since markers are not independent widgets but rather part of a Gterm widget
+instance, the parent Gterm widget is partially responsible for managing
+markers.  The Gterm widget implements the following commands for dealing
+with markers.
+

+
+               createMarker name [attribute-list]
+                 markerInit
+

+

+A new marker is created by sending the createMarker message to the parent
+gterm widget.  This creates a marker of the given name and type.
+The markerInit command, if sent to a gterm widget, destroys any markers
+defined for that widget and reinitializes the marker facility.  Markers
+may also be created by action procedures in response to user input events.
+

+A marker may be destroyed by itself in response to an input event (e.g. the
+user presses the delete key), by sending the marker the destroy message
+to tell it to destroy itself, by sending a markerInit to the parent gterm
+widget, or by destroying the marker object (or any parent) with the server
+command destroyObject.
+

+Once a marker has been created it behaves as an independent object and
+receives and executes messages, responds to events, generates callbacks,
+and so on.  The marker class defines the following commands.
+

+
+                makeCopy name
+             addCallback procedure [event [event ...]]
+                  notify [event-type [param [param ...]]]
+                 destroy [nocallback]
+

+                 markpos
+                  redraw [function] [markpos|nomarkpos] [erase|noerase]
+

+                   raise [reference-marker]
+                   lower [reference-marker]
+

+                    move x y
+                  resize width height
+                  rotate angle                # radians
+

+                     set attribute value      # alias for setAttribute
+             value = get attribute            # alias for getAttribute
+

+            setAttribute attribute value
+    value = getAttribute attribute
+           setAttributes attribute-list
+           getAttributes attribute-list
+             setVertices points first npts
+             getVertices points first npts
+

+      region = getRegion [unmap] [coord-type]
+                 getRect dx dy dnx dny
+

+

+Marker positions and dimensions are given in window (raster 0) coordinates. 
+

+The operators raise, lower, move, resize, and rotate erase the marker,
+modify it as indicated, and redraw it with the new attributes.  For finer
+control over marker attributes one can use [get|set]Attribute[s] and
+[get|set]Vertices to edit the markers directly.  In this case an auto
+redraw is not performed (unless the autoRedraw marker attribute is set).
+The usual sequence is a markpos to record the marker position, one or more
+setAttribute calls to change marker attributes, then a redraw to erase
+the old marker and redraw the new one.  Markers have many attributes which
+can be set to control things like the position and size, colors, line
+widths, fill type and style, font, rubber-band technique, and so on.
+Refer to <ObmW/Gterm.h> for a list of marker types and attributes.
+

+The marker type may be changed at runtime without destroying the marker.
+For example a circle can be changed to an ellipse or a rectangle.  This
+also works for polygons (the vertex list is preserved and restored when
+the marker is changed back to a polygon).
+

+The current shape of a marker may be queried with getVertices, which
+returns the polygon or polyline vertex list in window coordinates.  A more
+powerful routine which does something similar is getRegion.  This routine
+returns a high level description of the region outlined by the marker,
+giving the marker type (rectangle, circle, ellipse etc.), center, width
+and height, and so on.  Any position or dimension information may
+optionally be transformed back to the original source raster, if the marker
+center is in a region of the window which is the destination of an active
+mapping.  The unmap option will follow multiple mappings back to the
+original mapped source raster.
+

+The getRect function returns the parameters of the region outlined by a
+rectangle marker in a form convenient for use in a Gterm setMapping call
+(this is used to display an image within a marker).
+

+Default translations when pointer is over a marker.
+default Marker Translations
+

+
+        Shift <Btn1Motion>    m_rotateResize()             
+              <Btn1Motion>    m_moveResize()               
+          Shift <Btn1Down>    m_raise()  m_markpos()       
+                <Btn1Down>    m_raise()  m_markposAdd()    
+                  <Btn1Up>    m_redraw() m_destroyNull()   
+                <Btn2Down>    m_lower()                    
+            <Key> BackSpace   m_deleteDestroy()            
+               <Key> Delete   m_deleteDestroy()            
+                <KeyPress>    m_input()                    
+                  <Motion>    track-cursor()               
+

+

+
+
6.5.1  Command Summary

+

+
makeCopy

+

+Copy a marker.  The new marker is initially identical to the
+old one, and will not be distinct until, e.g., moved to a new center.
+

+Usage:
+

+
+         makeCopy name
+

+

+
addCallback

+

+Post a marker callback to be called when the specified
+event or events occurs.  If no events are listed a Notify callback will
+be posted.
+

+Usage:
+

+
+	addCallback procedure [event [event ...]]
+

+

+
notify

+

+Generate a Marker pseudo-event, causing any posted client
+callback procedures to be called.
+

+Usage:
+

+
+        notify [event-type [param [param ...]]]
+

+

+
destroy

+

+Destroy a marker.  Just tell the marker to destroy itself.
+All cleanup outside the marker facility relies upon the use of callbacks.
+This includes our callback markerDestroyCallback below.
+

+Usage:
+

+
+        destroy
+

+

+
markpos

+

+Mark the current position of a marker for a later redraw.
+

+Usage:
+

+
+        markpos
+

+

+Markpos is used to mark the position of a marker before changing any
+marker attributes, so that a later "redraw marked" will erase the old
+marker rather than the new one.  This is necessary, for example, if any
+marker attributes are changed which affect the size or position of the
+marker.
+

+
redraw

+

+Redraw a marker.
+

+Usage:
+

+
+        redraw [function] [erase|noerase] [markpos|nomarkpos]
+

+

+By default redraw will erase the old marker at the position indicated by
+a previous call to markpos, and redraw the marker with the current
+attributes using the drawing function copy (copy source to destination).
+Hence the usual usage is "markpos ... change marker attributes ... redraw".
+Optional arguments may be given to change the drawing function, enable or
+disable erase, or force redraw to do a markpos.  These arguments may be
+given in any order.
+

+The drawing functions are as given in the XLIB documentation, minus the
+"GX" prefix.  The most commonly used functions are "copy" and "xor".
+A normal marker redraw uses function=copy.
+

+
raise

+

+Raise a marker, i.e., cause it to be drawn on top of other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        raise [reference-marker]
+

+

+In a reference marker is named the marker will raise itself above this
+marker, otherwise the raised marker becomes the topmost marker.
+

+
lower

+

+Lower a marker, i.e., cause it to be drawn beneath other
+markers when overlapping markers are drawn.
+

+Usage:
+

+
+        lower [reference-marker]
+

+

+In a reference marker is named the marker will lower itself beneath this
+marker, otherwise the lowered marker becomes the lowest marker.
+

+
move

+

+Move a marker.
+

+Usage:
+

+
+        move x y
+

+

+Move the marker center to the indicated coordinates in the display window.
+

+
resize

+

+Resize a marker.
+

+Usage:
+

+
+         resize width height
+

+

+Resize the marker to the indicated size.  By default width and height are
+given in pixels.  For a text marker one can append "ch" to indicate that
+the units are chars in whatever font is in use, e.g., "40ch" or "40 chars"
+is an acceptable value for a text marker dimension.
+

+
rotate

+

+Rotate a marker.
+

+Usage:
+

+
+         rotate angle
+

+

+Redraw a marker oriented to the given rotation angle.  The angle is
+given in radians.
+

+
getAttribute

+

+Return the value of a marker attribute.
+

+Usage:
+

+
+        value = getAttribute attribute-name
+

+

+
setAttribute

+

+Set the value of a marker attribute.
+

+Usage:
+

+
+        setAttribute attribute-name value
+

+

+
getAttributes

+

+Return the values of a list of marker attributes.
+

+Usage:
+

+
+          getAttributes attribute-list
+  i.e.    getAttributes {name value [name value ...]}
+    or    getAttributes name value [name value ...]
+

+

+where "value" is the name of the variable in which the attribute value 
+is to be stored.
+

+
setAttributes

+

+Set the values of a list of marker attributes.
+

+Usage:
+

+
+        setAttributes attribute-list
+  i.e.  setAttributes {name value [name value ...]}
+

+

+where "value" is the new value of the associated marker attribute.
+

+
getVertices

+

+Get some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        getVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is returned in the
+variable "points", as a string of the form { {x y} {x y} ...}.  The first
+point is number zero.
+

+
setVertices

+

+Set some or all of the vertices making up the polygon or
+polyline representation of a marker.
+

+Usage:
+

+
+        setVertices points [first npts]
+

+

+The polygon or polyline representation of a marker is set using the points
+passed in the "points" variable as a string of the form { {x y} {x y} ...}.
+If FIRST and NPTS are not specified first is assumed to be zero (the first
+point) and NPTS is the length of the points array.
+

+
getRegion

+

+Return as a text string a high level description of the
+region defined by a marker.
+

+Usage:
+

+
+        region = getRegion [unmap] [coord-type]
+

+

+The output string defines the marker type and the major marker positional
+attributes.  The region description formats for the various marker types
+follow.
+

+
+        text raster x y width height
+        line raster x y x y
+        polyline raster npts { {x y} {x y} ...}
+        rectangle raster x y width height rotangle
+        circle raster x y radius
+        ellipse raster x y width height rotangle
+        polygon raster npts { {x y} {x y} ...}
+

+

+Here, width and height refer to the distance from the marker center to an
+edge, not to the width or height of the whole marker.  This avoids
+ambiguities about where the edge of a marker is if the width is even or
+odd.  Using the center to edge measurement, the edge is at x +/- width,
+y +/- height.
+

+If the "unmap" flag is given getRegion will attempt to associate the
+marker with a mapped raster, reversing any mappings from the screen back
+to the original source raster, and returning the raster number and raster
+coordinates and marker sizes.  If "unmap" is not given the marker
+coordinates will refer to raster 0.  Either pixel ("pixel") or NDC
+("ndc") coordinates may be returned, pixel coordinates being the default.
+

+
getRect

+

+Return the region enclosed by a rectangle marker.  The rect is
+returned in a form convenient for use as the destination rect in a gterm
+widget raster mapping.
+

+Usage:
+

+
+        getRect dx dy dnx dny
+

+

+The rect is stored in the output arguments.
+

+
+

+
+
+
6.6 Widget

+

+The Widget class is the generic or base class for the window system
+toolkit widgets supported by the object manager.  The Widget class
+supports a number of different Xt widget classes using a table driven
+approach to describe each widget.  Any widget may be created, destroyed,
+and manipulated in various ways using only the generic Widget class
+procedures and Widget-specific resources.  The Widget class may be
+subclassed to support complex Widgets that require custom class-specific
+commands for use by the GUI code.
+

+Generic Widget-class commands:
+

+
+                 set <resource-name> <value>
+                 get <resource-name>
+

+         addCallback <procedure-name> []
+      deleteCallback <procedure-name>
+        setSensitive <sensitive>
+         isSensitive
+

+             realize
+           unrealize
+         isRealizeed
+                 map
+               unmap
+              manage child [child ...]
+            unmanage child [child ...]
+               popup [grab-kind]
+             popdown
+   popupSpringLoaded
+

+                move <x> <y>
+              resize <width> <height> <border-width>
+           configure <x> <y> <width> <height> <border-width>
+

+

+The most important Widget commands are set/get resource, and the
+callbacks.  The widget sensitivity can be set and queried using set/get
+resource, but special procedures are provided to make this common operation
+more convenient.
+

+Class specific functions:
+

+
+                 append text                         # text widget
+                setList list [resize]                # list widget
+        value = getItem itemno
+              highlight itemno
+            unhighlight
+

+

+Ideally the widget class should be subclassed for widgets that require
+class-specific functions, but in simple cases involving standard widgets
+the support is built into the widget class code as a special case.
+

+Special actions (used in translations):
+

+
+                call (proc [,arg, ...])
+               popup (menu-name [xoffset [yoffset]])
+             popdown (menu-name)
+

+

+The "call" action is a very general mechanism which allows any GUI procedure
+to be registered with any translation using the X translation table
+mechanism.  The popup and popdown actions are used for popup menus.  The
+menu will be popped up at the event coordinates plus the optional offsets
+if given.
+

+Event handling:
+

+
+     addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+Event callback:
+

+
+    userEventHandler widget event-type time wx wy rx ry other
+

+

+In most cases translations are preferable to events, but a GUI can capture
+raw events if it wishes by adding event handlers.  Nearly all of the X
+event types are supported.  The callback syntax employs a number of
+standard arguments, followed by a number of event-specific arguments.
+

+
addCallback

+

+Add a callback procedure to the callback list for
+a widget.  If no callback name is given, "callback" is assumed.
+

+Usage:
+

+
+        addCallback  [<callback-name>]
+

+

+Specific widgets only support certain types of callbacks.  There is no
+checking that the callback type specified is supported by a widget; the
+wrong type of callback can be registered, but it will never be called.
+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a widget.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
do_userproc (call)

+

+Translation action procedure used to call general user
+action procedures in the interpreter.  The name of the user procedure to
+be called is given as the first argument in the translation.  For example,
+the translation "call(foo,a,b,c)" would cause procedure foo to be called
+with the arguments (a,b,c).  The following arguments are special:
+

+
+        Argument        Replaced by
+

+        $name             object name of widget
+        $time             event->time
+        $x                event->x
+        $y                event->y
+        $x_root           event->x_root
+        $y_root           event->y_root
+

+

+The "user procedure" can be any server procedure.
+

+
do_popup

+

+Popup a menu (or other spring loaded popup) at the location
+of the event which triggered this action.
+

+Usage:
+

+
+        popup(menu-name [xoffset [yoffset]])
+

+

+
do_popdown

+

+Pop down a menu.
+

+Usage:
+

+
+        popdown(menu-name)
+

+

+
set

+

+Set a widget resource.
+

+Usage:
+

+
+        set <resource-name> <value>
+

+

+
get

+

+Get a widget resource value as a string.
+

+Usage:
+

+
+        get <resource-name>
+

+

+
append

+

+Append data to a text widget.
+

+Usage:
+

+
+        append <text>
+

+

+
setList

+

+Set the item list of a list widget.
+

+Usage:
+

+
+        setList list [resize]
+

+

+The list is a simple list of strings, passed as a single string argument to
+setList (quotes, braces, etc. may be used to quote strings containing
+special characters).
+

+
getItem

+

+Get an item in a list widget.
+

+Usage:
+

+
+        value = getItem itemno
+

+

+If ITEMNO is a number the indicated list item is returned, or the string
+"EOF" if the requested item is beyond the end of the list.  Otherwise the
+currently selected item is returned, and the index of the item is returned
+in the output variable ITEMNO.  If no item is currently selected ITEMNO
+will be set to "none" on output.
+

+
highlight

+

+Highlight an item in a list widget.
+

+Usage:
+

+
+        highlight itemno
+

+

+The indicated item of the list is highlighted as if the item had been
+selected by the user.  Any previously highlighted item is unhighlighted.
+

+
unhighlight

+

+Unhighlight the currently highlighted item in a
+list widget.
+

+Usage:
+

+
+        unhighlight
+

+

+Any currently highlighted item in the list widget is unhighlighted.
+

+
realize

+

+Realize a widget.  This activates and assigns windows for
+a widget and all of its descendants.  Realizing a widget does not in itself
+cause it to appear on the screen.
+

+Usage:
+

+
+        realize
+

+

+
unrealize

+

+Unrealize a widget.  This destroys the windows assigned
+to a widget and all of its descendants.
+

+Usage:
+

+
+        unrealize
+

+

+
isRealized

+

+Test whether a widget is realized.
+

+Usage:
+

+
+        isRealized
+

+

+
map

+

+Map a widget.
+

+Usage:
+

+
+        map
+

+

+
unmap

+

+Unmap a widget.
+

+Usage:
+

+
+        unmap
+

+

+
manage

+

+Manage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Managing the
+children makes them appear in the window, possibly causing the other
+children to be rearranged in the window.
+

+Usage:
+

+
+        manage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
unmanage

+

+Unmanage a list of child widgets.  These should share the
+same common parent, a geometry widget of some sort.  Unmanaging the
+children makes them disappear from the window and be removed from geometry
+management, possibly causing the other children to be rearranged in the
+window.
+

+Usage:
+

+
+        unmanage child [child ...]
+

+

+This message should be sent to the geometry widget which is the parent
+of the children.
+

+
popup

+

+Popup a shell widget.  If no grab is indicated the popup
+can remain up while other windows accept input.
+

+Usage:
+

+
+        popup [grab-kind]
+

+

+
popdown

+

+Popdown a shell widget.
+

+Usage:
+

+
+        popdown
+

+

+
popupSpringLoaded

+

+Popup a shell widget, e.g., a popup menu.
+This implies an exclusive grab.
+

+Usage:
+

+
+        popupSpringLoaded
+

+

+
move

+

+Move a widget to the given window relative coordinates.
+

+Usage:
+

+
+        move <x> <y>
+

+

+
resize

+

+Resize a widget.
+

+Usage:
+

+
+        resize <width> <height> <border-width>
+

+

+
configure

+

+Configure a widget, i.e., execute a simultaneous
+move and resize.
+

+Usage:
+

+
+        configure <x> <y> <width> <height> <border-width>
+

+

+
setSensitive

+

+Set the sensitivity of a widget.
+

+Usage:
+

+
+        setSensitive <sensitive>
+

+

+
isSensitive

+

+Test the sensitivity of a widget.
+

+Usage:
+

+
+        isSensitive
+

+

+
addEventHandler

+

+Add a custom event handler to a widget.  A list
+of event masks is given to define the classes of events the user supplied
+event handling procedure is to receive.
+

+Usage:
+

+
+        addEventHandler <procname> <event-mask> [<event-mask>...]
+

+

+
removeEventHandler

+

+Remove an event handler previously posted
+with addEventHandler, above.
+

+Usage:
+

+
+        removeEventHandler procname
+

+

+
event

+

+Generic event handler called when a widget event handler
+posted by addEventHandler is called.
+

+The user event handler is called as
+

+
+        userEventHandler widget event-type time wx wy rx ry other
+

+

+where "other" is an event-type specific list of fields describing the
+the event.
+

+
+
+
6.7 Parameter

+

+The UI parameter class is used for client-UI communications.  The client
+does not control the user interface directly, rather the UI defines a set
+of abstract UI parameters, and during execution the client application
+assigns values to these parameters.  These UI parameters should be thought
+of as describing the runtime state of the client as viewed by the GUI.
+The GUI is free to interpret this state information in any way, including
+ignoring it.  Many GUIs can be written which use the same client state
+as described by the UI parameters.
+

+Assigning a value to a UI parameter causes the new value to be stored, and
+any parameter action procedures registered by the UI to be called.
+The action or actions [if any] taken when a parameter value changes are
+arbitrary, e.g. the action might be something as simple as changing a
+displayed value of a UI widget, or something more complex like displaying
+a popup.
+

+
UI Parameter class commands:

+

+
+            getValue
+            setValue  <new-value>
+         addCallback  <procedure-name>
+      deleteCallback  <procedure-name>
+              notify
+

+

+The most common usage is for the GUI to post one or more callbacks for
+each UI parameter.  When the UI parameter value is changed [with setValue,
+e.g. by the client] the GUI callback procedures are called with the old
+and new UI parameter values on the command line.  addCallback is used to
+add a callback procedure, and deleteCallback to delete one.  Multiple
+callbacks may be registered for a single UI parameter.  notify is used
+to simulate a parameter value change, causing any callback procedures to
+be invoked.
+

+The callback procedure is called as follows:
+

+
+	user-procedure param-name {old-value} {new-value}
+

+

+The important thing to note here is that the old and new value strings
+are quoted with braces.  This prevents any interpretation of the string
+by Tcl when the callback is executed, which is necessary because the
+strings can contain arbitrary data.  When Tcl calls the callback the
+first level of braces will be stripped off, leaving old-value and new-value
+each as a single string argument.
+

+

+
setValue

+

+Set the value of a parameter, and notify all clients
+via the posted callback procedures that the parameter value has changed.
+

+Usage:
+

+
+        setValue <new-value>
+

+

+
getValue

+

+Get the value of a parameter.
+

+Usage:
+

+
+        getValue
+

+

+
notify

+

+Notify the registered clients of a parameter as if the
+value had changed.
+

+Usage:
+

+
+        notify
+

+

+
addCallback

+

+Add a callback procedure to the callback list for
+a parameter.
+

+Usage:
+

+
+        addCallback <procedure-name>
+

+

+
deleteCallback

+

+Delete a callback procedure previously registered
+for a parameter.
+

+Usage:
+

+
+        deleteCallback <procedure-name>
+

+

+
+

+
+
diff --git a/vendor/x11iraf/obm/docs/obm/servercom.html b/vendor/x11iraf/obm/docs/obm/servercom.html
new file mode 100644
index 00000000..16c4c24e
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/obm/servercom.html
@@ -0,0 +1,375 @@
+
serverReset

+

+The "reset-server" command is implemented as a special case in ServerEvaluate.
+After doing a true reset ServerEvaluate calls Tcl_Eval to evaluate the full
+message which still contains the reset-server command. We want to ignore
+this the second time, so we treat the command here as a no-op.
+

+Usage:
+

+
+        reset-server
+

+

+Note: for reset-server to be recognized by ServerEvaluate and really reset
+things, it must be the first command in a message to the server.
+

+
createObjects

+

+TCL command to create the tree of UI objects comprising the user interface.
+The object tree is defined by a string valued resource. If no resource is
+named the default "objects" resource will be used.
+

+Usage:
+

+
+        createObjects [resource-name]
+

+
destroyObject

+

+Destroy an object and all of its children.
+

+Usage:	
+
+        destroyObject object-name
+

+

+
activate

+Activate the user interface. When called the first time the user interface
+is created and activated, thereafter the UI is merely reactivated (e.g.
+mapped if unmapped).
+

+Usage:	
+

+
+        activate
+

+

+
deactivate

+

+Deactivate the user interface. Optionally unmaps the UI and calls the Obm
+client back to let it know that the UI has been deactivated.
+

+Usage:
+

+
+        deactivate [unmap]
+

+

+
getResource

+

+Get the string value of the specified application resource (window
+system parameter). This allows use of the resource mechanism to supply
+default values for GUI parameters.
+

+Usage:
+

+
+        value = getResource resource-name [class [default-value]]
+

+

+In the simplest case one merely requests a resource by name and the
+string value is returned as the function value. If the resource has
+an entry in the fallback resources for the application (appInitialize
+resource list) then a value is guaranteed to be returned.
+

+If the Class name for the resource is given then a class default value
+will be returned if no entry is found for the name resource instance. This
+is useful when there are a number of resources of the same type (same class).
+If most or all resources in the same class have the same default value one
+need only make one entry for the Class in the application defaults resource
+list. It is up to the application developer to define the class name of a
+resource - the class name can be any string. Examples are "Font", "Cursor",
+etc. By convention the first character of a class name is capitalized, while
+instance names begin with a lower case letter.
+

+If there is an entry for the named resource in the resource list passed to
+appInitialize then a value string is guaranteed to be returned. This will be
+either the appInitialize default, or a value specified by the system or the
+user in an X resources file. If one is not certain a default value is defined
+somewhere, a default value should be specified in the getResource call as
+shown above.
+

+See also getResources, used to get multiple resources in one call.
+

+
getResources

+

+Get the string values of a list of resources.
+

+Usage:
+

+
+        getResources resource-list
+

+

+e.g.
+
+        getResources {
+            { resource [variable class [default-value]]] }
+            { resource [variable class [default-value]]] }
+            (etc.)
+        }
+

+

+
createMenu, editMenu

+

+Create or modify a menu. The editMenu function is an alias for createMenu.
+

+Usage:
+
+        createMenu menu-name parent item-list
+

+

+e.g.,
+
+        createMenu menu-name parent {
+            { label function data [options...] }
+            { label function data [options...] }
+            (etc.)
+        }
+

+

+where
+

+
+        menu-name is the object name for the menu popup shell
+        parent    is the parent widget of the menu shell
+        label     is a menu item label
+        function  is the function to be performed when the menu
+        item      is selected, e.g., f.exec, f.data, f.space, or f.line.
+        data      is function dependent data
+        options   are option-name option-value pairs, as specified
+                  below.
+

+

+In the item list the fields label and option-value may be any Tcl expression.
+Expressions are evaluated in the server context. The data field is a Tcl
+script to be executed when the menu item is selected.
+

+Options are specified as "option option-value". The menu item options are
+as follows.
+

+
+        bitmap       A bitmap to be displayed left justified in the label field
+                     (e.g. to indicate a parameter setting).
+        sensitive    Specifies whether the menu item is active (sensitive=true)
+                     or inactive (sensitive=false, item grayed out).
+        accelerator  Specifies an input translation (accelerator, e.g.,
+                     keyboard event) which can be used to execute the
+                     menu item.
+

+

+The option-value field may be any Tcl expression.
+

+Example:
+

+
+        createMenu fileMenu toplevel {
+            { "File Menu" f.title}
+            { Open f.exec openFile}
+            { Save f.exec saveFile}
+            { Load f.menu loadMenu}
+            { no-label f.line }
+            { Quit f.exec "send client Quit" }
+        }
+

+

+The first createMenu is called for a given menu the menu is created, added
+to the menu list, and all window system widgets are created for the menu.
+Subsequent calls will result in only the changed parts of the menu being
+altered provided the changes are not great. Hence this routine can be called
+to efficiently modify a menu when minor runtime changes occur, e.g., an
+item label or action changes, the item value changes state, and so on,
+without need for the GUI code to know how to make the necessary detailed
+changes to the widgets used to implement the menu.
+

+
destroyMenu

+

+Destroy a menu. This can be used to free up the resources used by a
+menu, e.g., if the menu is not expected to be needed again for a while.
+

+Usage:
+

+
+        destroyMenu menu-name
+

+

+
createBitmap

+

+Create a named bitmap. This replaces any old bitmap of the same name. The
+new bitmap is cached in server memory; when a widget bitmap resource is set,
+the bitmap cache will be searched for the named bitmap before asking Xlib
+to find the bitmap.
+

+Usage:
+

+
+        createBitmap name width height data
+

+

+e.g., 
+

+
+        createBitmap foo 16 16 {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+
createCursor

+

+Create a cursor from bitmap data. The cursor is entered into the server's
+cursor cache and will override any existing entry of the same name.
+

+Usage:
+

+
+        createCursor name source mask fg_color bg_color x_hot y_hot
+

+

+e.g., 
+

+
+        createCursor foo bitmap1 bitmap2 black white 8 8
+

+

+The named bitmaps must be created first with createBitmap.
+

+
createPixmap

+

+Create a named pixmap. This replaces any old pixmap of the same name. The
+new pixmap is cached in server memory; when a widget pixmap resource is set,
+the pixmap cache will be searched for the named pixmap before asking Xlib
+to find the pixmap.
+

+Usage:
+

+
+        createPixmap name width height depth fg_color bg_color data
+

+

+e.g., 
+

+
+        createPixmap foo 16 16 8 black white {
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0x01,
+            0x60,0x03,0x20,0x02,0x60,0x03,0xc0,0x01,0x00,0x00,0x00,0x00,
+            0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }
+

+

+
print

+

+Print a string on the standard output. This is used mainly for debugging
+user interfaces.
+

+Usage:
+

+
+        print arg [arg ...]
+

+

+
send

+

+Send a message to an object. The object interprets the message and returns
+a function value as the string result of the TCL command.
+

+Usage
+

+
+        send <object> <message>
+

+

+
postActivateCallback

+

+Post a callback procedure to be called when the UI is activated. The UI is
+activated when it is first downloaded to server, but it may also be
+activated (reactivated) after the application has exited and is later
+restarted, or when the UI is deactivated and reactivated. Note 
+that the UI state vis-a-vis the external world (client application) may
+no longer be accurate after it has been idle for a time and then reactivated.
+

+Usage:
+

+
+        postActivateCallback <procedure>
+

+

+

+
postTimedCallback

+

+Post a callback to call the named procedure back after a specified delay
+in milliseconds.
+

+Usage:
+

+
+        id = postTimedCallback procedure msec [client-data]
+

+

+After the specified delay the user callback procedure will be called with
+client_data (if given) as the single argument. Only one call will be made;
+the client must repost the callback in each call if the procedure is to be
+repeatedly executed.
+

+An ID value is returned which may be passed to deleteTimedCallback to delete
+the timer.
+

+
deleteTimedCallback

+

+Delete a timer callback procedure. This procedure is typically used to
+break a timer loop, where the timer procedure repeatedly reposts itself at
+the end of each interval.
+

+Usage:
+

+
+        deleteTimedCallback id
+

+

+The ID string is returned by postTimedCallback when a timer is posted.
+

+
postWorkCallback

+

+Post a callback for a procedure to be called when the server is idle.
+Work procedures are used to perform computations in the background while
+the user interface remains active and able to respond to input events.
+This works only if the user work procedure does its job in small increments,
+doing only a small amount of processing in each call. The work procedure
+will be called repeatedly until it returns a status indicating that it has
+finished its task.
+

+Usage:
+

+
+        id = postWorkCallback procedure [client-data]
+

+

+When the server has nothing else to do the user work procedure will be
+called with client_data (if given) as the single argument. The work procedure
+should return the string "done" when all processing is finished, or any other
+string if the procedure is to be called again.
+

+An ID value is returned which may be passed to deleteWorkCallback to delete
+the work procedure.
+

+
deleteWorkCallback

+

+Delete a work callback procedure.
+

+Usage:
+

+
+        deleteWorkCallback id
+

+

+The ID string is returned by postWorkCallback when a work procedure is posted.
diff --git a/vendor/x11iraf/obm/docs/tody.paper/todyd.html b/vendor/x11iraf/obm/docs/tody.paper/todyd.html
new file mode 100644
index 00000000..53705df4
--- /dev/null
+++ b/vendor/x11iraf/obm/docs/tody.paper/todyd.html
@@ -0,0 +1,522 @@
+
+ A Portable GUI Development System---The IRAF Widget Server 
+
+

+
 Astronomical Data Analysis Software and Systems IV
ASP Conference Series, Vol. 77, 1995
Book Editors: R. A. Shaw, H. E. Payne, and J. J. E. Hayes
Electronic Editor: H. E. Payne 
 

+
 A Portable GUI Development System---The IRAF Widget Server

+

+
D. Tody

+National Optical Astronomy Observatories, P.O. Box 26732,
+Tucson, AZ 85726

+

+The National Optical Astronomy Observatories are
+operated by the Association of Universities for Research in Astronomy, Inc.
+(AURA) under cooperative agreement with the National Science Foundation.
+

+

+ 
+ 
+  
+ 
+    
+ 
+ 
+ 
Abstract:

+We describe a new GUI (Graphics User Interface) development environment
+which extends the X window system and the X Toolkit (Xt) with a high-level,
+object-oriented, interpreted programming language.  
+This approach will allow GUIs written 
+using standard Xt-based widget sets to be constructed without requiring any
+window system programming on the part of the programmer.
+The architecture of the resulting program completely separates the GUI from
+the applications code, allowing the GUI to be developed separately and
+replaced at will without modifying the application.
+Despite the separation of the GUI from the application the two are tightly
+integrated using an asynchronous, event-driven messaging system based on
+requests and client events, with the remote client application appearing as
+just another class of object within the GUI.
+This approach maximizes window system and toolkit independence and is well
+suited to distributed applications, allowing the GUI and client application
+to be run easily on separate processors or computers.
+

+

+
 Introduction

+

+Most window system programming today is done via one of two approaches.  The
+first approach is to code directly in C or C++ at the window system toolkit
+level, usually integrating the user interface code and applications code
+within the same program.  The second approach, which is really just a
+variation on the first, is to use one of the many commercial GUI builders
+available.  This simplifies the programmer's task by allowing the user
+interface to be interactively designed, relying on the GUI builder to
+generate the window system code required to implement the user interface
+specified by the programmer and requiring the programmer to code only the
+application functionality.  As with the direct coding approach, the
+applications code is often integrated with the GUI in the same program.
+

+Recently a third approach has been used.  This employs a high-level,
+interpreted language in which the programmer codes all or part of the
+application, with at least the GUI being implemented in the high-level
+interpreted language.  Tcl/Tk is a recent example of this approach.  Other
+examples of the high-level interpreted approach from outside the Unix/X
+world include Apple's HyperCard/HyperTalk, and the Visual Basic facility of
+Microsoft Windows.
+

+This paper presents a new, high-level, interpreted window system toolkit
+which like Tcl/Tk is also based on the Tcl interpreter.  Unlike Tcl/Tk,
+which is by definition Tk specific, our approach tries to maximize window
+system and window system toolkit independence to ease future upgrades to new
+window systems or toolkits.  The initial implementation, which is for the X
+Window System, is based on the X Toolkit (a part of the X Consortium X11
+release) and uses standard Xt-based widgets.  Support for an asynchronous,
+event-driven messaging system is an integral part of the design, allowing
+the GUI to be isolated from the functional part of an application and making
+the facility well suited to distributed applications, e.g., where a GUI
+executing locally talks to application code executing remotely, with the
+application downloading the GUI to be run at startup time.  The core
+facility is implemented as a simple C-callable library which can be used to
+implement new GUI-based programs without having to write any window 
+system-level code.
+

+An important aspect of the facility described in this paper is that it
+represents a general user interface management system (UIMS) tailored for
+astronomical GUIs.  The intent is that by providing a high-level facility
+tailored for our applications, we can simplify the task of developing GUIs
+for astronomical applications while providing a greater degree of
+consistency between applications since they will share the same GUI
+components.  This is particularly important in the area of 2D graphics and
+imaging, including presentation and user interaction with such data, since
+the standard toolkits do not address this area.
+

+
 The Widget Server

+

+
 Overview

+

+``Widgets'' (window objects), are the basic building blocks of graphical user
+interfaces.  A window system toolkit provides a selection of widgets that
+the programmer can use to construct a user interface.  Typical widgets
+include things like push buttons, scrollbars, pop-down menus, or scrolling
+text regions.  The  widget server serves up widgets to a remote client
+process in much the same way that the X display server serves up windows and
+other low-level display resources to a remote client application.
+

+When a client application starts up it connects to the widget server and
+downloads its GUI.  The GUI is a simple block of text which is interpreted
+and executed by the widget server.  The GUI text contains a description of
+the widgets comprising the user interface, a number of interpreted action
+procedures to be called to process user interface or client events during
+execution, and any code needed to initialize the GUI.
+During execution the client application waits for and executes requests from
+the GUI, and sends messages to the GUI to inform it of any ``client events,''
+or changes in the state of the client.  The conventional compiled client
+application implements all the application-specific functionality, but does
+not communicate directly with the user.
+

+To the client application the GUI is merely a block of text to be passed on
+to the widget server; the client code knows nothing about the GUI other than
+the name of the GUI file to be sent to the widget server.  The client knows
+only about the applications functionality which it implements, and the
+messages and requests used to communicate with the GUI.  The GUI is
+completely isolated from the client application.  While to the user the GUI
+appears to be an integral part of the application, the actual compiled
+client application has an interpreted command-line interface and can be
+executed stand-alone without any GUI.
+

+
 Widget Server Architecture

+

+
  
+
Figure: Widget Server Architecture.
+
+  Original PostScript figure (34 kB)
+

+
+

+

+

+The architecture of an application which uses the widget server is
+summarized in Figure 1.
+The typical widget server-based application consists of two processes, the
+process containing the client application, and the widget server process
+itself which executes the client's GUI.  All user interface functionality
+resides in the GUI and all application-specific functionality resides in
+the client.  During execution these processes communicate via an
+asynchronous object-based messaging system.
+

+
 Advantages of the Widget Server

+

+The widget server architecture separates the user interface from the
+application-specific code and provides a high-level interpreted language
+for developing GUIs.  This approach has significant advantages,
+including the following:
+

+
  1. 
+The high-level, interpreted nature of the widget server makes it much
+easier to develop GUIs than is the case with toolkit-level programming or
+the conventional, compile-link approach.
+
  2. 
+The use of an interpreted runtime language (Tcl) to compose the GUI is more
+powerful than the visual programming approach used in GUI builders, since
+the latter only address the appearance of the user interface.
+User interface builders can still be used with the widget server to
+interactively layout the user interface, although this is less important
+than it might be given the interpreted nature of the GUI (i.e., changes can be
+made and the GUI redisplayed very quickly).
+
  3. 
+The high-level, integrated nature of the widget server-based GUI development
+environment makes it straightforward to customize the environment to support
+a particular class of application.  This is important for large systems
+where GUIs are developed by many people working independently,
+to reduce the overall effort and improve consistency.
+
  4. 
+The widget server isolates all window system and toolkit code into a single
+executable which can serve any number of applications.  This greatly reduces
+disk space consumption in a large system that has many application GUIs.
+
  5. 
+Since the widget server is a single executable it is easy to have multiple
+versions, e.g., supporting different toolkits or incorporating proprietary
+software to optimize performance for a particular class of workstation.
+
  6. 
+Since all the window system code is isolated into a separate process the
+client application is completely window system independent, allowing the
+same client application to be used with a widget server GUI executing on
+any local or remote platform running any operating system.
+
  7. 
+Porting a whole system full of GUIs to a new platform can be done by a
+single individual since only the widget server itself need be ported.
+
  8. 
+No window system libraries, and indeed no compilation, is needed
+to develop GUIs.  All that is needed is the widget server executable.
+This makes it much more feasible to use commercial or platform specific
+libraries should this be desired.
+
  9. 
+The GUI is completely isolated into a small text file separate from the
+application, allowing the GUI and the application to be developed separately,
+or several alternate GUIs to be used with a single application.
+
  10. 
+The widget server is well suited to distributed applications since the
+widget server can be run on the local workstation while the client
+application executes remotely.  This allows the entire GUI to execute
+interactively on the local workstation, a much more efficient approach than,
+for example, running an X application over the network.
+

+

+Possible disadvantages of the widget server approach are its relative
+complexity and the possibility of inefficiency when the application is
+distributed over two or more processes.  For a small system where only a few
+GUI-based applications are needed many of our big-system concerns are
+unimportant and it might be simpler to program directly at the toolkit
+level, especially if a user interface builder tool is available.  Efficiency
+can be a problem if the client code is required to respond in real time to
+user interface events, however this is rarely a problem in well designed
+applications since the more interactive portions of the program can be moved
+into the GUI, implemented as interpreted GUI procedures or as calls to the
+compiled functions in the widget server itself.  The asynchronous nature of
+the messaging system ensures that the user interface will always be
+responsive even when the client is busy computing.
+

+
  
+
Figure 2: A Simple GUI: The ``Hello, world'' Application

+
 Platform Independence

+

+The widget server automatically provides a high degree of platform and
+window system independence since the GUI is isolated from the client
+application; in the worst case only the GUI file has to be changed to use a
+GUI-based application on a new platform.  The current implementation
+provides full platform independence for platforms which run the X Window
+System since the current widget server implementation is X-based.  No
+changes to the GUI files are needed for these platforms.
+

+The current widget server implementation does not, however, provide full
+window system toolkit independence for window systems other than X.  Ideally
+the widget server should define a virtual set of widgets which can be
+implemented on a variety of window systems and window system toolkits; not
+only X but also Windows, Windows NT, Macintosh, etc.  This problem has
+partially been solved in that the language used in widget server GUIs
+isolates the widget-dependent code into a portion of the GUI which describes
+the widget hierarchy, assigning widget classes to named GUI objects.  The
+runtime part of the GUI, i.e., the interpreted action or callback procedures
+called at runtime as the GUI executes, is already almost completely widget-
+and toolkit-independent.  Defining a fully toolkit-independent virtual
+widget set is a future problem which cannot be attempted until we have a
+better idea what widgets are needed for our applications.  Several
+commercial window system toolkits or GUI development environments exist
+which have already attempted to address this problem, at least for the
+standard toolkits.
+

+The portion of the widget server which interfaces to the underlying window
+system and window system toolkit (widget set) is the  Object Manager.
+This is discussed in the next section.
+

+
 The Object Manager Library

+

+
 Overview

+

+The widget server is actually just a shell around the Object Manager library
+(OBM).  The widget server extends the Object Manager by providing a way for
+external clients to connect to the Object Manager to download and execute a
+GUI.  All of the real work of creating and executing the GUI is done by the
+Object Manager library.  The widget server adds a client-server communications
+method.
+

+The Object Manager provides services for creating, deactivating,
+reactivating, or destroying a GUI, creating or destroying objects, and
+delivering messages and events to objects within the GUI.  The OBM provides
+the framework within which GUIs execute, including the interpreter,
+automatic memory allocation, and a library of runtime services.
+The Object Manager defines four main classes of objects:  Server,
+ Client,  Parameter (for client events), and  Widget, for
+the graphical elements of the interface.  Within the Widget class are many
+subclasses, one for each type of widget.
+All Object Manager execution is event driven and asynchronous and is based
+on messages (requests), callbacks, and events.  For example, defining a new
+GUI is done by sending a message to the server object.
+

+The set of widgets implemented by the Object Manager is not fixed, i.e., new
+widgets can be added or existing widgets removed to meet the requirements of
+the applications which will be using the widget server.  The base Widget
+class provides a generic set of methods usable with all widget subclasses.
+Complex widgets subclass the base Widget class to add their own methods.
+The current Object Manager provides a mixture of Xt-based widgets which
+provide a Motif-like appearance but which are publically available and
+redistributable.  Source for these widgets and for all code used in the
+widget server is included in the distribution.  The current widget set
+includes the base Xt widgets, the 3D Athena widgets, selected FWF (Free
+Widget Foundation) widgets, plus a few others such as the Layout widget from
+MIT, the HTML hypertext markup language widget from NCSA  Mosaic, and
+the gterm-image widget from the IRAF project.   Additional Xt-based widgets
+(including Motif, OLIT, and commercial widgets) can easily be added.
+

+
 The OBM Library

+

+The main entry points of the OBM library are shown in Figure 3.
+The library is very simple since everything complicated is done by the
+interpreted GUI code.  The main runtime function of the OBM library, from
+the point of view of the application which uses the library, is messaging.
+A window system application (such as the widget server) calls
+ ObmDeliverMsg to deliver a message from the client application to a
+GUI object.  A callback function is registered with the Object Manager to
+intercept client requests and pass them on to the client.
+

+
  
+
Figure 3: Principal routines of the Object Manager library,  libobm.a

+
 Using the OBM Library to Build Standalone Applications

+

+Our discussion has thus far concentrated on the widget server and
+distributed applications, because the widget server provides the best
+architecture for adding GUIs to tasks in an existing, large data processing
+system.  Another important class of applications are window system
+applications, where the focus is on the window system functionality
+implemented by the application.  Most conventional X window system
+applications fall into this class.
+

+An important use of the Object Manager library is to implement such
+applications.  A stand-alone, single-process window system application can be
+built using the OBM library.  In this case the ``client'' is not a separate
+process, but an application-specific interpreter within the same process as
+the OBM library.  The program could be written as a conventional window
+system program making direct calls to the underlying window system toolkit,
+but by using the OBM library virtually all window system specific code is
+eliminated and the GUI is isolated to a high-level, interpreted GUI file.
+The only compiled code required is that which implements the functionality
+of the application itself.  The resulting task is almost completely window
+system independent.
+

+A good example of an existing stand-alone window system task built around
+the OBM library is  ximtool, the IRAF image display server program.
+This is a stand-alone X window system application used for image display and
+image interaction.   Ximtool contains only about one page of C code
+which has anything to do with X.  All of the remaining C code handles window
+system-independent raster image processing and the fifo or socket-based
+binary protocol used to communicate with remote clients for image display.
+The  ximtool GUI is an interpreted GUI text file, identical to what
+one might use with a widget server-based task.  The widget server itself,
+of course, is another example of a stand-alone X application based on the
+OBM library.
+

+
 The Object Manager Shell

+

+Another stand-alone host application built around the Object Manager library
+is  obmsh, the Object Manager shell.  This is a Unix shell which executes
+OBM windowing scripts.  It can be used to execute GUI files from the Unix
+command line, or be used in OBM-based scripts to write stand-alone Unix
+shell scripts that can be called as commands from the Unix environment.
+For example, the ``hello, world'' GUI shown in Figure 2 could be
+converted to a Unix command  hello by changing the file name to ``hello''
+and adding something like ``SPM_quot#!/usr/local/bin/obmsh"'' to the file header.
+

+
 Messaging

+

+
 Messaging Fundamentals

+

+The key to isolating the GUI from the client code of an application, while
+providing a tightly integrated, efficient application, lies with messaging.
+The messaging scheme used determines how objects within the application
+interact with each other during execution.  This includes the interaction
+of the client code (client object) with the GUI.  Our discussion here will
+concentrate on how messaging is used to link the client to the GUI, but it
+should be noted that the same messaging scheme is used for all object-to-object
+communications within the GUI as well.
+

+Messaging as defined by the OBM consists of two parts: requests and
+client events.  Requests are commands send to the client (or any other
+object).  The recipient is free to modify or ignore the request as it wishes.
+Client events are messages sent to the GUI when the client state
+changes in any way.  The same mechanism is also used to deliver other forms
+of client information to the GUI, e.g., in response to requests.  The GUI is
+free to ignore client events.  It is not unusual for a given GUI to be
+interested in only a portion of the client events generated by a client.
+

+A client event is a message sent to an object of the OBM class  Parameter.
+A parameter object is very simple, consisting of a name and a string value.
+The GUI registers callbacks with the user interface (UI) parameters, i.e., 
+client events,
+that it wishes to know about.  The string value of a UI parameter can be
+anything, for example a number, a structure, a list, or a large block of text.
+It is common for multiple callbacks to be registered on a single UI parameter
+by independent elements of the GUI.
+

+Messaging is fully asynchronous.  Both requests and client events are queued
+and buffered, and periodically flushed to the process on the other end.
+Synchronization occurs automatically when the client waits for input from
+the server (GUI).  The GUI never waits for a request to complete, nor does
+it check to see that a request has been honored.  Rather, when the client
+processes the request it sends client events back to the GUI to inform the
+GUI of any actions performed by the client.  The same thing happens when
+the client performs actions for any other reason, hence the GUI always
+reflects the true state of the client.
+

+Client events are an important abstraction mechanism.  Client events and
+messages allow the client to provide the GUI with all the information it
+needs to function, without the client code having any knowledge of the
+nature of the user interface.  Yet, since requests and client events are
+decoupled, the client will function even if the client events and messages
+it sends are discarded, as when running the client code without a GUI or
+with radically different GUIs.
+

+
 Simple Messaging Example

+

+Messaging is one of those things which is fundamentally simple, yet
+surprisingly hard to explain.  As a simple example, consider what happens
+when the user selects a frame to be displayed in  ximtool:
+

+
  1. 
+The user pushes the next frame button.
+
  2. 
+The callback procedure (in the GUI) for the nextFrame button sends the
+command ``nextFrame'' to the client.
+
  3. 
+The client receives and processes the request, changing the frame,
+sending the new frame number to the UI parameter ``frame''.
+
  4. 
+A GUI callback procedure registered on the ``frame'' parameter is called,
+updating the GUI to indicate the new display frame number.
+

+

+This example simplifies things considerably but is accurate so far as it
+goes.  In the real program there are a number of different ways the frame
+can be changed, e.g., by the next frame or previous frame buttons, by menu
+selection, keyboard accelerators, the blink timer, IRAF running in another
+process, and so on.  All of these end up sending a request to the 
+ximtool client which directly or indirectly results in a frame change.
+When the display frame is changed a number of client events are generated to
+inform the GUI not only of the new frame number, but also the new frame
+title, zoom, pan, and frame flip values, type of enhancement used for the
+frame, and so on.  Each of these items represents a separate client event.
+Although the action of the program may be arbitrarily complex in real world
+examples, the basic messaging mechanism on which this is all based remains
+very simple.
+

+
 Software Products

+

+
 The X11IRAF Package

+

+All of the software described in this paper is packaged in a single
+distribution called  x11iraf.  This includes  xgterm,  ximtool,
+the Object Manager library, sources for all the third party widgets used in
+OBM, and assorted demo applications.  Everything needed to build the package
+is included, including compatible versions of some publically available
+libraries, e.g., Tcl and Xpm.  Despite the name the software is
+not tied to IRAF in any way, other than that it is a product of the IRAF
+project and is used for IRAF GUIs.
+

+
 Xgterm

+

+ Xgterm is an upwards compatible version of the popular  xterm
+with the  xterm graphics ripped out and replaced with an
+OBM-based GUI which uses the gterm-image widget for graphics.  The
+graphics supports a number of extensions, including full color support, an
+integrated imaging capability, dialog interaction, intelligent unconstrained
+resize, and a full crosshair cursor.  Although  xgterm is often used as
+a simple terminal emulator it is also a general widget server since it
+contains the full OBM library, and it can be used to execute
+arbitrarily complex OBM-based GUIs and manage the communications with the
+remote client.  The current version of  xgterm is based on the X11R6
+version of  xterm.
+

+
 Ximtool

+

+ Ximtool is an image display server, used by remote client applications
+such as IRAF to display and interact with images.  Several frames can be
+loaded and independently displayed in a full-frame or tiled configuration.
+Display frames can be any size.   Ximtool is a good example of a
+conventional single process windowing application which uses the OBM library
+for the GUI and the window system interface.
+

+
 The Object Manager Library

+

+The Object Manager library (OBM) is a high-level, interpreted window system
+toolkit that is used to implement arbitrary graphics user interfaces.  The OBM
+library uses Tcl as the interpreter.  The current version of the OBM
+library is based on the X toolkit and can be used with any Xt-based
+widget or widget set.
+

+
 The Gterm-Image Widget

+

+The gterm-image widget is an X Toolkit-based widget for general
+2D graphics and image display.  This is a complex widget and a full
+description of its capabilities is beyond the scope of this paper.  The
+Gterm widget provides a general GKS-like vector graphics and text display
+capability.  An integrated image display capability allows any number and
+size of image rasters to be created within the widget or in the X server.
+ Mappings can be defined to map one raster to another, permitting
+general graphics pipelines involving scaling and other geometric transforms
+to be set up.  Colormap support is included for grayscale and pseudocolor
+rendering of raster data.  An interactive  graphics marker facility is
+provided for interaction with the displayed graphic.  The Gterm widget is
+used for all graphics and imaging in  xgterm and  ximtool.
+

+
 Adding GUIs to IRAF Applications

+

+A major application of the widget server and the other software described
+in this paper is in adding GUIs to IRAF applications.  In this case the
+IRAF task is the client: when the IRAF task starts up it downloads its GUI
+to the widget server, and during execution the IRAF task and the GUI
+communicate via the messaging facility described earlier.  The changes
+required to add a GUI to an IRAF task are minor, ranging from
+changing a single line of code to cause the GUI file to be downloaded, to
+defining a set of client events and adding  gmsg calls to allow more
+complete integration of the GUI.  Adding a GUI to a task increases the
+system size by only the 10 Kb or so required for the GUI file.
+

+
 Availability and Further Information

+

+Further information on the software described in this paper, including
+more detailed documentation, full sources, and executables for a variety
+of platforms can be found in
+the X11IRAF Web page.
+Further information on IRAF itself and other IRAF products can be found in 
+