XKeyboard

Char(keymap::Keymap, key::PhysicalKey)

Retrieve a UTF-8 character which corresponds to the printable input associated with the keysym obtained via the provided keycode and the keymap state.

If no printable input is defined for this keysym, the NUL character '\0' is returned which, when printed, is a no-op.

Char(keysym::Keysym)

Return the printable character of a Keysym ('\0' if not printable).

String(keymap::Keymap, key::PhysicalKey)

Obtain the string representation of a physical key.

String(keymap::Keymap)

Return a complete string representation of a Keymap.

String(keysym::Keysym)

Return a String representation of a Keysym.

Symbol(keymap::Keymap, key::PhysicalKey)

Obtain the name of a physical key.

String(keymap::Keymap, key::PhysicalKey) can be used instead if you aim to consume a String instead of a Symbol.

Symbol(keysym::Keysym)

Return the name of a Keysym. Equivalent to Symbol(String(keysym)).

Keymap used to encode information regarding keyboard layout, and country and language codes.

A string representation can be obtained from a Keymap by using String(keymap).

Code used by XKB to represent symbols on a logical level.

Such codes differ from keycodes in that they keycodes are stateless: when a key is pressed, it always emits the same keycode.

To understand the difference, let's take the physical key AD01. When pressed, it emits an integer signal (keycode) representing that specific key on the keyboard (the name AD01 is just a label that is more friendly than an integer code). If pressed on a US keyboard (QWERTY layout), it may emit the character q. Or Q. This depends on whether a shift modifier or caps lock (without shift modifier) is active, among other things. If we were on a French keyboard, then the letter would be a (AZERTY layout), or A. if we had pressed the left or right shift key instead, we would not even have a printable character associated with the keystroke.

q, Q, a, A, left_shift and right_shift are all semantic symbols, need not be printable (e.g. shifts) and their mapping from a physical key -if one exists- depends on some external state, tracked inside a Keymap. Just like physical keys, these symbols are represented with an integer code, and have a more friendly string representation that one can obtain with String(keysym::Keysym).

Keysyms are not physical keys, nor input characters.

Keysym(str::AbstractString)

Get the Keysym represented by the string str.

Keysym(keymap::Keymap, key::PhysicalKey)

Obtain the Keysym corresponding to the pressed key given a keymap state.

Keysym(name::Symbol)

Get the Keysym named name. Equivalent to Keysym(string(name)).

Physical key, represented with a designated integer keycode.

PhysicalKey(keymap::Keymap, name::Symbol)

Obtain a PhysicalKey from its string representation name using a keymap.

Useful for simulating events which typically require the integer code of a physical key (keycode).

A name of type AbstractString can be used instead if you have a string at the ready.

Construct a Keymap via X11 using conn as the connection to an X Server.

This action uses XKB, the X Keyboard extension, which must be initialized for each X11 connection, typically when creating a keymap. If this is not your first call to this constructor with this connection, you should set setup_xkb to false.

Upon creation, the keymap state (e.g. active modifiers) is filled with the current state. That means, if you press shift down while executing this code, the keymap state will encode a state where the shift modifier is active. This is not a concern if the state is properly managed by the calling code, e.g. XCB.jl updating the keymap on key presses and key releases, but this is something to be aware of.