Route VST2 keystrokes to ExternalWindow

[lucianoiam]

Related to #313

[falkTX]

While I can understand why, this needs more work and thought since the DGL Key macros are not available without DGL.
At the very least we need to define them somewhere.

[lucianoiam]

Yes. There's a design choice to be made, should those be moved out of DGL, replicated, inherit from a common base, not sure. This is again a stopgap PR that needs improvement :)

[falkTX]

This is also only for VST2, there is no such thing on other formats.
Makes it very inconsistent without having a dedicated way to receive keyboard events on the external window.

tbh I am more inclined to not support this whatsoever.

[lucianoiam]

That fact strikes me. Why is this required at all and only supported by VST2? I mean what can cause the topmost plugin view to be unable to receive keyboard input? . I really need to research on the latter to fix my problem. I agree this PR should not exist. But also don't understand why something similar exists for DGL, isn't kbd input already handled by Pugl? is it something related to the event loop? I don't reach that far.

[falkTX]

It is related to VST hosts and how they do not want plugins stealing keyboard focus.
This is the dumb solution added by steinberg, without having to dig any deeper into OS level things.
All should be possible without resorting to such tricks, but the constant fight for who gets keyboard events - host vs plugin - leads to sad situations like these.

JUCE has workarounds in place to always try and grab keyboard from the host, we dont do that in stock DPF so the special VST key events are required for some hosts.
Doesnt matter if linux, macos or windows, it just happens on some hosts regardless.

I think the biggest problem is finding a nice way for hosts to let plugins take some of the keyboard events (while some are reserved for the host) and then somehow recognize if the plugin did anything with it or not.
But this requires most hosts and plugins to be implemented in a similar fashion when it comes to keyboard input support... easier said than done.

We have a similar situation for the UI resize.
VST2 went with the dumb/stupid/simple decision to just have a callback for this as part of the spec. VST3 doubles-down by making that callback double-sided.
But such things are not really necessary if the host and plugin behave properly, which is what I am trying to push for in LV2 with the use of no lv2 ui resize extensions in DPF.

We should be able to make this all work without resorting to magic plugin-spec calls, but it takes a considerable amount of effort, and per-OS.

[lucianoiam]

That was very informative and perfectly explains the mixed results I am getting, thanks. I guess Bitwig on Linux does a great job keeping keyboard focus for itself, for example observed that repeatedly hitting keys while clicking a <input> [ I made clicking that <input> in turn call XSetInputFocus() ] sometimes produces text, maybe 1 out of 20 times. Sounds like a check happening at periodic intervals. REAPER and Carla are benevolent on this aspect, the plugin can grab focus indefinitely.

Will have a look at JUCE source then. Sad to know VST3 isn't much better in this aspect...

Edited to add missing words, including HTML tokens in GitHub replies does not work unless they are quoted

[lucianoiam]

I am not very sure of what I wrote above now, as running

watch -n 1 xdotool getwindowfocus

shows the window ID being updated as expected as the user toggles the focus between the Bitwig window or plugin windows, including mine. Vital VST3 has a preset browser with a search box and the box works as expected on Bitwig/Linux. Also didn't spot anything special in JUCE code but tbh haven't devoted a lot of time on it. Still think I am oversimplifying this.

[lucianoiam]

In the case of Linux/GTK I found gdk_seat_grab(seat, window, GDK_SEAT_CAPABILITY_KEYBOARD, ...) to be very effective. Tested on REAPER and Bitwig. Never had issues on Carla to start with.

Closing this PR now.