stumpwm / mahogany

A stumpwm like Wayland compositor
GNU General Public License v2.0
220 stars 12 forks source link

Keyboard interaction interface #15

Closed sdilts closed 3 years ago

sdilts commented 4 years ago

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: https://github.com/stumpwm/mahogany/blob/b4b02b6ecac920d1ba4d2f5fe2846584114e0e01/heart/include/hrt/hrt_input.h#L34-L41

Function where the callback is invoked: https://github.com/stumpwm/mahogany/blob/b4b02b6ecac920d1ba4d2f5fe2846584114e0e01/heart/src/keyboard.c#L62

sdilts commented 4 years ago

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

mtlll commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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