-
Notifications
You must be signed in to change notification settings - Fork 180
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
Sending keyboard modifier state to inactive and layer-shell views with mouse clicks #891
Comments
I can only agree with you. Regarding one of your questions, I have already opened an issue here: swaywm/wlr-protocols#32 You can get normal keyboard focus if you set your layer-shell surface to be keyboard interactive but add Regarding modifiers, this is more or less the design of wayland. There is yet another open issue: swaywm/wlr-protocols#31 The second issue is more about keyboard layout but ctrl/alt/etc are very similar (because they are modifiers too). |
Hi, thanks for the responses; I've added my comment on swaywm/wlr-protocols#32. I'll experiment more with using I believe my second issue is more with the click-to-focus behavior currently in Wayfire (it only works if no modifiers are pressed); is there a specific reason (beside difficulty in matching with a |
I believe we have fixed what we can in Wayfire, the rest is up to wlr-layer-shell |
Hi,
I'm opening this as a question, since this has become a complicated problem for a simple issue :)
My main problem is detecting if one of the modifier keys are pressed during a mouse click. This does not seem to work for non-focused views, including layer-shell views without the keyboard-interactivity option set.
E.g. cairo-dock has the feature where holding the shift key while clicking on the icon of a running app starts a second instance. This does not work on Wayfire, since the fact that shift is pressed is not reported. Separately, Ctrl-click on a currently unfocused view does not work (e.g. open a link in a new tab on Firefox).
After a bit of investigating, I see two causes:
Keyboard focus for layer-shell surfaces is too restricted in my opinion. If a layer-shell surface is on the top layer, it either grabs all keyboard events or nothing (depending whether keyboard interactivity is set ). This makes sense for views in the overlay layer, such as a lock screen, but I think there is rationale for layer-shell views that behave similarly to "always-on-top" views, i.e. allow the keyboard focus to be lost. (alternatively, a layer-shell surface could set / unset keyboard interactivity whenever the pointer enters / leaves, but that goes against the typical behavior for keyboard focus). I believe any change here would require changing the protocol definition -- I can open a separate issue for this on wlr-protocols.
Non-focused views do not receive active modifiers with mouse clicks and also, setting keyboard focus on click only works if no modifiers are pressed. This is true for non-layer-shell views as well, so left-clicking on a view sets the focus, but e.g. clicking with shift or ctrl pressed will not, since that does not match the focus change binding here. In this case, the view receives the mouse click, but not the state of the modifier (since it never receives keyboard focus). This can be tested e.g. with Firefox, where ctrl + click should open a link in a new tab, but this does not work if Firefox is not the active view.
Let me know if I can provide more info or examples. So far, I've made a hack that always sends modifiers to layer-shell surfaces, mostly fixing my issue with shift-click on cairo-dock, but I don't think it's a good idea for general usage.
Thanks!
ps Related issues:
#640
#657
The text was updated successfully, but these errors were encountered: