summaryrefslogtreecommitdiff
path: root/XCBToDoKeyboard.mdwn
diff options
context:
space:
mode:
authorArnaudFontaine <ArnaudFontaine@web>2010-03-23 09:31:08 -0700
committerXCB site <xcb@freedesktop.org>2010-03-23 09:31:08 -0700
commit142f728f7428757bec3f01a9589e640fa05b656e (patch)
treea4b1539ad59d6599af76ca900c3e99afd0f19708 /XCBToDoKeyboard.mdwn
parent620337f04ce81e1fb7aaf536b96262e2078edd19 (diff)
Diffstat (limited to 'XCBToDoKeyboard.mdwn')
-rw-r--r--XCBToDoKeyboard.mdwn36
1 files changed, 18 insertions, 18 deletions
diff --git a/XCBToDoKeyboard.mdwn b/XCBToDoKeyboard.mdwn
index 1675643..ecc1972 100644
--- a/XCBToDoKeyboard.mdwn
+++ b/XCBToDoKeyboard.mdwn
@@ -33,8 +33,8 @@ also describes how a KeyCode should be converted to a KeySym.
### Overview
According to the X Window System protocol, the KeyPress and KeyRelease
-events contains the following fields (`detail' contains the keycode
-and `state' the modifiers state):
+events contains the following fields (`detail` contains the keycode
+and `state` the modifiers state):
root, event: WINDOW
child: WINDOW or None
@@ -44,14 +44,14 @@ and `state' the modifiers state):
state: SETofKEYBUTMASK
time: TIMESTAMP
-The section 5 of `X Window System Protocol' describes how a KeyCode is
+The section 5 of `X Window System Protocol` describes how a KeyCode is
converted to a KeySym according to the modifiers state. Only at most
two KeySym groups (which can be switched using the group modifier) can
be associated to a KeyCode and each group can have two KeySyms.
-Unlike `shift', `lock' and `control' modifiers, `Mode_Switch' and
-`Num_Lock' KeySyms do not have a dedicated modifier and are just bound
-to any of the modifiers `Mod1' through `Mod5'.
+Unlike `shift`, `lock` and `control` modifiers, `Mode_Switch` and
+`Num_Lock` KeySyms do not have a dedicated modifier and are just bound
+to any of the modifiers `Mod1` through `Mod5`.
This is the client library responsibility to convert a KeySym to a
character in the proper encoding. The appendix A describes the KeySym
@@ -106,7 +106,7 @@ events given above, Xlib defines the following functions:
_XTranslateKey which converts the KeyCode and the set modifiers to a
KeySym. Then, it calls _XTranslateKeySym to convert the KeySym to a
string, by looking at rebound KeySym (XRebindKey) then Latin 1 and
- ASCII. `USE_OWN_COMPOSE' seem to never be set by default?
+ ASCII. `USE_OWN_COMPOSE` seem to never be set by default?
* XKeysymToKeycode
@@ -132,8 +132,8 @@ characters which have to be translated to the proper character
encoding (UTF-8 ([http://www.cl.cam.ac.uk/~mgk25/unicode.html]),
UTF-16 or UTF-32).
-This is implemented in `src/xlibi18n' as `Xutf8LookupString()' (UTF-8
-strings), `XwcLookupString' and `XmbLookupString'.
+This is implemented in `src/xlibi18n` as `Xutf8LookupString()` (UTF-8
+strings), `XwcLookupString` and `XmbLookupString`.
## XCB
@@ -144,14 +144,14 @@ keyboard functions. Therefore, it greatly restricts the usages of XCB
in "real-world" applications and duplicate the efforts as most
applications ported to XCB so far (such as Awesome Window Manager, VLC
and others) have to write their own implementation, which is often
-incomplete and buggy as it's rather tricky to implement properly and
+incomplete and buggy as it is rather tricky to implement properly and
entirely.
### Current status
Currently, XCB only implements the bits given in the X Window System
Protocol, and even this support is not complete compared to Xlib
-(character encoding, no `XLookupString()'...). All the X Window System
+(character encoding, no `XLookupString()`...). All the X Window System
Protocol requests have been implemented so far, but most applications
rely extensively on Xlib helpers which provides
@@ -162,31 +162,31 @@ still missing.
Here is a list of files and/or functions:
-* `keysymdef.h'
+* `keysymdef.h`
Perhaps, it should be defined in an XML file, rather than a plain
header (useful to bindings for another programming languages?).
-* `XConvertCase()': `xcb_convert_case()'
+* `XConvertCase()`: `xcb_convert_case()`
Compare to Xlib implementation, XCB misses "Latin 1", "Unicode" and
"Latin 9" KeySyms. The first and second ones are implemented in
- `UCSConvertCase()' Xlib function.
+ `UCSConvertCase()` Xlib function.
Moreover, Besides of that, the X Window System Protocol also defines
more sets, namely "Kana", "Arabic", "Technical", "Special",
"Publish", "APL", "Hebrew", "Thai", "Korean" and "Currency"?
-* `XKeycodeToKeysym()': `xcb_key_symbols_get_keysym()'
+* `XKeycodeToKeysym()`: `xcb_key_symbols_get_keysym()`
OK.
-* `XLookupKeysym()': `xcb_key_press_lookup_keysym()' and
- `xcb_key_release_lookup_keysym()'
+* `XLookupKeysym()`: `xcb_key_press_lookup_keysym()` and
+ `xcb_key_release_lookup_keysym()`
OK.
-* `XRefreshKeyboardMapping()': `xcb_refresh_keyboard_mapping()'
+* `XRefreshKeyboardMapping()`: `xcb_refresh_keyboard_mapping()`
OK.