From c336374f3bf34ce875b29001548470f8d824141e Mon Sep 17 00:00:00 2001 From: Matt Dew Date: Wed, 2 Mar 2011 17:11:05 -0700 Subject: Fix bad link anchors. Fix broken links in kxproto. The old links hardcoded the output filename 'XKBproto.htm' and used anchors that didn't convert correctly. The new anchors are strings that use the same convention as other anchors in other docs. Fix links like: Compute State Field to be: Compute State Field Signed-off-by: Matt Dew Reviewed-by: Gaetan Nadon Reviewed-by: Alan Coopersmith --- specs/appA.xml | 2 +- specs/ch02.xml | 14 +++--- specs/ch03.xml | 4 +- specs/ch04.xml | 56 ++++++++++----------- specs/ch05.xml | 24 ++++----- specs/ch06.xml | 36 +++++++------- specs/ch07.xml | 42 ++++++++-------- specs/ch08.xml | 9 ++-- specs/ch09.xml | 17 +++---- specs/ch10.xml | 4 +- specs/ch11.xml | 7 ++- specs/ch12.xml | 56 ++++++++++----------- specs/ch13.xml | 5 +- specs/ch14.xml | 4 +- specs/ch15.xml | 2 +- specs/ch16.xml | 153 ++++++++++++++++++++++++++------------------------------- 16 files changed, 200 insertions(+), 235 deletions(-) diff --git a/specs/appA.xml b/specs/appA.xml index fa85a67..6bb0dbe 100644 --- a/specs/appA.xml +++ b/specs/appA.xml @@ -175,7 +175,7 @@ capitalization behavior. Any keysyms not explicitly listed in these tables are not capitalized by XKB when locale-insensitive capitalization is in effect and are not automatically assigned the ALPHABETIC - type as described in . + type as described in the Alphabetic Key Type. diff --git a/specs/ch02.xml b/specs/ch02.xml index 27a566a..e3558d1 100644 --- a/specs/ch02.xml +++ b/specs/ch02.xml @@ -273,8 +273,8 @@ ServerInternalModifiers IgnoreLocksModifiers and IgnoreGroupLock - controls, described in See Server -Internal Modifiers and Ignore Locks Behavior, to derive these two + controls, described in See Server +Internal Modifiers and Ignore Locks Behavior, to derive these two states as follows: @@ -355,16 +355,15 @@ The core protocol interpretation of keyboard modifiers does not include direct support for multiple groups, so XKB reports the effective keyboard group to XKB-aware clients using some of the reserved bits in the state field of some core protocol events, as described in -See Computing A State Field from an -XKB State. +See Computing A State Field from an +XKB State. This modified state field would not be interpreted correctly by XKB-unaware clients, so XKB provides a group compatibility mapping -(see See Group Compatibility Map) which +(see See Group Compatibility Map) which remaps the keyboard group into a core modifier mask that has similar effects, when possible. XKB maintains three compatibility state components that are used to make non-XKB clients work as well as possible: @@ -399,8 +398,7 @@ of the grab state. Compatibility states are essentially the corresponding XKB state, but with -keyboard group possibly encoded as one or more modifiers; See Group Compatibility Map describes +keyboard group possibly encoded as one or more modifiers; See Group Compatibility Map describes the group compatibility map, which specifies the modifier(s) that correspond to each keyboard group. diff --git a/specs/ch03.xml b/specs/ch03.xml index 1181172..66b3353 100644 --- a/specs/ch03.xml +++ b/specs/ch03.xml @@ -212,8 +212,8 @@ NumLock The virtual modifier mapping is normally updated automatically whenever actions -are assigned to keys (see See Changing -the Keyboard Mapping Using the Core Protocol for details) and few +are assigned to keys (see See Changing +the Keyboard Mapping Using the Core Protocol for details) and few applications should need to change the virtual modifier mapping explicitly. diff --git a/specs/ch04.xml b/specs/ch04.xml index 33b77b3..631d1b0 100644 --- a/specs/ch04.xml +++ b/specs/ch04.xml @@ -99,8 +99,8 @@ whether or not it is supported. -See Querying and Changing Per-Client -Flags describes the +See Querying and Changing Per-Client +Flags describes the XkbPerClientFlags request, which reports or changes values for all of the per-client flags, and which lists the per-client flags that are supported. @@ -148,8 +148,7 @@ rejection or release of any key to interested clients using AccessXNotify events. The AccessXNotify - event is described in more detail in See Events. + event is described in more detail in See Events. @@ -184,8 +183,7 @@ interested clients by sending an AccessXNotify event. The AccessXNotify - event is described in more detail in See Events. + event is described in more detail in See Events. @@ -377,8 +375,8 @@ When MouseKeys are active and a SA_MovePtr - key action (see See Key -Actions) is activated, a pointer motion event is generated immediately. + key action (see See Key +Actions) is activated, a pointer motion event is generated immediately. If MouseKeysAccel is enabled and if acceleration is enabled for the key in question, a second @@ -517,11 +515,11 @@ StickyKeys Some of these key sequences optionally generate audible feedback of the change -in state, as described in See The -AccessXFeedback Control, or cause +in state, as described in See The +AccessXFeedback Control, or cause XkbAccessXNotify - events as described in See -Events. + events as described in See +Events. @@ -781,8 +779,8 @@ should generate when that overlay is enabled, assign it either the KB_Overlay1 or KB_Overlay2 - key behaviors, as described in See -Key Behavior. + key behaviors, as described in See +Key Behavior. @@ -793,11 +791,11 @@ Key Behavior. All of the controls described above, along with the AudibleBell - control (described in See Disabling -Server Generated Bells) and the + control (described in See Disabling +Server Generated Bells) and the IgnoreGroupLock - control (described in See Server -Internal Modifiers and Ignore Locks Behavior) comprise the + control (described in See Server +Internal Modifiers and Ignore Locks Behavior) comprise the boolean controls . In addition to any parameters listed in the descriptions of the individual controls, the boolean controls can be individually enabled or disabled by @@ -815,18 +813,18 @@ EnabledControls control or specified in any context that accepts only boolean controls: GroupsWrap - (See Computing Effective Modifier and -Group), + (See Computing Effective Modifier and +Group), EnabledControls , InternalMods - (See Server Internal Modifiers and -Ignore Locks Behavior), and + (See Server Internal Modifiers and +Ignore Locks Behavior), and IgnoreLockMods - (See Server Internal Modifiers and -Ignore Locks Behavior) and + (See Server Internal Modifiers and +Ignore Locks Behavior) and PerKeyRepeat - (See The RepeatKeys Control) + (See The RepeatKeys Control) @@ -838,8 +836,8 @@ PerKeyRepeat The auto-reset controls are a per-client value which consist of two masks that can contain any of the -boolean controls (see See "Boolean" -Controls and The EnabledControls Control). Whenever the client exits +boolean controls (see See "Boolean" +Controls and The EnabledControls Control). Whenever the client exits for any reason, any boolean controls specified in the auto-reset mask are set to the corresponding value from the @@ -853,8 +851,8 @@ automatically, even if abnormally terminated. For example, a client that replace the keyboard bell with some other audible cue might want to turn off the AudibleBell - control (See Disabling Server -Generated Bells) to prevent the server from also generating a sound and + control (See Disabling Server +Generated Bells) to prevent the server from also generating a sound and thus avoid cacophony. If the client were to exit without resetting the AudibleBell diff --git a/specs/ch05.xml b/specs/ch05.xml index d00a26d..e712d56 100644 --- a/specs/ch05.xml +++ b/specs/ch05.xml @@ -19,8 +19,7 @@ elapsed while the RepeatKeys control can cause multiple X events from a single physical key press if the key is held down for an extended period. The global keyboard controls affect -all of the keys on the keyboard and are described in See Global Keyboard Controls. +all of the keys on the keyboard and are described in See Global Keyboard Controls. @@ -30,8 +29,7 @@ keyboard overlays, in which a key generates an alternate keycode under certain circumstances, can be implemented using per-key behavior. Every key has a single behavior, so the effect of key behavior does not depend on keyboard modifier or group state, though it might depend on global keyboard controls. -Per-key behaviors are described in detail in See Key Behavior. +Per-key behaviors are described in detail in See Key Behavior. @@ -39,8 +37,7 @@ url="XKBproto.htm#50332257_81140">See Key Behavior. keyboard has some action associated with it. The key action tells the server what to do when an event which yields the corresponding keysym is generated. Key actions might change or suppress the event, generate some other event, or -change some aspect of the server. Key actions are described in See Key Actions. +change some aspect of the server. Key actions are described in See Key Actions. @@ -53,16 +50,14 @@ event, the client which receives the event processes it in several steps. First the client extracts the effective keyboard group and a set of -modifiers from the state field of the event. See See Computing A State Field from an XKB -State for details. +modifiers from the state field of the event. See See Computing A State Field from an XKB +State for details. Using the modifiers and effective keyboard group, the client selects a -symbol from the list of keysyms bound to the key. See Determining the KeySym Associated with a -Key Event discusses symbol selection. +symbol from the list of keysyms bound to the key. See Determining the KeySym Associated with a +Key Event discusses symbol selection. @@ -71,9 +66,8 @@ using any modifiers that are "left over" from the process of looking up a symbol. For example, if the Lock modifier is left over, the resulting keysym is capitalized according to the -capitalization rules specified by the system. See See Transforming the KeySym Associated with a -Key Event for a more detailed discussion of the transformations defined +capitalization rules specified by the system. See See Transforming the KeySym Associated with a +Key Event for a more detailed discussion of the transformations defined by XKB. diff --git a/specs/ch06.xml b/specs/ch06.xml index cab2624..6476750 100644 --- a/specs/ch06.xml +++ b/specs/ch06.xml @@ -261,9 +261,9 @@ Each key has an optional list of actions. If present, this list parallels the list of symbols associated with the key (i.e. it has one action per symbol associated with the key). For key press events, the server looks up the action to be applied from this list using the key symbol mapping associated with the -event key, just as a client looks up symbols as described in See Determining the KeySym Associated with a -Key Event; if the event key does not have any actions, the server uses +event key, just as a client looks up symbols as described in See Determining the KeySym Associated with a +Key Event; if the event key does not have any actions, the server uses the SA_NoAction event for that key regardless of modifier or group state. @@ -292,7 +292,7 @@ delay between the activation of one and the other. Most actions which affect keyboard modifier state accept a modifier definition -(see See Virtual Modifiers) +(see See Virtual Modifiers) named mods and a boolean flag name @@ -679,8 +679,8 @@ MouseKeysAccel keyboard control is enabled, key press also initiates the mouse keys timer for this key; every time this timer expires, the cursor moves again. The distance the cursor moves in these subsequent events is determined by the mouse keys -acceleration as described in See The -MouseKeysAccel Control. +acceleration as described in See The +MouseKeysAccel Control. @@ -1627,8 +1627,8 @@ event that caused them. Events sent to clients that have not issued an XkbUseExtension request contain a compatibility state in place of the actual XKB keyboard -state. See See Effects of XKB on Core -Protocol Events for a description of this compatibility mapping. +state. See See Effects of XKB on Core +Protocol Events for a description of this compatibility mapping. @@ -1646,9 +1646,9 @@ the following changes: A passive grab triggers if the modifier state specified in the grab -matches the grab compatibility state (described in See Compatibility Components of Keyboard -State). Clients can choose to use the XKB grab state instead by setting +matches the grab compatibility state (described in See Compatibility Components of Keyboard +State). Clients can choose to use the XKB grab state instead by setting the GrabsUseXKBState per-client flag. This flag affects all passive grabs that are requested by the @@ -1678,15 +1678,15 @@ LookupStateWhenGrabbed Otherwise, the state field of events that do not trigger a passive grab report is derived from the XKB effective modifiers and group, as described in -See Computing A State Field from an -XKB State. +See Computing A State Field from an +XKB State. If a key release event is the result of an autorepeating key that is being held down, and the client to which the event is reported has requested -detectable autorepeat (see See -Detectable Autorepeat), the event is not delivered to the client. +detectable autorepeat (see See +Detectable Autorepeat), the event is not delivered to the client. @@ -1719,9 +1719,9 @@ interact. The largest problems arise from the fact that an XKB state field -encodes an explicit keyboard group in bits 13-14 (as described in See Computing A State Field from an XKB -State), while pre-XKB clients use one of the eight keyboard modifiers +encodes an explicit keyboard group in bits 13-14 (as described in See Computing A State Field from an XKB +State), while pre-XKB clients use one of the eight keyboard modifiers to select an alternate keyboard group. To make existing clients behave reasonably, XKB normally uses the compatibility grab state instead of the XKB grab state to determine whether or not a passive grab is triggered. XKB-aware diff --git a/specs/ch07.xml b/specs/ch07.xml index 15b5399..500357f 100644 --- a/specs/ch07.xml +++ b/specs/ch07.xml @@ -7,7 +7,7 @@ client map for a keyboard is the collection of information a client needs to interpret key events that come from that keyboard. It contains a global list of key types -, described in See Key Types, +, described in See Key Types, and an array of key symbol map s, each of which describes the symbols bound to one particular key and the @@ -19,8 +19,8 @@ rules to be used to interpret those symbols. XKB associates a two-dimensional array of symbols with each key. Symbols are -addressed by keyboard group (see See -Keyboard State) and shift level, where level is defined as in the +addressed by keyboard group (see See +Keyboard State) and shift level, where level is defined as in the ISO9995 standard: @@ -86,14 +86,14 @@ group and shift level that correspond to the event. Group is reported in bits 13-14 of the state field of the key event, as -described in See Computing A State -Field from an XKB State. The keyboard group reported in the event might +described in See Computing A State +Field from an XKB State. The keyboard group reported in the event might be out-of-range for any particular key because the number of groups can vary from key to key. The XKB description of each key contains a group info field which is interpreted identically to the global groups wrap control (see -See Computing Effective Modifier and -Group) and which specifies the interpretation of groups that are +See Computing Effective Modifier and +Group) and which specifies the interpretation of groups that are out-of-range for that key. @@ -104,7 +104,7 @@ determine the shift level. The description of a key includes a key type for each group of symbols bound to the key. Given the modifiers from the key event, this key type yields a shift level and a set of "leftover" modifiers, as -described in See Key Types +described in See Key Types below. @@ -125,8 +125,8 @@ map field specifies the shift level that corresponds to some XKB modifier definition; any combination of modifiers that is not explicitly listed somewhere in the map yields shift level one. Map entries which specify unbound -virtual modifiers (see See Inactive -Modifier Definitions) are not considered; each entry contains an +virtual modifiers (see See Inactive +Modifier Definitions) are not considered; each entry contains an automatically-updated active field which indicates whether or not it should be used. @@ -161,8 +161,8 @@ Any modifiers specified in modifiers are normally consumed - (see See Transforming the KeySym -Associated with a Key Event), which means that they are not considered + (see See Transforming the KeySym +Associated with a Key Event), which means that they are not considered during any of the later stages of event processing. For those rare occasions that a modifier should @@ -396,8 +396,8 @@ according to the locale-sensitive capitalization rules specified by the system. If the Control modifier is set, the keysym is not affected, but the corresponding character -should be converted to a control character as described in . +should be converted to a control character as described in Default Symbol Transformations. @@ -427,7 +427,7 @@ Control Report the control character associated with the symbol. This extension defines the control characters associated with the ASCII alphabetic characters (both upper and lower case) and for a small set of punctuation -characters (see ). Applications are +characters (see Default Symbol Transformations). Applications are free to associate control characters with any symbols that are not specified by this extension. @@ -437,7 +437,7 @@ Lock Capitalize the symbol either according to capitalization rules appropriate to the application locale or using the capitalization rules defined -by this extension (see ). +by this extension (see Default Symbol Transformations). @@ -449,11 +449,11 @@ Interpretation of other modifiers is application dependent. This definition of capitalization is fundamentally different from the core protocol’s, which uses the lock modifier to select from the symbols -bound to the key. Consider key 9 in the example keyboard on See Consider a simple, if +bound to the key. Consider key 9 in the example keyboard on See Consider a simple, if unlikely, keyboard with the following keys (gray characters indicate symbols that are implied or expected but are not actually engraved on the -key):; the core protocol provides no way to generate the capital form +key):; the core protocol provides no way to generate the capital form of either symbol bound to this key. XKB specifies that we first look up the symbol and then capitalize, so XKB yields the capital form of the two symbols when caps lock is active. @@ -677,8 +677,8 @@ to be used. The key type determines which symbol is chosen from the list. -See Determining the KeySym Associated -with a Key Event details the procedure to map from a key event to a +See Determining the KeySym Associated +with a Key Event details the procedure to map from a key event to a symbol and/or a string. diff --git a/specs/ch08.xml b/specs/ch08.xml index feaa995..2dd04a9 100644 --- a/specs/ch08.xml +++ b/specs/ch08.xml @@ -86,9 +86,8 @@ symbols geometry names typically correspond to the keyboard components from which the current keyboard description was assembled. These components are stored individually in -the server’s database of keyboard components, described in See The Server Database of Keyboard -Components, and can be combined to assemble a complete keyboard +the server’s database of keyboard components, described in See The Server Database of Keyboard +Components, and can be combined to assemble a complete keyboard description. @@ -131,8 +130,8 @@ customizations are straightforward. Key aliases can be specified both in the symbolic names component and in the -keyboard geometry (see See Keyboard -Geometry). Both sets of aliases are always valid, but key alias +keyboard geometry (see See 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, applications should consider the definitions from the geometry before considering the definitions from the symbolic names section. diff --git a/specs/ch09.xml b/specs/ch09.xml index b5cae3f..c78eba9 100644 --- a/specs/ch09.xml +++ b/specs/ch09.xml @@ -60,8 +60,8 @@ keyboard, it cannot be directly changed under program control. It is possible, however, for the set of physical indicators to be change if a new keyboard is attached or if a completely new keyboard description is loaded by the XkbGetKeyboardByName - request (see See Using the Server’s -Database of Keyboard Components). + request (see See Using the Server’s +Database of Keyboard Components). @@ -88,9 +88,8 @@ XkbGetNames request reports the symbolic names for all keyboard components, including the indicators. Use the XkbSetNames - request to change symbolic names. Both requests are described in See Querying and Changing Symbolic -Names. + request to change symbolic names. Both requests are described in See Querying and Changing Symbolic +Names. @@ -233,8 +232,7 @@ mods fields of an indicator map determine how the state of the keyboard modifiers affect the corresponding indicator. The mods - field is an XKB modifier definition, as described in See Modifier Definitions, which can + field is an XKB modifier definition, as described in See Modifier Definitions, which can specify both real and virtual modifiers. The mods field takes effect even if some or all of the virtual indicators specified in mods @@ -307,9 +305,8 @@ IM_UseCompat The controls - field specifies a subset of the boolean keyboard controls (see See "Boolean" Controls and The -EnabledControls Control). The indicator is lit whenever any of the + field specifies a subset of the boolean keyboard controls (see See "Boolean" Controls and The +EnabledControls Control). The indicator is lit whenever any of the boolean controls specified in controls are enabled. diff --git a/specs/ch10.xml b/specs/ch10.xml index 66b5cab..c20622b 100644 --- a/specs/ch10.xml +++ b/specs/ch10.xml @@ -110,8 +110,8 @@ sounds other than simple tones, but it is not required to do so. Aside from those used by the XKB AccessXFeedback - control (see See The AccessXFeedback -Control), this extension does not specify bell names or their + control (see See The AccessXFeedback +Control), this extension does not specify bell names or their interpretation. diff --git a/specs/ch11.xml b/specs/ch11.xml index 3164b6c..1be90dd 100644 --- a/specs/ch11.xml +++ b/specs/ch11.xml @@ -79,8 +79,8 @@ structures refer to geometry properties. A list of key aliases -, as described in See Symbolic -Names. +, as described in See Symbolic +Names. @@ -89,8 +89,7 @@ shapes ; other keyboard components refer to shapes by their index in this list. A shape consists of a name and one or more closed-polygons called outlines -. Shapes and outlines are described in detail in See Shapes and Outlines. +. Shapes and outlines are described in detail in See Shapes and Outlines. diff --git a/specs/ch12.xml b/specs/ch12.xml index ff399a1..cd21a48 100644 --- a/specs/ch12.xml +++ b/specs/ch12.xml @@ -53,8 +53,8 @@ of a keyboard mapping and XKB and explains the ways they can interact. Group Compatibility Map -As described in See Keyboard -State, the current keyboard group is reported to XKB-aware clients in +As described in See Keyboard +State, the current keyboard group is reported to XKB-aware clients in bits 13-14 of the state field of many core protocol events. XKB-unaware clients cannot interpret those bits, but they might use a keyboard modifier to implement support for a single keyboard group. To ensure that pre-XKB clients @@ -243,42 +243,41 @@ field for a key can contain any combination of the following values: ExplicitKeyType1 Automatic determination of the key type associated with Group1 - (see See Assigning Types To Groups of -Symbols for a Key) + (see See Assigning Types To Groups of +Symbols for a Key) ExplicitKeyType2 Automatic determination of the key type associated with Group2 -(see See Assigning Types To Groups of -Symbols for a Key) +(see See Assigning Types To Groups of +Symbols for a Key) ExplicitKeyType3 Automatic determination of the key type associated with Group3 -(see See Assigning Types To Groups of -Symbols for a Key). +(see See Assigning Types To Groups of +Symbols for a Key). ExplicitKeyType4 Automatic determination of the key type associated with Group4 -(see See Assigning Types To Groups of -Symbols for a Key). +(see See Assigning Types To Groups of +Symbols for a Key). ExplicitInterpret Application of any of the fields of a symbol interpretation to the -key in question (see See Assigning -Actions To Keys). +key in question (see See Assigning +Actions To Keys). ExplicitAutoRepeat Automatic determination of autorepeat status for the key, as -specified in a symbol interpretation (see See Assigning Actions To -Keys). +specified in a symbol interpretation (see See Assigning Actions To +Keys). ExplicitBehavior @@ -286,16 +285,15 @@ Keys). KB_Lock behavior to the key, if the LockingKey - flag is set in a symbol interpretation (see See Assigning Actions To -Keys). + flag is set in a symbol interpretation (see See Assigning Actions To +Keys). ExplicitVModMap Automatic determination of the virtual modifier map for the key based on the actions assigned to the key and the symbol interpretations which -match the key (see See Assigning -Actions To Keys). +match the key (see See Assigning +Actions To Keys). @@ -312,8 +310,7 @@ ChangeKeyboardMapping groups that are defined for the key and the width of each group. The XKB extension does not change key types in response to core protocol SetModifierMapping - requests, but it does choose key actions as described in See Assigning Actions To Keys. + requests, but it does choose key actions as described in See Assigning Actions To Keys. @@ -490,8 +487,7 @@ ALPHABETIC Describes alphabetic keys that have exactly two symbols per group. The default definition of the ALPHABETIC - type provides shift-cancels-caps behavior as described in See Key Types. Index + type provides shift-cancels-caps behavior as described in See Key Types. Index 2 in any key symbol map specifies key type ALPHABETIC @@ -541,7 +537,7 @@ lowercase and uppercase forms are defined, the X server treats the key as if the first element of the group were the lowercase form of the symbol and the second element were the uppercase form of the symbol. For the purposes of this expansion, XKB ignores the locale and uses the capitalization rules defined in -. +Default Symbol Transformations. @@ -737,7 +733,7 @@ locking key field is set in the symbol interpretation, the behavior of the key is changed to KB_Lock - (see See Key Behavior). The + (see See Key Behavior). The ExplicitBehavior component prevents this change. @@ -791,8 +787,8 @@ indicator maps, internal modifiers or ignore locks modifiers. After applying server actions which modify the base, latched or locked modifier or group state of the keyboard, the X server recomputes the effective group and state. Several components of the keyboard state are reported to XKB-aware -clients depending on context (see See -Keyboard State for a detailed description of each of the keyboard state +clients depending on context (see See +Keyboard State for a detailed description of each of the keyboard state components): @@ -967,8 +963,8 @@ by all of the actions associated with the key plus all of the modifiers associated with any virtual modifiers bound to the key by the virtual modifier mapping. If any of the actions associated with a key affect any component of the keyboard group, any modifiers specified in any entry of the group -compatibility map (see See Group -Compatibility Map) are reported in the modifier mask. The +compatibility map (see See Group +Compatibility Map) are reported in the modifier mask. The SA_ISOLock action can theoretically affect any modifier, but the modifier map of an diff --git a/specs/ch13.xml b/specs/ch13.xml index 5797f9f..f00a467 100644 --- a/specs/ch13.xml +++ b/specs/ch13.xml @@ -275,8 +275,7 @@ types component of a keyboard mapping specifies the key types that can be associated with the various keyboard keys. It affects the types - symbolic name and the list of types associated with the keyboard (see See Key Types). The types component + symbolic name and the list of types associated with the keyboard (see See Key Types). The types component of a keyboard mapping can also optionally contain real modifier bindings and symbolic names for one or more virtual modifiers. @@ -284,7 +283,7 @@ symbolic names for one or more virtual modifiers. The special types component named "canonical" always contains the types and -definitions listed in of this document. +definitions listed in Canonical Key Types of this document. diff --git a/specs/ch14.xml b/specs/ch14.xml index 98bde5d..fcf127a 100644 --- a/specs/ch14.xml +++ b/specs/ch14.xml @@ -9,8 +9,8 @@ keycodes. The server can generate an XkbNewKeyboardNotify event when it detects a new keyboard, or in response to an XkbGetKeyboardByName - request (see See Using the Server’s -Database of Keyboard Components) which loads a new keyboard description. + request (see See Using the Server’s +Database of Keyboard Components) which loads a new keyboard description. diff --git a/specs/ch15.xml b/specs/ch15.xml index fb9472f..7cca36a 100644 --- a/specs/ch15.xml +++ b/specs/ch15.xml @@ -113,7 +113,7 @@ Keyboard The XKB extension optionally allows clients to assign any key action (see -See Key Actions) to core +See Key Actions) to core pointer or input extension device buttons. This makes it possible to control the keyboard or generate keyboard key events from extension devices or from the core pointer. diff --git a/specs/ch16.xml b/specs/ch16.xml index 2ec152b..aeaec30 100644 --- a/specs/ch16.xml +++ b/specs/ch16.xml @@ -1215,8 +1215,7 @@ affectWhich If any components are specified in a client’s event masks, the X server sends the client an appropriate event whenever any of those components change state. -Unless explicitly modified, all event detail masks are empty. See Events describes all XKB events +Unless explicitly modified, all event detail masks are empty. See Events describes all XKB events and the conditions under which the server generates them. @@ -1533,8 +1532,8 @@ effective modifiers minus any server internal modifiers. The grabMods return value reports the grab modifiers, which consist of the lookup modifiers minus any members of the ignore locks mask that are not either latched or -logically depressed. See Keyboard -State describes the lookup modifiers and grab modifiers in more detail. +logically depressed. See Keyboard +State describes the lookup modifiers and grab modifiers in more detail. @@ -1557,8 +1556,8 @@ compatGrabMods return values report the core protocol compatibility states that correspond to the XKB lookup and grab state. All of the compatibility states are computed by applying the group compatibility mapping to the corresponding XKB modifier and -group states, as described in See -Group Compatibility Map. +group states, as described in See +Group Compatibility Map. @@ -1822,15 +1821,13 @@ The numGroups return value reports the current number of groups, and groupsWrap - reports the treatment of out-of-range groups, as described in See Key Symbol Map. The + reports the treatment of out-of-range groups, as described in See Key Symbol Map. The internalMods and ignoreLockMods return values report the current values of the server internal and ignore -locks modifiers as described in See -Keyboard State. Both are modifier definitions (See Modifier Definitions) which +locks modifiers as described in See +Keyboard State. Both are modifier definitions (See Modifier Definitions) which report the real modifiers, virtual modifiers, and the resulting combination of real modifiers that are bound to the corresponding control. @@ -1857,8 +1854,8 @@ mouseKeysMaxSpeed and mouseKeysCurve return values report the current acceleration applied to mouse keys, as -described in See The MouseKeysAccel -Control. All times are reported in milliseconds. +described in See The MouseKeysAccel +Control. All times are reported in milliseconds. @@ -2224,8 +2221,7 @@ If applied, repeatDelay and repeatInterval - change the autorepeat characteristics of the keyboard, as described in See The RepeatKeys Control. If + change the autorepeat characteristics of the keyboard, as described in See The RepeatKeys Control. If specified, repeatDelay and @@ -2241,8 +2237,8 @@ If applied, the slowKeysDelay field specifies a new delay for the SlowKeys - control, as defined in See The -SlowKeys Control. If specified, + control, as defined in See The +SlowKeys Control. If specified, slowKeysDelay must be non-zero, or a Value @@ -2255,8 +2251,8 @@ If applied, the debounceDelay field specifies a new delay for the BounceKeys - control, as described in See The -BounceKeys Control. If present, the + control, as described in See The +BounceKeys Control. If present, the debounceDelay must be non-zero or a Value @@ -2276,8 +2272,8 @@ SA_LockPtrBtn mouseKeysDfltBtn must specify a legal button for the core pointer device, or a Value - error results. See Key -Actions describes the + error results. See Key +Actions describes the SA_PtrBtn and SA_LockPtrBtn @@ -2299,8 +2295,8 @@ mouseKeysCurve fields change the rate at which the pointer moves when a key which generates a SA_MovePtr - action is held down. See The -MouseKeysAccel Control describes these + action is held down. See The +MouseKeysAccel Control describes these MouseKeysAccel parameters in more detail. If defined, the mouseKeysDelay @@ -2325,8 +2321,7 @@ Value If applied, the accessXOptions - field sets the AccessX options, which are described in detail in See The AccessXKeys Control. If + field sets the AccessX options, which are described in detail in See The AccessXKeys Control. If either one of XkbStickyKeysMask and @@ -2360,8 +2355,8 @@ accessXTimeoutOptionsMask and accessXTimeoutOptionsValues fields change the behavior of the AccessX Timeout control, as described in -See The AccessXTimeout -Control. The +See The AccessXTimeout +Control. The accessXTimeout must be greater than zero, or a Value @@ -2388,7 +2383,7 @@ Match If present, the groupsWrap field specifies the treatment of out-of-range keyboard groups, as described in -See Key Symbol Map. If the +See Key Symbol Map. If the groupsWrap field does not specify a legal treatment for out-of-range groups, a @@ -3328,8 +3323,8 @@ flags last key type specified by this request is the last element in the list. If the list of key types is shrunk, any existing key definitions that use key types that eliminated are automatically assigned key types from the list of canonical -key types as described in See -Assigning Types To Groups of Symbols for a Key. The list of key types +key types as described in See +Assigning Types To Groups of Symbols for a Key. The list of key types bound to a keyboard must always include the four canonical types and cannot have more than XkbMaxTypesPerKey @@ -3741,8 +3736,7 @@ XkbSetMapRecomputeActions bit is set in flags , the actions associated with any keys for which symbol or modifier bindings -were changed by this request are recomputed as described in See Assigning Actions To Keys. Note +were changed by this request are recomputed as described in See Assigning Actions To Keys. Note that actions are recomputed after any actions specified in this request are bound to keys, so the actions @@ -4088,8 +4082,8 @@ recomputeActions True , the server regenerates recalculates the actions bound to all keyboard keys by applying the new symbol interpretations to the entire key symbol map, as -described in See Assigning Actions To -Keys. +described in See Assigning Actions To +Keys. @@ -4245,7 +4239,7 @@ XkbIndicatorStateNotify The maps return value reports the requested indicator maps. Indicator maps are -described in See Indicator Maps +described in See Indicator Maps @@ -4719,8 +4713,7 @@ If setMap is True -, XKB changes the map for the indicator (see See Indicator Maps) to reflect the +, XKB changes the map for the indicator (see See Indicator Maps) to reflect the values specified in map . @@ -5529,9 +5522,8 @@ name is a valid atom other than None , the server returns the keyboard geometry description with that name in the -server database of keyboard components (see See The Server Database of Keyboard -Components) if one exists. If +server database of keyboard components (see See The Server Database of Keyboard +Components) if one exists. If deviceSpec does not specify a valid keyboard device, a Keyboard @@ -5570,8 +5562,8 @@ found True , the remaining fields of the reply describe the requested keyboard geometry. The interpretation of the components that make up a keyboard geometry is -described in detail in See Keyboard -Geometry +described in detail in See Keyboard +Geometry @@ -5863,36 +5855,36 @@ per-client-flags are: XkbPCF_DetectableAutorepeat - See Detectable -Autorepeat + See Detectable +Autorepeat XkbPCF_GrabsUseXKBStateMask - See Setting a Passive Grab -for an XKB State + See Setting a Passive Grab +for an XKB State XkbPCF_AutoResetControlsMask - See Automatic Reset of -Boolean Controls + See Automatic Reset of +Boolean Controls XkbPCF_LookupStateWhenGrabbed - See Effects of XKB on Core -Protocol Events + See Effects of XKB on Core +Protocol Events XkbPCF_SendEventUsesXKBState - See Sending Events to -Clients + See Sending Events to +Clients @@ -6117,8 +6109,7 @@ components. Each pattern uses the ISO Latin-1 encoding and should contain only parentheses, the wildcard characters "?" and "*" or characters that are permitted in a -component class or member name (see See Component Names). Illegal +component class or member name (see See Component Names). Illegal characters in a pattern are simply ignored; no error results if a pattern contains illegal characters. @@ -6162,15 +6153,15 @@ compatMaps symbols and geometries - return the hints (see See Component -Hints) and names of any components from the server database that match + return the hints (see See Component +Hints) and names of any components from the server database that match the corresponding pattern. -See The Server Database of Keyboard -Components describes the X server database of keyboard components in +See The Server Database of Keyboard +Components describes the X server database of keyboard components in more detail. @@ -6309,8 +6300,8 @@ compatMapSpec symbolsSpec and geometrySpec - component expressions (see See -Partial Components and Combining Multiple Components) specify the + component expressions (see See +Partial Components and Combining Multiple Components) specify the database components to be used to assemble the keyboard description. @@ -6419,8 +6410,8 @@ If either field contains a GBN component that depends on some database component for which the request does not supply an expression, XKB automatically substitutes the special pattern "%" which copies the corresponding component from the current keyboard description, as described in -See Partial Components and Combining -Multiple Components. +See Partial Components and Combining +Multiple Components. @@ -6443,9 +6434,8 @@ If all necessary components are both specified and found, the new keyboard description is loaded. If the new keyboard description has a different geometry or keycode range than the previous keyboard description, XKB sends XkbNewKeyboardNotify - events to all interested clients. See See Replacing the Keyboard -"On-the-Fly" for more information about the effects of replacing the + events to all interested clients. See See Replacing the Keyboard +"On-the-Fly" for more information about the effects of replacing the keyboard description on the fly. @@ -6895,9 +6885,8 @@ deviceID which values are being returned. The supported return value reports the set of optional XKB extension device features that -are supported by this implementation (see See Interactions Between XKB and the X Input -Extension) for the specified device, and the unsupported return value +are supported by this implementation (see See Interactions Between XKB and the X Input +Extension) for the specified device, and the unsupported return value reports any unsupported features. @@ -7543,8 +7532,8 @@ Once a client receives a new keyboard notify event which reports a new keycode range, the X server reports events from all keys in the new range to that client. Clients that do not request or receive new keyboard notify events receive events only from keys that fall in the last range for legal keys -reported to that client. See See -Replacing the Keyboard "On-the-Fly" for a more detailed explanation. +reported to that client. See See +Replacing the Keyboard "On-the-Fly" for a more detailed explanation. @@ -7911,8 +7900,7 @@ requestMajor, requestMinor: CARD8 An XkbStateNotify - event reports that some component of the XKB state (see See Keyboard State) has changed. + event reports that some component of the XKB state (see See Keyboard State) has changed. State notify events are usually caused by key or pointer activity, but they can also result from explicit state changes requested by the XkbLatchLockState @@ -7926,8 +7914,7 @@ deviceID field reports the keyboard on which some state component changed. The changed - field reports the XKB state components (see See Keyboard State) that have changed + field reports the XKB state components (see See Keyboard State) that have changed and contain any combination of: @@ -8176,10 +8163,9 @@ requestMinor: CARD8 An XkbControlsNotify event reports a change in one or more of the global keyboard controls (see -See Global Keyboard Controls) -or in the internal modifiers or ignore locks masks (see See Server Internal Modifiers and Ignore -Locks Behavior). Controls notify events are usually caused by and +See Global Keyboard Controls) +or in the internal modifiers or ignore locks masks (see See Server Internal Modifiers and Ignore +Locks Behavior). Controls notify events are usually caused by and XkbSetControls request, but they can also be caused by keyboard activity or certain core @@ -9181,10 +9167,9 @@ detail slowKeysDelay and debounceDelay - fields always reports the current slow keys acceptance delay (see See The SlowKeys Control) and -debounce delay (see See The BounceKeys -Control) for the specified keyboard. + fields always reports the current slow keys acceptance delay (see See The SlowKeys Control) and +debounce delay (see See The BounceKeys +Control) for the specified keyboard. @@ -9348,8 +9333,8 @@ extension device feature that is not supported by the XKB implementation in the server for the specified device. The unsupported mask reports the requested features that are not available on the specified -device. See See Interactions Between -XKB and the X Input Extension for more information about possible XKB +device. See See Interactions Between +XKB and the X Input Extension for more information about possible XKB interactions with the X Input Extension. -- cgit v1.2.1