diff options
Diffstat (limited to 'libX11/specs/XKB/glossary.xml')
| -rw-r--r-- | libX11/specs/XKB/glossary.xml | 1016 |
1 files changed, 1016 insertions, 0 deletions
diff --git a/libX11/specs/XKB/glossary.xml b/libX11/specs/XKB/glossary.xml new file mode 100644 index 000000000..0cccf0f8f --- /dev/null +++ b/libX11/specs/XKB/glossary.xml @@ -0,0 +1,1016 @@ +<glossary id='glossary'> +<title>Glossary</title> +<glossentry> + <glossterm>Allocator</glossterm> + <glossdef> + <para> +Xkb provides functions, known as allocators, to create and initialize Xkb data +structures. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Audible Bell</glossterm> + <glossdef> + <para> +An audible bell is the sound generated by whatever bell is associated with the +keyboard or input extension device, as opposed to any other audible sound +generated elsewhere in the system. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Autoreset Controls</glossterm> + <glossdef> + <para> +The autoreset controls configure the boolean controls to automatically be +enabled or disabled at the time a program exits. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Base Group</glossterm> + <glossdef> + <para> +The group in effect as a result of all actions other than a previous lock or +latch request; the base group is transient. For example, the user pressing and +holding a group shift key that shifts to Group2 would result in the base group +being group 2 at that point in time. Initially, base group is always Group1. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Base Modifiers</glossterm> + <glossdef> + <para> +Modifiers that are turned on as a result of some actions other than previous +lock or latch requests; base modifiers are transient. For example, the user +pressing and holding a key bound to the Shift modifier would result in Shift +being a base modifier at that point in time. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Base Event Code</glossterm> + <glossdef> + <para> +A number assigned by the X server at run time that is assigned to the extension +to identify events from that extension. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Base State</glossterm> + <glossdef> + <para> +The base group and base modifiers represent keys that are physically or +logically down; these constitute the base state. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Boolean Controls</glossterm> + <glossdef> + <para> +Global keyboard controls that may be selectively enabled and disabled under +program control and that may be automatically set to an on or off condition +upon client program exit. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Canonical Key Types</glossterm> + <glossdef> + <para> +The canonical key types are predefined key types that describe the types of +keys available on most keyboards. The definitions for the canonical key types +are held in the first <emphasis> +XkbNumRequiredTypes</emphasis> + entries of the <emphasis> +types</emphasis> + field of the client map and are indexed using the following constants: + </para> + <itemizedlist> + <listitem> + <para> +<emphasis>XkbOneLevelIndex</emphasis> + </para> + </listitem> + <listitem> + <para> +<emphasis>XkbTwoLevelIndex</emphasis> + </para> + </listitem> + <listitem> + <para> +<emphasis>XkbAlphabeticIndex</emphasis> + </para> + </listitem> + <listitem> + <para> +<emphasis>XkbKeypadIndex</emphasis> + </para> + </listitem> + </itemizedlist> + </glossdef> +</glossentry> + +<glossentry> + <glossterm>Client Map</glossterm> + <glossdef> + <para> +The key mapping information needed to convert arbitrary keycodes to symbols. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Compat Name</glossterm> + <glossdef> + <para> +The <emphasis> +compat</emphasis> + name is a string that provides some information about the rules used to bind +actions to keys that are changed using core protocol requests. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Compatibility State</glossterm> + <glossdef> + <para> +When an Xkb-extended X server connects to an Xkb-unaware client, the +compatibility state remaps the keyboard group into a core modifier whenever +possible. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Compatibility Grab State</glossterm> + <glossdef> + <para> +The grab state that results from applying the compatibility map to the Xkb grab +state. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Compatibility Map</glossterm> + <glossdef> + <para> +The definition of how to map core protocol keyboard state to Xkb keyboard state. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Component Expression</glossterm> + <glossdef> + <para> +An expression used to describe server keyboard database components to be +loaded. It describes the order in which the components should be loaded and the +rules by which duplicate attributes should be resolved. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Compose Processing</glossterm> + <glossdef> + <para> +The process of mapping a series of keysyms to a string is known as compose +processing. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Consumed Modifier</glossterm> + <glossdef> + <para> +Xkb normally consumes modifiers in determining the appropriate symbol for an +event, that is, the modifiers are not considered during any of the later stages +of event processing. For those rare occasions when a modifier <emphasis> +should</emphasis> + be considered despite having been used to look up a symbol, key types include +an optional <emphasis> +preserve</emphasis> + field. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Core Event</glossterm> + <glossdef> + <para> +An event created from the core X server. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Detectable Auto-Repeat</glossterm> + <glossdef> + <para> +Detectable auto-repeat allows a client to detect an auto-repeating key. If a +client requests and the server supports detectable auto-repeat, Xkb generates +<emphasis> +KeyRelease</emphasis> + events only when the key is physically released. Thus the client receives a +number of <emphasis> +KeyPress</emphasis> + events for that key without intervening <emphasis> +KeyRelease</emphasis> + events until the key is finally released, when a <emphasis> +KeyRelease</emphasis> + event is received. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Effective Group</glossterm> + <glossdef> + <para> +The effective group is the arithmetic sum of the locked, latched, and base +groups. The effective keyboard group is always brought back into range +depending on the value of the <emphasis> +GroupsWrap</emphasis> + control for the keyboard. If an event occurs with an effective group that is +legal for the keyboard as a whole, but not for the key in question, the group +<emphasis> +for that event only</emphasis> + is normalized using the algorithm specified by the <emphasis> +group_info</emphasis> + member of the key symbol map (<emphasis> +XkbSymMapRec</emphasis> +). + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Effective Mask</glossterm> + <glossdef> + <para> +An Xkb modifier definition consists of a set of bit masks corresponding to the +eight real modifiers; a similar set of bitmasks corresponding to the 16 named +virtual modifiers; and an effective mask. The effective mask represents the set +of all real modifiers that can logically be set either by setting any of the +real modifiers or by setting any of the virtual modifiers in the definition. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Effective Modifier</glossterm> + <glossdef> + <para> +The effective modifiers are the bitwise union of the base, latched and locked +modifiers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Extension Device</glossterm> + <glossdef> + <para> +Any keyboard or other input device recognized by the X input extension. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Global Keyboard Controls</glossterm> + <glossdef> + <para> +Controls that affect the way Xkb generates key events. The controls affect all +keys, as opposed to per-key controls that are for a single key. Global controls +include + </para> + <itemizedlist> + <listitem> + <para>RepeatKeys Control</para> + </listitem> + <listitem> + <para>DetectableAuto-repeat</para> + </listitem> + <listitem> + <para>SlowKeys</para> + </listitem> + <listitem> + <para>BounceKeys</para> + </listitem> + <listitem> + <para>StickyKeys</para> + </listitem> + <listitem> + <para>MouseKeys</para> + </listitem> + <listitem> + <para>MouseKeysAccel</para> + </listitem> + <listitem> + <para>AccessXKeys</para> + </listitem> + <listitem> + <para>AccessXTimeout</para> + </listitem> + <listitem> + <para>AccessXFeedback</para> + </listitem> + <listitem> + <para>Overlay1</para> + </listitem> + <listitem> + <para>Overlay2</para> + </listitem> + <listitem> + <para>EnabledControls</para> + </listitem> + </itemizedlist> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Grab State</glossterm> + <glossdef> + <para> +The grab state is the state used when matching events to passive grabs. It +consists of the grab group and the grab modifiers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Group</glossterm> + <glossdef> + <para>See Keysym Group</para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Group Index</glossterm> + <glossdef> + <para> +A number used as the internal representation for a group number. Group1 through +Group 4 have indices of 0 through 3. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Groups Wrap Control</glossterm> + <glossdef> + <para> +If a group index exceeds the maximum number of groups permitted for the +specified keyboard, it is wrapped or truncated back into range as specified by +the global <emphasis>GroupsWrap</emphasis> control. <emphasis> +GroupsWrap</emphasis> can have the following values: + </para> + <literallayout> + <emphasis>WrapIntoRange</emphasis> + <emphasis>ClampIntoRange</emphasis> + <emphasis>RedirectIntoRange</emphasis> + </literallayout> + </glossdef> +</glossentry> + +<glossentry> + <glossterm>Key Type</glossterm> + <glossdef> + <para> +An attribute of a key that identifies which modifiers affect the shift level of +a key and the number of groups on the key. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Key Width</glossterm> + <glossdef> + <para> +The maximum number of shift levels in any group for the key type associated +with a key. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keysym Group</glossterm> + <glossdef> + <para> +A keysym group is a logical state of the keyboard providing access to a +collection of characters. A group usually contains a set of characters that +logically belong together and that may be arranged on several shift levels +within that group. For example, Group1 could be the English alphabet, and +Group2 could be Greek. Xkb supports up to four different groups for an input +device or keyboard. Groups are in the range 1-4 (Group1 - Group4), and are +often referred to as G1 - G4 and indexed as 0 - 3. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Indicator</glossterm> + <glossdef> + <para> +An indicator is a feedback mechanism such as an LED on an input device. Using +Xkb, a client application can determine the names of the various indicators, +determine and control the way that the individual indicators should be updated +to reflect keyboard changes, and determine which of the 32 keyboard indicators +reported by the protocol are actually present on the keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Indicator Feedback</glossterm> + <glossdef> + <para> +An indicator feedback describes the state of a bank of up to 32 lights. It has +a mask where each bit corresponds to a light and an associated value mask that +specifies which lights are on or off. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Indicator Map</glossterm> + <glossdef> + <para> +An indicator has its own set of attributes that specify whether clients can +explicitly set its state and whether it tracks the keyboard state. The +indicator map is the collection of these attributes for each indicator and is +held in the <emphasis> +maps</emphasis> + array, which is an array of <emphasis> +XkbIndicatorRec</emphasis> + structures. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Input Extension</glossterm> + <glossdef> + <para> +An extension to the core X protocol that allows an X server to support multiple +keyboards, as well as other input devices, in addition to the core X keyboard +and pointer. Other types of devices supported by the input extension include, +but are not limited to: mice, tablets, touchscreens, barcode readers, button +boxes, trackballs, identifier devices, data gloves, and eye trackers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Key Action</glossterm> + <glossdef> + <para> +A key action consists of an operator and some optional data. Once the server +has applied the global controls and per-key behavior and has decided to process +a key event, it applies key actions to determine the effects of the key on the +internal state of the server. Xkb supports actions that do the following: + </para> + <itemizedlist> + <listitem> + <para> +Change base, latched, or locked modifiers or group + </para> + </listitem> + <listitem> + <para> +Move the core pointer or simulate core pointer button events + </para> + </listitem> + <listitem> + <para> +Change most aspects of keyboard behavior + </para> + </listitem> + <listitem> + <para> +Terminate or suspend the server + </para> + </listitem> + <listitem> + <para> +Send a message to interested clients + </para> + </listitem> + <listitem> + <para> +Simulate events on other keys + </para> + </listitem> + </itemizedlist> + </glossdef> +</glossentry> + +<glossentry> + <glossterm>Key Alias</glossterm> + <glossdef> + <para> +A key alias is a symbolic name for a specific physical key. Key aliases allow +the keyboard layout designer to assign multiple key names to a single key. This +allows the keyboard layout designer to refer to keys using either their +position or their "function." Key aliases can be specified both in the symbolic +names component and in the keyboard geometry. Both sets of aliases are always +valid, but key alias definitions in the keyboard geometry have priority; if +both symbolic names and geometry include aliases, you should consider the +definitions from the geometry before considering the definitions from the +symbolic names section. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Key Behavior</glossterm> + <glossdef> + <para> +The <emphasis> +behaviors</emphasis> + field of the server map is an array of <emphasis> +XkbBehavior</emphasis> +, indexed by keycode, and contains the behavior for each key. The X server uses +key behavior to determine whether to process or filter out any given key event; +key behavior is independent of keyboard modifier or group state. Each key has +exactly one behavior. + </para> + <para>Key behaviors include:</para> + <itemizedlist> + <listitem> + <para>XkbKB_Default</para> + </listitem> + <listitem> + <para>XkbKB_Lock</para> + </listitem> + <listitem> + <para>XkbKB_RadioGroup</para> + </listitem> + <listitem> + <para>XkbKB_Overlay1</para> + </listitem> + <listitem> + <para>XkbKB_Overlay2</para> + </listitem> + </itemizedlist> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Key Symbol Map</glossterm> + <glossdef> + <para> +A key symbol map describes the symbols bound to a key and the rules to be used +to interpret those symbols. It is an array of <emphasis> +XkbSymMapRec</emphasis> + structures indexed by keycode. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Key Type</glossterm> + <glossdef> + <para> +Key types are used to determine the shift level of a key given the current +state of the keyboard. There is one key type for each group for a key. Key +types are defined using the <emphasis> +XkbKeyTypeRec</emphasis> + and <emphasis> +XkbKTMapEntryRec</emphasis> + structures. Xkb allows up to <emphasis> +XkbMaxKeyTypes</emphasis> + (255) key types to be defined, but requires at least <emphasis> +XkbNumRequiredTypes</emphasis> + (4) predefined types to be in a key map. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard Bells</glossterm> + <glossdef> + <para> +The sound the default bell makes when rung is the system bell or the default +keyboard bell. Some input devices may have more than one bell, identified by +<emphasis>bell_class</emphasis> and <emphasis>bell_id</emphasis>. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard Components</glossterm> + <glossdef> + <para> +There are five types of components stored in the X server database of keyboard +components. They correspond to the <emphasis> +symbols, geometry, keycodes, compat, </emphasis> +and<emphasis> + types</emphasis> + symbolic names associated with a keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard Feedback</glossterm> + <glossdef> + <para> +A keyboard feedback includes the following: + </para> +<literallayout> + Keyclick volume + Bell volume + Bell pitch + Bell duration + Global auto-repeat + Per key auto-repeat + 32 LEDs +</literallayout> + </glossdef> +</glossentry> + +<glossentry> + <glossterm>Key Width, Key Type Width</glossterm> + <glossdef> + <para> +The maximum number of shift levels for a type is referred to as the width of a +key type. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard Geometry</glossterm> + <glossdef> + <para> +Keyboard geometry describes the physical appearance of the keyboard, including +the shape, location, and color of all keyboard keys or other visible keyboard +components such as indicators and is stored in a <emphasis> +XkbGeometryRec</emphasis> + structure. The information contained in a keyboard geometry is sufficient to +allow a client program to draw an accurate two-dimensional image of the +keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard Geometry Name</glossterm> + <glossdef> + <para> +The keyboard geometry name describes the physical location, size, and shape of +the various keys on the keyboard and is part of the <emphasis> +XkbNamesRec</emphasis> + structure. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keyboard State</glossterm> + <glossdef> + <para> +Keyboard state encompasses all of the transitory information necessary to map a +physical key press or release to an appropriate event. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keycode</glossterm> + <glossdef> + <para> +A numeric value returned to the X server when a key on a keyboard is pressed or +released, indicating which key is being modulated. Keycode numbers are in the +range 1 <= keycode <= max, where max is the number of physical keys on +the device. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Keycode Name</glossterm> + <glossdef> + <para> +The keycode name describes the range and meaning of the keycodes returned by +the keyboard and is part of the <emphasis> +XkbNamesRec</emphasis> + structure. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Latched Group</glossterm> + <glossdef> + <para> +A latched group is a group index that is combined with the base and locked +group to form the effective group. It applies only to the next key event that +does not change the keyboard state. The latched group can be changed by +keyboard activity or via Xkb extension library functions. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Latched Modifier</glossterm> + <glossdef> + <para> +Latched modifiers are the set of modifiers that are combined with the base +modifiers and the locked modifiers to form the effective modifiers. It applies +only to the next key event that does not change the keyboard state. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>LED</glossterm> + <glossdef> + <para> +A light emitting diode. However, for the purposes of the X keyboard extension +specification, a LED is any form of visual two-state indicator that is either +on or off. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Locked Group</glossterm> + <glossdef> + <para> +A locked group is a group index that is combined with the base and latched +group to form the effective group. When a group is locked, it supersedes any +previous locked group and remains the locked group for all future key events, +until a new group is locked. The locked group can be changed by keyboard +activity or via Xkb extension library functions. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Locked Modifiers</glossterm> + <glossdef> + <para> +Locked modifiers are the set of modifiers that are combined with the base +modifiers and the latched modifiers to form the effective modifiers. A locked +modifier applies to all future key events until it is explicitly unlocked. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Lookup State </glossterm> + <glossdef> + <para> +The lookup state is composed of the lookup group and the lookup modifiers, and +it is the state an Xkb-capable or Xkb-aware client should use to map a keycode +to a keysym. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Modifier</glossterm> + <glossdef> + <para> +A modifier is a logical condition that is either set or unset. The modifiers +control the Shift Level selected when a key event occurs. Xkb supports the core +protocol eight modifiers (<emphasis> +Shift</emphasis> +, <emphasis> +Lock</emphasis> +, <emphasis> +Control</emphasis> +, and <emphasis> +Mod1</emphasis> + through <emphasis> +Mod5</emphasis> +), called the <emphasis> +real</emphasis> + modifiers. In addition, Xkb extends modifier flexibility by providing a set of +sixteen named virtual modifiers, each of which can be bound to any set of the +eight real modifiers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Modifier Key</glossterm> + <glossdef> + <para> +A modifier key is a key whose operation has no immediate effect, but that, for +as long as it is held down, modifies the effect of other keys. A modifier key +may be, for example, a shift key or a control key. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Modifier Definition</glossterm> + <glossdef> + <para> +An Xkb modifier definition, held in an <emphasis> +XkbModsRec</emphasis> +, consists of a set of real modifiers, a set of virtual modifiers, and an +effective mask. The mask is the union of the real modifiers and the set of real +modifiers to which the virtual modifiers map; the mask cannot be explicitly +changed. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Nonkeyboard Extension Device </glossterm> + <glossdef> + <para> +An input extension device that is not a keyboard. Other types of devices +supported by the input extension include, but are not limited to: mice, +tablets, touchscreens, barcode readers, button boxes, trackballs, identifier +devices, data gloves, and eye trackers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Outlines</glossterm> + <glossdef> + <para> +An outline is a list of one or more points that describes a single closed +polygon, used in the geometry specification for a keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Physical Indicator Mask</glossterm> + <glossdef> + <para> +The physical indicator mask is a field in the <emphasis> +XkbIndicatorRec</emphasis> + that indicates which indicators are bound to physical LEDs on the keyboard; if +a bit is set in <emphasis> +phys_indicators</emphasis> +, then the associated indicator has a physical LED associated with it. This +field is necessary because some indicators may not have corresponding physical +LEDs on the keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Physical Symbol Keyboard Name</glossterm> + <glossdef> + <para> +The <emphasis> +symbols</emphasis> + keyboard name identifies the symbols logically bound to the keys. The symbols +name is a human or application-readable description of the intended locale or +usage of the keyboard with these symbols. The <emphasis> +phys_symbols</emphasis> + keyboard name, on the other hand, identifies the symbols actually engraved on +the keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Preserved Modifier</glossterm> + <glossdef> + <para> +Xkb normally consumes modifiers in determining the appropriate symbol for an +event, that is, the modifiers are not considered during any of the later stages +of event processing. For those rare occasions when a modifier <emphasis> +should</emphasis> + be considered despite having been used to look up a symbol, key types include +an optional <emphasis> +preserve</emphasis> + field. If a modifier is present in the <emphasis> +preserve</emphasis> + list, it is a preserved modifier. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Radio Group</glossterm> + <glossdef> + <para> +A radio group is a set of keys whose behavior simulates a set of radio buttons. +Once a key in a radio group is pressed, it stays logically depressed until +another key in the group is pressed, at which point the previously depressed +key is logically released. Consequently, at most one key in a radio group can +be logically depressed at one time. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Real Modifier</glossterm> + <glossdef> + <para> +Xkb supports the eight core protocol modifiers (<emphasis> +Shift</emphasis> +, <emphasis> +Lock</emphasis> +, <emphasis> +Control</emphasis> +, and <emphasis> +Mod1</emphasis> + through <emphasis> +Mod5</emphasis> +); these are called the <emphasis> +real</emphasis> + modifiers, as opposed to the set of sixteen named virtual modifiers that can +be bound to any set of the eight real modifiers. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Server Internal Modifiers</glossterm> + <glossdef> + <para> +Modifiers that the server uses to determine the appropriate symbol for an +event; internal modifiers are normally consumed by the server. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Shift Level</glossterm> + <glossdef> + <para> +One of several states (normally 2 or 3) governing which graphic character is +produced when a key is actuated. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Symbol Keyboard Name</glossterm> + <glossdef> + <para> +The <emphasis> +symbols</emphasis> + keyboard name identifies the symbols logically bound to the keys. The symbols +name is a human or application-readable description of the intended locale or +usage of the keyboard with these symbols. The <emphasis> +phys_symbols</emphasis> + keyboard name, on the other hand, identifies the symbols actually engraved on +the keyboard. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Symbolic Name</glossterm> + <glossdef> + <para> +Xkb supports symbolic names for most components of the keyboard extension. Most +of these symbolic names are grouped into the <emphasis> +names</emphasis> + component of the keyboard description. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>State Field</glossterm> + <glossdef> + <para> +The portion of a client-side core protocol event that holds the modifier, +group, and button state information pertaining to the event. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Types Name</glossterm> + <glossdef> + <para> +The <emphasis> +types</emphasis> + name provides some information about the set of key types that can be +associated with the keyboard. In addition, each key type can have a name, and +each shift level of a type can have a name. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Valuator</glossterm> + <glossdef> + <para> +A valuator reports a range of values for some entity, like a mouse axis, a +slider, or a dial. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Virtual Modifier</glossterm> + <glossdef> + <para> +Xkb provides a set of sixteen named virtual modifiers that can be bound to any +set of the eight real modifiers. Each virtual modifier can be bound to any set +of the real modifiers (<emphasis> +Shift</emphasis> +, <emphasis> +Lock</emphasis> +, <emphasis> +Control,</emphasis> + and <emphasis> +Mod1</emphasis> +-<emphasis> +Mod5</emphasis> +). + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Virtual Modifier Mapping</glossterm> + <glossdef> + <para> +Xkb maintains a virtual modifier mapping, which lists the virtual modifiers +associated with each key. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Xkb-aware Client</glossterm> + <glossdef> + <para> +A client application that initializes Xkb extension and is consequently bound +to an Xlib that includes the Xkb extension. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Xkb-capable Client</glossterm> + <glossdef> + <para> +A client application that makes no Xkb extension Xlib calls but is bound to an +Xlib that includes the Xkb extension. + </para> + </glossdef> +</glossentry> +<glossentry> + <glossterm>Xkb-unaware Client</glossterm> + <glossdef> + <para> +A client application that makes no Xkb extension Xlib calls and is bound to an +Xlib that does not include the Xkb extension. + </para> + </glossdef> +</glossentry> + +</glossary> |