Lines Matching full:we

6 the library. We will employ a few use-cases to lead the examples:
32 Before we can do anything interesting, we need a library context:
46 Next we need to create a keymap, `xkb_keymap`. This is an immutable object
50 If we are an evdev client, we have nothing to go by, so we need to ask
54 by the X server. With it, we can fill a struct called `xkb_rule_names`;
73 If we are a Wayland client, the compositor gives us a string complete
74 with a keymap. In this case, we can create the keymap object like this:
87 If we are an X11 client, we are better off getting the keymap from the
88 X server directly. For this we need to choose the XInput device; here
89 we will use the core keyboard device:
105 Now that we have the keymap, we are ready to handle the keyboard devices.
106 For each device, we create an `xkb_state`, which remembers things like which
123 When we have an `xkb_state` for a device, we can start handling key events
124 from it.  Given a keycode for a key, we can get its keysym:
135 We can see which keysym we got, and get its name:
156 We can also get a UTF-8 string representation for this key:
170 Of course, we also need to keep the `xkb_state` up-to-date with the
171 keyboard device, if we want to get the correct keysyms in the future.
173 If we are an evdev client, we must let the library know whether a key
188 If it is a key-repeat event, we can ask the keymap what to do with it:
195 On the other hand, if we are an X or Wayland client, the server already
197 changes, and we can simply use what it tells us (the necessary
210 Now that we have an always-up-to-date `xkb_state`, we can examine it.
211 For example, we can check whether the Control modifier is active, or
223 And that's it! Eventually, we should free the objects we've created: