Open amarakon opened 1 month ago
moverest
commented
1 month ago That is something I've looked into and unfortunately that behaviour is expected as the context menu loses focus when the keyboard input is taken over by wl-kbptr.
I have not found a way around it yet besides using the key bindings suggested in the README.
amarakon
commented
1 month ago That is something I've looked into and unfortunately that behaviour is expected as the context menu loses focus when the keyboard input is taken over by wl-kbptr.
Would there need to be patches for wlroots or the window manager to have the ability to make context menus not lose focus? Or is it handled by the graphical toolkit (GTK and QT)?
I have not found a way around it yet besides using the key bindings suggested in the README.
If I understand correctly, the key bindings in the README allow you to move the mouse manually with certain keys without hiding context menus. Is that right?
moverest
commented
1 month ago Would there need to be patches for wlroots or the window manager to have the ability to make context menus not lose focus? Or is it handled by the graphical toolkit (GTK and QT)?
Context menus are handled by the xdg-shell protocol and more specifically by its xdg_popup object. When the pop-up loses focus, it receives the popup_done event sent by the compositor. As such, we would need to patch the compositor for the context menu to not be dismissed.
If I understand correctly, the key bindings in the README allow you to move the mouse manually with certain keys without hiding context menus. Is that right?
Yes, that is the idea. It's not ideal, but that's the workaround I use.
Whenever there's a context menu visible, for example by right clicking something in a graphical user interface, launching wl-kbptr causes that context menu to hide itself, making you unable to use wl-kbptr to move the mouse pointer and click on the context menu. Is there some way I can make it so that context menus remain visible and clickable when wl-kbptr is launched?