Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reparented X11 windows don't receive keyboard events when not hovering over them #116

Open
robbert-vdh opened this issue Feb 9, 2022 · 1 comment · Fixed by BillyDM/egui-baseview#9

Comments

@robbert-vdh
Copy link
Member

robbert-vdh commented Feb 9, 2022

An X11 window created using Windows::open_parented() will not receive keyboard input, and as a consequence of that, keyboard input for modifiers, when not hovering over the window. This makes sense as the window is not requesting input focus, but it does mean that weird things happen when you combine this with dragging gestures. When you start a dragging gesture, hold down shift, move your mouse cursor outside of the window, release shift, and then WIndowHandler won't notice shift being released, and every subsequent interaction would behave as if shift was still pressed. You can cry this out with this example using the patched baseview from #115 and Carla:

NOTE: This example has been updated with the patches from #117, so the issue no longer exists on the latest version.

git clone [email protected]:robbert-vdh/nih-plug.git
cd nih-plug
cargo xtask bundle gain_gui --bundle-vst3 && carla-single vst3 target/gain_gui.vst3

Note that this won't happen in Bitwig, as in Bitwig the host's parent window grabs focus itself and then forwards most keyboard events (except for Space and a couple other keys) to the child window.

Also, because modifiers are not sent as part of the mouse move/click events, the modifiers will be ignored when you Shift+click on a plugin GUI directly after opening the window in Bitwig because the click event arrives before the keyboard even (of it doesn't get sent at all, I'd need to check).

The potential ways to fix this would be to always grab keyboard focus, or to add modifiers to mouse move and click events. The last one is the least invasive, and I think this information is part of those events on every platform.

@robbert-vdh robbert-vdh changed the title Reparented X11 windows don't receive keyboard events when not hovering overthem Reparented X11 windows don't receive keyboard events when not hovering over them Feb 9, 2022
robbert-vdh added a commit to robbert-vdh/baseview that referenced this issue Feb 9, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
robbert-vdh added a commit to robbert-vdh/egui-baseview that referenced this issue Feb 9, 2022
Which should fix RustAudio/baseview#116 for
the use case of Shift+dragging a slider.
robbert-vdh added a commit to robbert-vdh/nih-plug that referenced this issue Feb 9, 2022
robbert-vdh added a commit to robbert-vdh/baseview that referenced this issue Feb 10, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
robbert-vdh added a commit to robbert-vdh/baseview that referenced this issue Mar 7, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
robbert-vdh added a commit to robbert-vdh/baseview that referenced this issue Mar 11, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
robbert-vdh added a commit to robbert-vdh/baseview that referenced this issue Mar 11, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
@robbert-vdh
Copy link
Member Author

To add to this, I feel like the simplest way around this would be to add grab_focus() and release_focus() methods to WindowHandle, and to also add FocusIn/FocusGrabbed and FocusOut/FocusReleased events that lets the window know if received or lost focus so it can keep track if its focus state.

robbert-vdh added a commit to robbert-vdh/egui-baseview that referenced this issue Sep 22, 2022
Which should fix RustAudio/baseview#116 for
the use case of Shift+dragging a slider.
robbert-vdh added a commit to robbert-vdh/egui-baseview that referenced this issue Sep 22, 2022
Which should fix RustAudio/baseview#116 for
the use case of Shift+dragging a slider.
robbert-vdh added a commit to robbert-vdh/egui-baseview that referenced this issue Sep 22, 2022
This should fix RustAudio/baseview#116 for the
use case of Shift+dragging a slider.
robbert-vdh added a commit to robbert-vdh/egui-baseview that referenced this issue Sep 22, 2022
This should fix RustAudio/baseview#116 for the
use case of Shift+dragging a slider.
kunalarya pushed a commit to kunalarya/baseview that referenced this issue Dec 10, 2022
This would solve the most important use case for RustAudio#116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant