You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To Reproduce
See Python code below. It creates a layer-shell view with buttons to toggle keyboard-interactivity + a separate button below the text entry ("Release keyboard") which tries to "lose" keyboard interactivity by (1) switching to NONE; (2) waiting 500 ms (to make what's happening more visible); and (3) switching back to ON_DEMAND
In any case when keyboard-interactivity is switched to ON_DEMAND, the layer-shell surface grabs keyboard focus.
Expected behavior
When clicking on "Release keyboard", the layer-shell surface should stay unfocused.
(Note: I'm unsure what should happen when clicking the "On demand" button; on the one hand, a mouse click should lead to keyboard focus; on the other hand, even in this case, switching to ON_DEMAND happens after the mouse click finished. In any case, this is not relevant to my use case and I'm fine with any behavior)
Use case
Primarily, I use ON_DEMAND to be able to register modifier + click on a layer-shell surface (while using standard GTK API). This requires ON_DEMAND to be the default state. I do want to "lose" the keyboard focus in specific cases: (1) when a menu is closed (e.g. by ESC or wf-shell::toggle_menu); (2) when triggering scale via IPC (e.g. see here).
So far I've only tested with my Python example and gtk-layer-demo. Since it avoids calling refocus in a lot of cases, it can have further, unintended consequences. One thing to note is that this results in clicking the "On demand" button also not grabbing focus which can be counter-intuitive in some cases.
Describe the bug
Per here, this is not intended.
To Reproduce
See Python code below. It creates a layer-shell view with buttons to toggle keyboard-interactivity + a separate button below the text entry ("Release keyboard") which tries to "lose" keyboard interactivity by (1) switching to NONE; (2) waiting 500 ms (to make what's happening more visible); and (3) switching back to ON_DEMAND
In any case when keyboard-interactivity is switched to ON_DEMAND, the layer-shell surface grabs keyboard focus.
Expected behavior
When clicking on "Release keyboard", the layer-shell surface should stay unfocused.
(Note: I'm unsure what should happen when clicking the "On demand" button; on the one hand, a mouse click should lead to keyboard focus; on the other hand, even in this case, switching to ON_DEMAND happens after the mouse click finished. In any case, this is not relevant to my use case and I'm fine with any behavior)
Use case
Primarily, I use ON_DEMAND to be able to register
modifier + click
on a layer-shell surface (while using standard GTK API). This requires ON_DEMAND to be the default state. I do want to "lose" the keyboard focus in specific cases: (1) when a menu is closed (e.g. by ESC or wf-shell::toggle_menu); (2) when triggering scale via IPC (e.g. see here).Wayfire version
git 44e1fa9
Test code
The text was updated successfully, but these errors were encountered: