-
Notifications
You must be signed in to change notification settings - Fork 567
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
listen for key events globally #1546
Comments
So long-term yes I would like some concept of 'ambient focus' where we will treat key events more like normal events, and just send them down the tree until handled. Currently, this doesn't exist; you need to do something a bit hacky, like have a custom edit: That said I'm going to coopt this as a tracking issue for this feature, which I'm calling "ambient focus"; there's some previous discussion here, for instance but I don't see a concrete issue. |
Global key (device event) capture should be optional, that shouldn't be enabled by default. It also may be detected as key logger by anti-virus programs. It can also cause hog unneccessary CPU in Windows. e.g. winit does that, and it eats CPU even though window is not visible or minimized.. |
yes you're right I've misread the issue, listening to key events globally is definitely not a case I've been thinking hard about, and certainly wouldn't be on the near-term roadmap. I could imagine some mechanism where druid apps could register platform-wide hotkeys, but I'd prefer to see some other mechanism for that.. |
Closing this for now. |
I am extremely new to druid, so I apologize if this isn't the right place for this.
The motivation is this issue.
Is global/unfocused key event capturing something that's supported in druid? I looked at the event_viewer example and it looks like it only works if the window (and more specifically the widget the controller is wrapped around) is in focus. it also appears that media key event capturing is spotty in Linux. (on my machine media keys aren't captured at all, on some machines it seems that the events are firing some times, but not always?)
Edit: After a quick glance at the gtk implementation for
window
, it looks like we're connecting key_press/key_release events at the window level, meaning we would only receive keyboard events while the window is in focus. Assuming that's true, I'm hoping this could be a place to discuss a design that supports for listening for events globally.The text was updated successfully, but these errors were encountered: