-
Notifications
You must be signed in to change notification settings - Fork 58
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
Comments
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
This should fix RustAudio/baseview#116.
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.
To add to this, I feel like the simplest way around this would be to add |
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
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 thenWIndowHandler
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.
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.
The text was updated successfully, but these errors were encountered: