.bp
\&
.sp 1
.ce 3
\s+1\fBAppendix B\fP\s-1

\s+1\fBTranslation Table Syntax\fP\s-1
.sp 2
.LP
.XS
Appendix B \- Translation Table Syntax
.XE
.IN "Translation tables"
.SH
Notation
.LP
Syntax is specified in EBNF notation with the following conventions:
.TS
l l.
[ a ]	Means either nothing or ``a''
{ a }	Means zero or more occurrences of ``a''
.TE
.LP
All terminals are enclosed in double quotation masks (`` '').
Informal descriptions are enclosed in angle brackets (< >).
.SH
Syntax
.LP
The syntax of the translation table file is:
.TS
l l .
translationTable	= [ directive ] { production }
directive	= ( "#replace" | "#override" | "#augment" ) "\\\\n"
production	= lhs ":" rhs "\\\\n"
lhs	= ( event | keyseq ) { "," (event | keyseq) }
keyseq	= """ keychar {keychar} """
keychar	= [ "^" | "$" | "\\\\" ] <ISO Latin 1 character>
event	= [modifier_list] "<"event_type">" [ "(" count["+"] ")" ] {detail}
modifier_list	= ( ["!"] [":"] {modifier} ) | "None"
modifier	= ["~"] modifier_name
count	= ("1" | "2" | "3" | "4" | ...)
modifier_name	= "@" <keysym> | <see ModifierNames table below>
event_type	= <see Event Types table below>
detail	= <event specific details>
rhs	= { name "(" [params] ")" }
name	= namechar { namechar }
namechar	= { "a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-" }
params	= string {"," string}.
string	= quoted_string | unquoted_string
quoted_string	= """ {<Latin 1 character>} """
unquoted_string	= {<Latin 1 character except space, tab, ",", newline, ")">}
.TE
.LP
It is often convenient to include newlines in a translation table to make it
more readable.
In C, indicate a newline with a ``\\n'':
.LP
.Ds
.TA .5i 1.5i
.ta .5i 1.5i
	"<Btn1Down>:	DoSomething()\\n\\
	<Btn2Down>:	DoSomethingElse()"
.De
.SH
Modifier Names
.LP
The modifier field is used to specify normal X keyboard and button
modifier mask bits.
Modifiers are legal on event types 
.PN KeyPress ,
.PN KeyRelease , 
.PN ButtonPress ,
.PN ButtonRelease ,
.PN MotionNotify ,
.PN EnterNotify ,
.PN LeaveNotify ,
and their abbreviations.
An error is generated when a translation table 
that contains modifiers for any other events is parsed.
.IP \(bu 5
If the modifier_list has no entries and is not ``None'',
it means ``don't care'' on all modifiers.
.IP \(bu 5
If an exclamation point (!) is specified at the beginning 
of the modifier list,
it means that the listed modifiers must be in the correct state
and no other modifiers can be asserted.
.IP \(bu 5
If any modifiers are specified 
and an exclamation point (!) is not specified,
it means that the listed modifiers must be in the
correct state and ``don't care'' about any other modifiers.
.IP \(bu 5
If a modifier is preceded by a tilde (~),
it means that that modifier must not be asserted.
.IP \(bu 5
If ``None'' is specified, it means no modifiers can be asserted.
.IP \(bu 5
If a colon (:) is specified at the beginning of the modifier list,
it directs the \*(xI to apply any standard modifiers in the
event to map the event keycode into a keysym.
The default standard modifiers are Shift and Lock, 
with the interpretation as defined in 
\fIX Window System Protocol, X Version 11\fP.
The resulting keysym must exactly match the specified
keysym, and the nonstandard modifiers in the event must match the
modifier_list.
For example, ``:<Key>a'' is distinct from ``:<Key>A'', 
and ``:Shift<Key>A'' is distinct from ``:<Key>A''.
.IP \(bu 5
If both an exclamation point (!) and a colon (:) are specified at
the beginning of the modifier list, it means that the listed
modifiers must be in the correct state and that no other modifiers
except the standard modifiers can be asserted.  Any standard
modifiers in the event are applied as for colon (:) above.
.IP \(bu 5
If a colon (:) is not specified,
no standard modifiers are applied.
Then, for example, ``<Key>A'' and ``<Key>a'' are equivalent.
.LP
In key sequences,
a circumflex (^) is an abbreviation for the Control modifier,
a dollar sign ($) is an abbreviation for Meta, 
and a backslash (\\) can be used to quote any
character, in particular a double quote ("), a circumflex (^), 
a dollar sign ($), and another backslash (\\).
Briefly:
.LP
.Ds 0
.TA 2.5i
.ta 2.5i
No Modifiers:	None <event> detail
Any Modifiers:	<event> detail
Only these Modifiers:	! mod1 mod2 <event> detail
These modifiers and any others:	mod1 mod2 <event> detail
.LP
The use of ``None'' for a modifier_list is identical to the use
of and exclamation point with no modifers.
.De
.TS H
lw(1i) lw(1i) lw(3i).
_
.sp 6p
.TB
Modifier	Abbreviation	Meaning
.sp 6p
_
.sp 6p
.TH
.R
Ctrl	c	Control modifier bit
Shift	s	Shift modifier bit
Lock	l	Lock modifier bit
Meta	m	Meta key modifier (see below)
Hyper	h	Hyper key modifier (see below)
Super	su	Super key modifier (see below)
Alt	a	Alt key modifier (see below)
Mod1		Mod1 modifier bit
Mod2		Mod2 modifier bit
Mod3		Mod3 modifier bit
Mod4		Mod4 modifier bit
Mod5		Mod5 modifier bit
Button1		Button1 modifier bit
Button2		Button2 modifier bit
Button3		Button3 modifier bit
Button4		Button4 modifier bit
Button5		Button5 modifier bit
None		no modifiers
Any		Any modifier combination
.sp 6p
_
.TE
.LP
.IN "key modifier"
A key modifier is any modifier bit whose corresponding keycode contains the
corresponding left or right keysym.
For example, 
``m'' or ``Meta'' means any modifier bit mapping to a keycode 
whose keysym list contains XK_Meta_L or XK_Meta_R.
Note that this interpretation is for each display, 
not global or even for each application context.
The Control, Shift, and Lock modifier names refer
explicitly to the corresponding modifier bits; 
there is no additional interpretation of keysyms for these modifiers.
.LP
Because it is possible to associate arbitrary keysyms with modifiers, the set of
modifier key modifiers is extensible.  The "@" <keysym> syntax means any
modifier bit whose corresponding keycode contains the specified keysym.
.LP
A modifier_list/keysym combination in a translation matches a
modifiers/keycode combination in an event in the following:
.IP 1. 5
If a colon (:) is used, the \*(xI call the display's 
.PN XtKeyProc 
with the keycode and modifiers.
To match, (modifiers & ~modifiers_return) must equal modifier_list, and
keysym_return must equal the given keysym.
.IP 2. 5
If (:) is not used, the \*(xI mask off all don't-care bits from the 
modifiers.
This value must be equal to modifier_list.
Then, for each possible combination of
don't-care modifiers in the modifier_list, the \*(xI call the display's 
.PN XtKeyProc 
with the keycode and that combination ORed with the cared-about modifier bits 
from the event.
Keysym_return must match the keysym in the translation.
.SH
Event Types
.LP
The EventType field describes XEvent types.
In addition to the standard
Xlib symbolic event type names, the following event type synonyms
are defined:
.TS H
lw(1.5i) lw(3i).
_
.sp 6p
.TB
Type	Meaning
.sp 6p
_
.sp 6p
.TH
T{
Key
.br
KeyDown
T}	T{
.PN KeyPress
T}
KeyUp	T{
.PN KeyRelease
T}
BtnDown	T{
.PN ButtonPress
T}
BtnUp	T{
.PN ButtonRelease
T}
T{
Motion
.br
PtrMoved
.br
MouseMoved
T}	T{
.PN MotionNotify
T}
T{
Enter
.br
EnterWindow
T}	T{
.PN EnterNotify
T}
T{
Leave
.br
LeaveWindow
T}	T{
.PN LeaveNotify
T}
FocusIn	T{
.PN FocusIn
T}
FocusOut	T{
.PN FocusOut
T}
Keymap	T{
.PN KeymapNotify
T}
Expose	T{
.PN Expose
T}
GrExp	T{
.PN GraphicsExpose
T}
NoExp	T{
.PN NoExpose
T}
Visible	T{
.PN VisibilityNotify
T}
Create	T{
.PN CreateNotify
T}
Destroy	T{
.PN DestroyNotify
T}
Unmap	T{
.PN UnmapNotify
T}
Map	T{
.PN MapNotify
T}
MapReq	T{
.PN MapRequest
T}
Reparent	T{
.PN ReparentNotify
T}
Configure	T{
.PN ConfigureNotify
T}
ConfigureReq	T{
.PN ConfigureRequest
T}
Grav	T{
.PN GravityNotify
T}
ResReq	T{
.PN ResizeRequest
T}
Circ	T{
.PN CirculateNotify
T}
CircReq	T{
.PN CirculateRequest
T}
Prop	T{
.PN PropertyNotify
T}
SelClr	T{
.PN SelectionClear
T}
SelReq	T{
.PN SelectionRequest
T}
Select	T{
.PN SelectionNotify
T}
Clrmap	T{
.PN ColormapNotify
T}
Message	T{
.PN ClientMessage
T}
Mapping	T{
.PN MappingNotify
T}
.sp 6p
_
.TE
The supported abbreviations are:
.TS H
lw(1.5i) lw(3i).
_
.sp 6p
.TB
Abbreviation	Meaning
.sp 6p
_
.sp 6p
.TH
.R
Ctrl	T{
.PN KeyPress
with control modifier
T}
Meta	T{
.PN KeyPress
with meta modifier
T}
Shift	T{
.PN KeyPress
with shift modifier
T}
Btn1Down	T{
.PN ButtonPress
with Btn1 detail
T}
Btn1Up	T{
.PN ButtonRelease
with Btn1 detail
T}
Btn2Down	T{
.PN ButtonPress
with Btn2 detail
T}
Btn2Up	T{
.PN ButtonRelease
with Btn2 detail
T}
Btn3Down	T{
.PN ButtonPress
with Btn3 detail
T}
Btn3Up	T{
.PN ButtonRelease
with Btn3 detail
T}
Btn4Down	T{
.PN ButtonPress
with Btn4 detail
T}
Btn4Up	T{
.PN ButtonRelease
with Btn4 detail
T}
Btn5Down	T{
.PN ButtonPress
with Btn5 detail
T}
Btn5Up	T{
.PN ButtonRelease
with Btn5 detail
T}
BtnMotion	T{
.PN MotionNotify
with any button modifier
T}
Btn1Motion	T{
.PN MotionNotify
with Button1 modifier
T}
Btn2Motion	T{
.PN MotionNotify
with Button2 modifier
T}
Btn3Motion	T{
.PN MotionNotify
with Button3 modifier
T}
Btn4Motion	T{
.PN MotionNotify
with Button4 modifier
T}
Btn5Motion	T{
.PN MotionNotify
with Button5 modifier
T}
.sp 6p
_
.TE
.sp
.LP
The Detail field is event specific and normally corresponds to the
detail field of the corresponding event as described
by the X Protocol specification.  The detail field is supported
for the following event types:
.LP
.TS
l l .
_
.sp 6p
.TB
Event	Event Field
.sp 6p
_
.sp 6p
KeyPress	KeySym from event detail (keycode)
KeyRelease	KeySym from event detail (keycode)
ButtonPress	button from event detail
ButtonRelease	button from event detail
MotionNotify	event detail
EnterNotify	event mode (not detail)
LeaveNotify	event mode (not detail)
FocusIn	event mode (not detail)
FocusOut	event mode (not detail)
PropertyNotify	atom
SelectionClear	selection
SelectionRequest	selection
SelectionNotify	selection
ClientMessage	type
MappingNotify	request
.sp 6p
_
.TE
.LP
If the event type is
.PN KeyPress
or
.PN KeyRelease ,
the detail field
specifies a KeySym name in standard format which is matched against
the event as described above, for example, <Key>A.
.LP
For the
.PN PropertyNotify ,
.PN SelectionClear ,
.PN SelectionRequest ,
.PN SelectionNotify
and
.PN ClientMessage
events the detail field is specified
as an atom name; for example, <Message>WM_PROTOCOLS.  For the
.PN MotionNotify ,
.PN EnterNotify ,
.PN LeaveNotify ,
.PN FocusIn ,
.PN FocusOut
and
.PN MappingNotify
events either the symbolic constants as defined by the
X Protocol specification or the numeric values may be specified.
.LP
If no detail field is specified, then any value in the event detail is
accepted as a match.
.LP
A keysym can be specified as any of the standard keysym names, 
a hexadecimal number prefixed with ``0x'' or ``0X'', 
an octal number prefixed with ``0'' or a decimal number.
A keysym expressed as a single digit is interpreted as the
corresponding Latin 1 keysym, for example, ``0'' is the keysym XK_0.
Other single character keysyms are treated as literal constants from Latin 1,
for example, ``!'' is treated as 0x21.
Standard keysym names are as defined in 
.Pn < X11/keysymdef.h >
with the ``XK_'' prefix removed.
.LP
.SH
Canonical Representation
.LP
Every translation table has a unique, canonical text representation. This
representation is passed to a widget's
.PN display_accelerator
method to describe the accelerators installed on that widget.
The canonical representation of a translation table file is (see also
``Syntax''):
.TS
l l .
translationTable	= { production }
production	= lhs ":" rhs "\\\\n"
lhs	= event { "," event  }
event	= [modifier_list] "<"event_type">" [ "(" count["+"] ")" ] {detail}
modifier_list	= ["!"] [":"] {modifier}
modifier	= ["~"] modifier_name
count	= ("1" | "2" | "3" | "4" | ...)
modifier_name	= "@" <keysym> | <see canonical modifier names below>
event_type	= <see canonical event types below>
detail	= <event specific details>
rhs	= { name "(" [params] ")" }
name	= namechar { namechar }
namechar	= { "a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-" }
params	= string {"," string}.
string	= quoted_string
quoted_string	= """ {<Latin 1 character>} """
.TE
.LP
The canonical modifier names are:
.LP
.Ds
.TA 1i 2.5i
.ta 1i 2.5i
Ctrl	Button1
Shift	Button2
Lock	Button3
Mod1	Button4
Mod2	Button5
Mod3
Mod4
Mod5
.De
.LP
The canonical event types are:
.IP
.TS
l l.
T{
.PN KeyPress
T}	T{
.PN KeyRelease
T}
T{
.PN ButtonPress
T}	T{
.PN ButtonRelease
T}
T{
.PN MotionNotify
T}	T{
.PN EnterNotify
T}
T{
.PN LeaveNotify
T}	T{
.PN FocusIn
T}
T{
.PN FocusOut
T}	T{
.PN KeymapNotify
T}
T{
.PN Expose
T}	T{
.PN GraphicsExpose,
T}
T{
.PN NoExpose
T}	T{
.PN VisibilityNotify
T}
T{
.PN CreateNotify
T}	T{
.PN DestroyNotify
T}
T{
.PN UnmapNotify
T}	T{
.PN MapNotify
T}
T{
.PN MapRequest
T}	T{
.PN ReparentNotify
T}
T{
.PN ConfigureNotify
T}	T{
.PN ConfigureRequest
T}
T{
.PN GravityNotify
T}	T{
.PN ResizeRequest
T}
T{
.PN CirculateNotify
T}	T{
.PN CirculateRequest
T}
T{
.PN PropertyNotify
T}	T{
.PN SelectionClear
T}
T{
.PN SelectionRequest
T}	T{
.PN SelectionNotify
T}
T{
.PN ColormapNotify
T}	T{
.PN ClientMessage
T}
.TE
.LP
.SH
Examples
.LP
.IP \(bu 5
Always put more specific events in the table before more general ones:
.LP
.Ds
Shift <Btn1Down> : twas()\\n\\
<Btn1Down> : brillig()
.De
.LP
.IP \(bu 5
For double-click on Button 1 Up with Shift, use this specification:
.IP
.Ds
Shift<Btn1Up>(2) : and()
.DE
.IP
This is equivalent to the following line with appropriate timers set 
between events:
.IP
.Ds
Shift<Btn1Down>,Shift<Btn1Up>,Shift<Btn1Down>,Shift<Btn1Up> : and()
.De
.IP \(bu 5
For double-click on Button 1 Down with Shift, use this specification:
.IP
.Ds
Shift<Btn1Down>(2) : the()
.De
.IP
This is equivalent to the following line with appropriate timers set
between events:
.IP
.Ds
Shift<Btn1Down>,Shift<Btn1Up>,Shift<Btn1Down> : the()
.De
.IP \(bu 5
Mouse motion is always discarded when it occurs between events in a table
where no motion event is specified:
.IP
.Ds
<Btn1Down>,<Btn1Up> : slithy()
.De
.IP
This is taken, even if the pointer moves a bit between the down and
up events.
Similarly, any motion event specified in a translation matches any number
of motion events.
If the motion event causes an action procedure to be invoked,
the procedure is invoked after each motion event.
.IP \(bu 5
If an event sequence consists of a sequence of events that is also a
non-initial subsequence of another translation,
it is not taken if it occurs in the context of the longer sequence.
This occurs mostly in sequences like the following:
.IP
.Ds
<Btn1Down>,<Btn1Up> : toves()\\n\\
<Btn1Up> :  did()
.De
.IP
The second translation is taken only if the button release is not
preceded by a button press or if there are intervening events between the
press and the release.
Be particularly aware of this when using the repeat notation, above,
with buttons and keys
because their expansion includes additional events,
and when specifying motion events because they are implicitly included
between any two other events.
In particular,
pointer motion and double-click translations cannot coexist in the same
translation table.
.IP \(bu 5
For single click on Button 1 Up with Shift and Meta, use this specification:
.IP
.Ds
Shift Meta <Btn1Down>, Shift Meta<Btn1Up>: gyre()
.De
.IP \(bu 5
For multiple clicks greater or equal to a minimum number,
a plus sign (+) may be appended to the final (right-most)
count in an event sequence.  The actions will be invoked
on the count-th click and each subsequent one arriving
within the multi-click time interval.  For example:
.IP
.Ds
Shift <Btn1Up>(2+) : and()
.De
.IP \(bu 5
To indicate 
.PN EnterNotify 
with any modifiers, use this specification:
.IP
.Ds
<Enter> : gimble()
.De
.IP \(bu 5
To indicate 
.PN EnterNotify
with no modifiers, use this specification:
.IP
.Ds
None <Enter> : in()
.De
.IP \(bu 5
To indicate 
.PN EnterNotify 
with Button 1 Down and Button 2 Up and don't care about
the other modifiers, use this specification:
.IP
.Ds
Button1 ~Button2 <Enter> : the()
.De
.IP \(bu 5
To indicate 
.PN EnterNotify
with Button1 Down and Button2 Down exclusively, use this specification:
.IP
.Ds
! Button1 Button2 <Enter> : wabe()
.De
.IP
You do not need to use a tilde (~) with an exclamation point (!).
