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

listen for key events globally #1546

Closed
seeplusplus opened this issue Jan 22, 2021 · 4 comments
Closed

listen for key events globally #1546

seeplusplus opened this issue Jan 22, 2021 · 4 comments
Labels
architecture changes the architecture, usually breaking enhancement adds or requests a new feature

Comments

@seeplusplus
Copy link

seeplusplus commented Jan 22, 2021

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.

@cmyr
Copy link
Member

cmyr commented Feb 17, 2021

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 Controller at the root of the tree that takes focus, and that then sends the events where you want them. Unfortunately it can't send them using the normal Event mechanism, since druid will check to see if a widget has focus before it delivers a key event. 😒

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.

@cmyr cmyr added enhancement adds or requests a new feature architecture changes the architecture, usually breaking labels Feb 17, 2021
@Ciantic
Copy link
Collaborator

Ciantic commented Feb 17, 2021

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..

@cmyr
Copy link
Member

cmyr commented Feb 17, 2021

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..

@PoignardAzur
Copy link
Collaborator

Closing this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture changes the architecture, usually breaking enhancement adds or requests a new feature
Projects
None yet
Development

No branches or pull requests

4 participants