strokes(5) [redhat man page]

STROKES(5)							File Formats Manual							STROKES(5)

NAME

       Strokes - X(1) action invocation with simple mouse movements

DESCRIPTION

       What are strokes?  Simply put, they are a method to invoke program actions with mouse drags.  They are defined by the following grid:

			   1 2 3
			   4 5 6
			   7 8 9

       Stroke  456  is	the horizontal movement from left to right with the stroke button pressed.  Holding down the stroke button and tracing out
       the letter `C' would be stroke 3214789.	Simple, right?

       The Stroke library allows you to add strokes to any X(1) program with one simple function call, StrokeInstall(3). For example:

		   W = XmCreateMessageDialog(Parent,
			"StrokeEnabledDialog",
			NULL, 0);
		   StrokeInstall(W);

       will enable strokes in the dialog W.

       When a stroke is entered the action corresponding to the stroke is called.  For the above example the action `Stroke-456' would	be  called
       when `456 is stroked'.

       In order to specify a different action you can specify this with the `strokes' resource for the Widget that the strokes have been installed
       in. So `*StrokeEnabledDialog.strokes: 456 ManagerGadgetSelect' would call the ManagerGadgetSelect action of the message dialog when 456	is
       stroked. The exact syntax is:

       Resource.strokes: stroke action [[,stroke action]...]

   Resources
       strokes: stroke action [[,stroke action]...]
	      This provides a mapping of strokes to actions.  By default the action `Stroke-456' is called for stroke `456'.

       strokeSlop: int
	      This  is	used  to  define  a buffer zone between the boxes of the grid.	The amount of slop tolerated is actually the resulting box
	      dimension divided by this slop number. Therefore the larger the slop number the  more  accurate  your  strokes  must  be.   A  value
	      approaching  3 will make it all but impossible to recognize a stroke.  The default value is currently 20.  Run the stroke(1) program
	      with StrokeDebug turned on to show what this means.

       strokeDebug: True | False
	      Turns on `stroke debug mode'.  In this mode the strokes are not erased from the screen when the button is released  and  a  grid	is
	      drawn around the stroke.	Try the stroke(1) program to see what I mean.

       strokeButton: 1 | 2 | 3 | 4 | 5
	      Specifies the button to be used to draw strokes. By default Btn3 is used.

       strokeSound: sound file
	      If  given,  the contents of this resource will be provided as an argument to the `PlaySound' action at the conclusion of the stroke.
	      If the PlaySound action is not defined in your application do not specify this resource.	Specifically the following call is made:

	      XtCallActionProc(W, "PlaySound", NULL, "sound file", 1);

AUTHOR

       Rick Scott <rwscott@alumni.uwaterloo.ca>
       Check out LessTif at http://www.LessTif.org

SEE ALSO

       stroke(1) StrokeInstall(3) StrokeRemove(3) StrokeSetButton(3) StrokeGetButton(3)  StrokeSetDebug(3)  StrokeGetDebug(3)  StrokeSetMapping(3)
       StrokeGetMapping(3)

																	STROKES(5)

XtInstallAccelerators() 												   XtInstallAccelerators()

Name
  XtInstallAccelerators - install a widget's accelerators on another widget.

Synopsis
  void XtInstallAccelerators(destination, source)
	 Widget destination;
	 Widget source;

Inputs
  destination
	    Specifies  the widget in which events specified in the accelerator table will be detected.	Must be of class Core or any subclass
	    thereof.

  source    Specifies the widget whose actions will be invoked when events occur in destination.  Must be  of  class  Core  or	any  subclass
	    thereof.

Description
  XtInstallAccelerators()  merges  the accelerator table of source into the translation table of destination.  After this call, events in the
  destination widget will trigger actions in the source widget.

  If the display_accelerator() method of source is non-NULL, XtInstallAccelerators() calls it with source and a canonical  representation  of
  the accelerator table that was installed.  This method is a hook that is intended to allow a widget to dynamically modify its appearance (a
  menu button might display the key sequence that will invoke it, for example) when an accelerator is installed.

Usage
  It is often convenient to be able to bind events in one widget to actions in another.  In particular, it is often  useful  to  be  able  to
  invoke menu actions from the keyboard.  The Intrinsics provide a facility, called accelerators, that let you accomplish this.  An accelera-
  tor table is a translation table that binds events in the destination widget to actions in the source widget.  The accelerator table can be
  installed  on  one or more destination widgets.  When an event sequence in destination would cause an accelerator action to be invoked, and
  if the source widget is sensitive, the actions are executed as though triggered by the same event sequence in source.  The event is  passed
  to the action procedure without modification.  The action procedures used within accelerators must assume neither that the source widget is
  realized, nor that any fields of the event are in reference to the source widget's window if the widget is realized.

  Every widget includes an XtNaccelerators resource, which is defined by the Core widget class.  The actual value of  this  resource  can  be
  hardcoded by the application or set in a resource file, just like any other resource.

  In  order for the XtNaccelerators resource to actually be used, however, the application must call XtInstallAccelerators() (or XtInstallAl-
  lAccelerators()).  This call takes two arguments.  The destination widget is the widget whose translation table will be augmented with  the
  accelerator table from the source widget.

  It  is  difficult to remember which of the two widgets in this call is which.  If you want to install a keyboard accelerator so that a key-
  stroke in a text widget invokes an action in a menu button, then the menu button is the source, and the text	widget	is  the  destination.
  You must set the accelerator table in the XtNaccelerators resource of the menu button, and then install those accelerators on the text wid-
  get.

  If you are programming with the Motif widget set, you will generally not be able to use accelerators as described here.  Motif  provides  a
  different (and incompatible) style of accelerators for use with menus; see Volume 6, Motif Programming Manual for more information.

Example
  Assume  an  application  whose  top-level shell widget is named topLevel, and which contains a Command widget instance named quit.  Further
  assume that the quit widget has the following XtNaccelerators resource defined for it:

	*quit.accelerators:	 <KeyPress>q: notify()

  The call:

	XtInstallAccelerators (topLevel, quit);

  would allow a "q" typed in the application's top-level window to invoke the quit widget's notify action.  The  notify  action  invokes  the
  callback list of the button, and assuming that a quit callback was registered, causes the application to terminate.

See Also
  XtInstallAllAccelerators(1),
  display_accelerator(4).

Xt - Translations and Actions												   XtInstallAccelerators()