WIP: forwarding certain key events of 'wine_window' to 'host_window'

[Goli4thus]

TLDR: Found a way to forward key events received on wine_window to host_window.

backstory

This feature request: https://github.com/robbert-vdh/yabridge/issues/259 Also inspired by some things I learned recently from linvst.

the not so intuitive part

All about this part:

const uint32_t event_mask = XCB_EVENT_MASK_NO_EVENT;
event->event = host_window_;
xcb_send_event(
        x11_connection_.get(),
        false, host_window_, event_mask,
        reinterpret_cast<const char*>(event));

The comments in actual code mention it somewhat, but here in more detail:

For whatever reason, using something like XCB_EVENT_MASK_KEY_PRESS for the event mask didn't work (i.e. sent key events didn't trigger anything in REAPER). But using XCB_EVENT_MASK_NO_EVENT somehow makes it work.

I find this bit suprising: My guess would have been that the whole event mask mechanism for deciding which events are sent to a client (e.g. REAPER) would be like a bitwise AND operation:

(event_mask__reaper & event_mask__xcb_send_event) != 0

If that evaluates to true, the event would be forwarded to REAPER by Xserver (which xcb, just like xlib builds upon). But considering XCB_EVENT_MASK_NO_EVENT has the value 0 and considering this commit works kind of invalidates that guess. Almost seems like it would function as a wildcard of some sort and forward the event anyway, regardless of what REAPER might have set.

Then again, I didn't debug the Xserver to check if: a) the event was sent with both event masks, but REAPER somehow dropped the event by itself b) if the event really wasn't sent by Xserver, because it figured that REAPER has set an event mask that just doesn't allow it (still leaves the question how XCB_EVENT_MASK_NO_EVENT actually works)

Open points

1. I couldn't figure out how to detect the current host being REAPER or something else. The goal would be to just enable this forwarding for REAPER (not point in having it for bitwig).
2. I'm open for criticism on what could be improved (apart from point 1 above). Obviously I'm still quite unfamiliar with the codebase, so I can't be too sure if this isn't breaking anything. But at least on REAPER it seemed rather solid.