From cf337875c5cd2b36dbfaaf30114edceaa2a539e5 Mon Sep 17 00:00:00 2001 From: Ran Benita Date: Sat, 21 Nov 2015 23:17:55 +0200 Subject: [PATCH] doc/quick-guide: small improvements Signed-off-by: Ran Benita --- doc/quick-guide.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/doc/quick-guide.md b/doc/quick-guide.md index 3cf5b3b..972d09c 100644 --- a/doc/quick-guide.md +++ b/doc/quick-guide.md @@ -27,8 +27,7 @@ xkbcommon/ for more details. ## Code -Before we can do anything interesting, we need a library context. So -let's create one: +Before we can do anything interesting, we need a library context: ~~~{.c} #include @@ -39,10 +38,10 @@ let's create one: if (!ctx) ~~~ -The xkb_context contains the keymap include paths, the log level and +The `xkb_context` contains the keymap include paths, the log level and functions, and other general customizable administrativia. -Next we need to create a keymap, xkb_keymap. This is an immutable object +Next we need to create a keymap, `xkb_keymap`. This is an immutable object which contains all of the information about the keys, layouts, etc. There are different ways to do this. @@ -50,8 +49,8 @@ If we are an evdev client, we have nothing to go by, so we need to ask the user for his/her keymap preferences (for example, an Icelandic keyboard with a Dvorak layout). The configuration format is commonly called RMLVO (Rules+Model+Layout+Variant+Options), the same format used -by the X server. With it, we can fill a struct called xkb_rule_names; -passing NULL chooses the system's default. +by the X server. With it, we can fill a struct called `xkb_rule_names`; +passing `NULL` chooses the system's default. ~~~{.c} struct xkb_keymap *keymap; @@ -101,7 +100,7 @@ we will use the core keyboard device: ~~~ Now that we have the keymap, we are ready to handle the keyboard devices. -For each device, we create an xkb_state, which remembers things like which +For each device, we create an `xkb_state`, which remembers things like which keyboard modifiers and LEDs are active: ~~~{.c} @@ -118,7 +117,7 @@ For X11/XCB clients, this is better: if (!state) ~~~ -When we have an xkb_state for a device, we can start handling key events +When we have an `xkb_state` for a device, we can start handling key events from it. Given a keycode for a key, we can get its keysym: ~~~{.c} @@ -165,7 +164,7 @@ We can also get a UTF-8 string representation for this key: xkb_state_key_get_utf8(state, keycode, buffer, size); ~~~ -Of course, we also need to keep the xkb_state up-to-date with the +Of course, we also need to keep the `xkb_state` up-to-date with the keyboard device, if we want to get the correct keysyms in the future. If we are an evdev client, we must let the library know whether a key @@ -183,7 +182,7 @@ is pressed or released at any given time: The `changed` return value tells us exactly which parts of the state have changed. -If is is a key-repeat event, we can ask the keymap what to do with it: +If it is a key-repeat event, we can ask the keymap what to do with it: ~~~{.c} if ( && !xkb_keymap_key_repeats(keymap, keycode)) @@ -205,7 +204,7 @@ information usually comes in a form of some "state changed" event): event->locked_layout); ~~~ -Now that we have an always-up-to-date xkb_state, we can examine it. +Now that we have an always-up-to-date `xkb_state`, we can examine it. For example, we can check whether the Control modifier is active, or whether the Num Lock LED is active: @@ -218,8 +217,7 @@ whether the Num Lock LED is active: ~~~ -And that's it! When we're finished, we should free the objects we've -created: +And that's it! Eventually, we should free the objects we've created: ~~~{.c} xkb_state_unref(state);