Keyboard interaction interface

[sdilts]

In the c-core branch, the keyboard interaction callback interface is ready to be designed and implemented. All of the callbacks are hooked up and ready: the main thing to do is figure out what data should be passed to the callback, and if any wrapper functions in C need to be written.

Callback struct:

mahogany/heart/include/hrt/hrt_input.h

Lines 34 to 41 in b4b02b6

	struct hrt_seat_callbacks {
	// TODO: these need parameters
	void (*button_event)();
	void (*wheel_event)();
	bool (*keyboard_key_event)();
	// TODO: I don't know if we need this event:
	// bool (*keyboard_modifier_event)();
	};

Function where the callback is invoked:

mahogany/heart/src/keyboard.c

Line 62 in b4b02b6

static void seat_handle_key(struct wl_listener *listener, void *data) {

[sdilts]

We will need the keyboard_modifier_event if we are to implement bindings like CTRL-click as mentioned in #18.

[mtlll]

I'm a bit out of my comfort zone here, so bear with me in case my concerns make no sense.

If we have separate callbacks for a keyboard key being pressed and a modifier key being pressed, what does this look like for the program consuming the event? Let's saying I'm doing "C-z". It would first call keyboard_modifier_event, and then keyboard_key_event, right? So on the lisp side, I'm getting called into twice for what is essentially one event, with possible things like window updates etc happening in between? Wouldn't this add a fair amount of complication to the protocol? How do I as the client tell whether a modifier event and key event should be combined?

Perhaps it would be simplest just to have a struct with both the key and the modifier(s) on it, and pass that to the keyboard event callback(and similar for mouse/wheel events)? From peeking at the C code, looks like the modifiers modifiers are just stored as a uint32 which I assume is a bitfield; that should be simple enough to pass to the lisp side as is, and translate it to something lispy like a list of modifiers or something on the lisp side.

[sdilts]

The reason the keyboard_modifier event exists is because we need to manually pass all events to the focused clients. The clients just receive the raw events and decide what to do for themselves. That is easily done on the C side. Since we can access the modifier state from keyboard objects, we don't necessarily need to expose the keyboard_modifier event to get the keyboard interface working.

On the lisp side, my thinking was that since we would implement the CTRL-click keybindings, we would need to access the modifier state in some way without the keyboard object. Now that you mention it, we could just keep track of the modifier state in the C backend and pass the modifier state in with the mouse and keyboard events.

[sdilts]

I ended up going with the suggestion by @mtlll in the implementation in #20.