Journey Of A Keystroke

When the user presses a key, a series of events is launched to handle that action. Let’s follow the bits through the system after the user presses a key on the keyboard.

Step 1: The Input Server Add-on

When the user presses a key on the keyboard, the entity responsible for recognizing this action is the Input Server add-on for the keyboard device on which the key was pressed. The add-on uses the current keymap (which it has obtained by calling get_key_map()) to map the keycode to the character.

The add-on then constructs a B_KEY_DOWN or B_UNMAPPED_KEY_DOWN BMessage, containing both the raw keycode and the actual characters generated by the key, and sends the message to the Application Server by calling the BInputServerDevice::EnqueueMessage() function.

Step 2: The Application Server

The Aplication Server receives the message from the Input Server add-on and decides what to do with it. If the key pressed is something the Application Server traps, like a workspace change keystroke, it gets handled internally.

Otherwise, the Application server locates the active window and passes the BMessage along to its BWindow::DispatchMessage() function.

Step 3: The Active Window

The BWindow::DispatchMessage() function receives the BMessage from the Application Server, and intercepts some keys (like menu shortcuts and the Command+W close window sequence). If it’s not a key the BWindow class (or derived class) wants to intercept, DispatchMessage() passes the message along to the currently focused view’s BView::MessageReceived() function.

Step 4: The Focused View

The message finally arrives at the view that’s currently focused in the active window. This view’s MessageReceived() function processes the keypress in whatever way it wants to.

Likewise, when the key is released, a B_KEY_UP or B_UNMAPPED_KEY_UP event is sent through this same route.