-
Notifications
You must be signed in to change notification settings - Fork 170
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
Support keyboard input for xdg-popups of layer-shell views #1779
Comments
As far as I understand xdg-popups, you are supposed to start a keyboard grab when the menu opens. Since wlroots handles that, I think that it will work, no matter what Wayfire does. |
I can repro with lxqt-panel and wayfire-git. Which is weird but at least we know it is a Wayfire bug. |
Coinicidentally, this was recently raised against labwc - labwc/labwc#1572 So it has the same problem. |
In fact ;) Only kwin_wayland and Hyprland are not affected, gonna open an issue at sway. |
PR #2277 seems to fix the problem for me, can someone confirm? |
Describe the bug
All menus should always get keyboard focus - there should only ever be one menu on the screen at any one time, and if one is shown, keystrokes should go to it. This does not happen in some cases under Wayfire.
To Reproduce
Add the following test widget to wf-panel:
test.cpp
test.hpp
Build and include the plugin in the panel config. Run the panel.
Click the "Test" button to open the menu. Use the up and down arrow keys when the menu is on screen - they should move the menu highlight, but they have no effect.
This can be fixed by including
gtk_layer_set_keyboard_mode (window->gobj(), GTK_LAYER_SHELL_KEYBOARD_MODE_ON_DEMAND);
in the create_window function in panel.cpp, but this does not completely fix the problem.If that line is included, then if the menu is opened with the mouse, then the menu does now get keyboard focus and can be navigated with the arrow keys. But if the menu is opened without using the mouse - I am using a DBus message sent from wayfire in response to a keyboard shortcut which then triggers the command handler in the plugin - then the menu opens but still does not have keyboard focus, because it is the action of clicking on a panel button with the mouse which requests keyboard focus.
The only way I have been able to get this situation to work is to modify the way the menu is opened so that before the menu opens, the panel is given exclusive keyboard focus, the menu then opens, and a handler is attached to the menu so that when it closes the exclusive keyboard focus on the panel is relinquished, which really cannot be the right thing to do!
As I understand it, there are no circumstances when a menu should not have keyboard focus, so I think Wayfire itself should ensure that this is the case whenever a menu is opened.
Wayfire version
0.7.5 from Debian bookworm
The text was updated successfully, but these errors were encountered: