Lines Matching refs:we

30 Before we can do anything interesting, we need a library context. So
45 Next we need to create a keymap, xkb_keymap. This is an immutable object
49 If we are an evdev client, we have nothing to go by, so we need to ask
53 by the X server. With it, we can fill a struct called xkb_rule_names;
72 If we are a Wayland client, the compositor gives us a string complete
73 with a keymap. In this case, we can create the keymap object like this:
85 If we are an X11 client, we are better off getting the keymap from the
86 X server directly. For this we need to choose the XInput device; here
87 we will use the core keyboard device:
103 Now that we have the keymap, we are ready to handle the keyboard devices.
104 For each device, we create an xkb_state, which remembers things like which
121 When we have an xkb_state for a device, we can start handling key events
122 from it.  Given a keycode for a key, we can get its keysym:
133 We can see which keysym we got, and get its name:
168 Of course, we also need to keep the xkb_state up-to-date with the
169 keyboard device, if we want to get the correct keysyms in the future.
171 If we are an evdev client, we must let the library know whether a key
186 If is is a key-repeat event, we can ask the keymap what to do with it:
193 On the other hand, if we are an X or Wayland client, the server already
195 changes, and we can simply use what it tells us (the necessary
208 Now that we have an always-up-to-date xkb_state, we can examine it.
209 For example, we can check whether the Control modifier is active, or
221 And that's it! When we're finished, we should free the objects we've