Closed jlindgren90 closed 4 months ago
* Panel grabs focus from the active window at startup (but the active window's titlebar is still the active color)
This is intentional. If panels get activated when pressed, foreign-toplevel
minimize-raise action does not work, because the action logic relies on the target window being activated.
I haven't checked what other compositors / window-managers do and might be wrong with the approach, but nonetheless it is intentional.
* After switching focus back to another window, panel loses keyboard focus and clicking the applications menu does not grab focus (cannot type to search)
With https://github.com/labwc/labwc/pull/1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.
If you're talking about opening a panel-menu with a short-cut (without mouse) then, that's a different discussion. Quite frankly, I'm not sure what the right answer it to that. There are solutions of course, but none of them seem particularly clean or native to me.
This is intentional. If panels get activated when pressed,
foreign-toplevel
minimize-raise action does not work, because the action logic relies on the target window being activated.
Right, I agree the panel shouldn't get "activated" -- it shouldn't get focus at all though. Not until a menu is opened.
With labwc/labwc#1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.
That would certainly be an improvement. I'll try it out when I get a chance.
The ideal behavior, in my mind, would be what happens under X11 -- the panel get focus only when a menu is opened, and loses it/gives it up again when the menu is closed. I don't know the correct mechanism for this under layer-shell.
If you're talking about opening a panel-menu with a short-cut (without mouse) then, that's a different discussion. Quite frankly, I'm not sure what the right answer it to that. There are solutions of course, but none of them seem particularly clean or native to me.
qmpanel doesn't actually allow opening the menu via a shortcut currently. Maybe it should...
- Notifications are fine here with lxqt-notificationd with layershell support, did you try dunst or mako?
This could be a solution for notifications specifically, but I think the problem is more general -- X11 windows that have the "skip taskbar" hint set, are not skipped when using wlr-foreign-toplevel. Maybe something we could fix on the labwc side.
Maybe something we could fix on the labwc side
I don't think xwayland notifications will ever work fine. I used layershell also in its version 5 forlxqt-notificationd
. Placement and skip taskbar and switcher can be solved with rules but focus stealing which is really annyoing atm only in hyprland if I remember well.
<windowRule identifier="lxqt-notificationd" skipTaskbar="yes" skipWindowSwitcher="yes">
<action name="SnapToRegion" region="notifications"/>
</windowRule>
With https://github.com/labwc/labwc/pull/1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.
Click-to-focus seems to be working fine since https://github.com/labwc/labwc/pull/1594 actually. Thanks!
Maybe something we could fix on the labwc side
I don't think xwayland notifications will ever work fine. I used layershell also in its version 5 for
lxqt-notificationd
. Placement and skip taskbar and switcher can be solved with rules but focus stealing which is really annyoing atm only in hyprland if I remember well.<windowRule identifier="lxqt-notificationd" skipTaskbar="yes" skipWindowSwitcher="yes"> <action name="SnapToRegion" region="notifications"/> </windowRule>
There is also https://github.com/labwc/labwc/pull/1490 on the labwc side which could automatically create rules for specific xwayland window types.
Panel grabs focus from the active window at startup (it should not get focus until a menu is opened)
Panel does not give keyboard focus back to the active/top application after a menu is closed
Looks like we only ever set interactivity to on-demand in qmpanel (which is the way it should be in my opinion): https://github.com/jlindgren90/qmpanel/blob/631a7b9a6bcf7ed4c35cd1f9056b9d2d351bdc04/panel/mainpanel.cpp#L77
Any chance of verifying the two points above against the latest version for labwc
? We just merged six layer-shell related commits trying to sort out focus issues :smile: (mostly in response to feedback from the LXQt team - as well as obviously trying to handle layer-shell stuff in the most correct way possible).
Any chance of verifying the two points above against the latest version for
labwc
? We just merged six layer-shell related commits trying to sort out focus issues 😄 (mostly in response to feedback from the LXQt team - as well as obviously trying to handle layer-shell stuff in the most correct way possible).
It looks like qmpanel no longer grabs focus at startup with latest labwc master
, nice!
Focus is still not returning automatically to the topmost/active application when the panel menu closes.
It looks like qmpanel no longer grabs focus at startup with latest labwc
master
, nice! Focus is still not returning automatically to the topmost/active application when the panel menu closes.
On the topic of keyboard interactivity, the protocol says: “This setting is inherited by child surfaces set by the get_popup request.”
The behaviour you describe probably requires “none” when popup not open, and “exclusive” when pop up is open (rather than on-demand all the time)
Technically we may be able to force exclusive when popups are mapped (but feels like that goes against the protocol specification).
Alternatively the client could set exclusive before opening a popup. Some panels have done that (xfce4-panel and sfwbar IIRC).
Open to suggestions here.
The behaviour you describe probably requires “none” when popup not open, and “exclusive” when pop up is open (rather than on-demand all the time)
This sounds like the least ambiguous way to communicate the intent to the compositor, if perhaps a bit of a pain to implement on the panel side. If other panels are doing similar (switching to exclusive when opening a popup menu), I guess it is probably the way to go.
I see a similar issue with fancymenu (mainmenu would be the same I guess). It opens but no way to use keyboard, also after clicking around in the menu. We don't have yet own globalkeys working, but this opens it but is useless:
<keybind key="A-w">
<action name="Execute" command=" qdbus org.kde.StatusNotifierWatcher /global_key_shortcuts/panel/fancymenu/show_hide org.lxqt.global_key_shortcuts.client.activated"/>
</keybind>
Under kwin_wayland it works, but kwin doesn't respect keyboardactivation set by client.
I'm closing this since most of the issues have been fixed and the remainder are mentioned in the README now. Thanks all!
Keyboard focus:
Panel grabs focus from the active window at startup (it should not get focus until a menu is opened)(fixed by https://github.com/labwc/labwc/commit/6990ff713bc817fba28146617db4c78d843bb019)After switching focus back to another window, panel loses keyboard focus and clicking the applications menu does not grab focus (cannot type to search)(fixed by https://github.com/labwc/labwc/commit/a5fcbfaf720fc6c2486d850012215102e90e04bf)Panel does not give keyboard focus back to the active/top application after a menu is closed(fixed by 0f5747aa654d179749e38d9e6a4bf04d9ed623c5 and 326d04650beaed5313f20a8751bb8a622d93067c)Menu positioning:
Menus (including the applications menu, system tray icon menus, and the calendar popup) are aligned to the bottom of the screen, overlapping the panel(fixed by a940f5fbba61490e974f0322eb537b350aeafadf)Category submenus (e.g. "Multimedia" or "Network") are aligned to the bottom of the screen rather than the corresponding item in the (parent) applications menu.
In type-to-search mode (which shrinks the applications menu), the menu position does not adjust to stay aligned to the panel, leaving a large gap between the menu and panel.
When the panel is not focused, clicking on a system tray icon causes its menu to pop up in the center of the screen and have window decorations (titlebar etc.)(fixed with 631a7b9a6bcf7ed4c35cd1f9056b9d2d351bdc04)Micellaneous:
Notification popups (from xfce4-notifyd, running in XWayland mode) result in an unexpected "xfce4-notifyd" taskbar button(fixed by https://github.com/labwc/labwc/commit/7e419f7584f6e6c047204612119733d4a85e005f)Dragging the mouse cursor downward into the bottom-left corner of the screen results in the applications menu flickering in and out of "hover" state. Occasionally, it ends up non-hovered and clicking on it does nothing, even though the cursor is still in the corner of the screen.
Tested with: