xwayland: support _NET_WM_SKIP_PAGER and ignore WM_HINTS.input for Alt-Tab

[jlindgren90]

Related to issue #1130 and discussion on #1137.

Since 7e72bf975fb65c8290b398d21b2ad9d87a22880f, XWayland views that set WM_HINTS.input=false are skipped in the Alt-Tab pager. This behavior matches Openbox; however, it is inconvenient when dealing with some XWayland applications that set WM_HINTS.input=false incorrectly (example: MATLAB).

(WM_HINTS.input=false means that a client either "never expects keyboard input" (No Input model) or "wants to prevent the window manager from setting the input focus to any of its windows" (Globally Active input model). See ICCCM section 4.1.7.)

In the (relatively) newer Extended Window Manager Hints spec, there is a _NET_WM_STATE_SKIP_PAGER hint which is more narrowly tailored to exclude a view from the Alt-Tab list. If we support this hint, we could probably ignore WM_HINTS.input for the purpose of Alt-Tab.

In my opinion, we should still not focus views that set WM_HINTS.input=false automatically (e.g. when another view that was on top is closed/minimized). In my workflow, it trips me up when I close a window and the taskbar gains focus instead of the window underneath. It takes a second to figure out "where did the keyboard focus go?"

[Consolatis]

I close a window and the taskbar gains focus instead of the window underneath. It takes a second to figure out "where did the keyboard focus go?"

The taskbar you are using doesn't support the layershell protocol? That one has a keyboard_interactivity = None setting which prevents that.

[jlindgren90]

The taskbar you are using doesn't support the layershell protocol? That one has a keyboard_interactivity = None setting which prevents that.

Right, I am still using qmpanel under XWayland since I have not yet found a feature-compatible replacement that uses layershell.

More generally, several of the applications I use regularly (particular Qt-based ones) still have issues with native Wayland and so I am focusing on getting things usable in XWayland mode for now, as a transitional step. At this point, it's mostly minor issues that still prevent labwc from being a drop-in replacement for Openbox+Picom, while continuing to run an X11-based desktop otherwise. I think it's nice to have this as an option, rather than doing an all-at-once X11 -> native Wayland switchover.

[johanmalm]

We could consider doing some window-rule for xwayland-window-types in line with sways approach

https://github.com/swaywm/sway/blob/8a8fb76ec1d0b9a269b86688cff419201d1e6f62/sway/criteria.c#L114-L129 https://github.com/swaywm/sway/blob/8a8fb76ec1d0b9a269b86688cff419201d1e6f62/sway/desktop/xwayland.c#L24-L36

Have thought about this before, but never had a need :smile:

[Consolatis]

Also related: some generic noFocus window rule property. It was requested before, as far as I remember for utilities like Conky and lxpanel in wayland mode (but without layershell support).

[jlindgren90]

Openbox appears to also consider _NET_WM_WINDOW_TYPE for the Alt-Tab switcher (_NET_WM_WINDOW_TYPE_DOCK is excluded for example).

[johanmalm]

Openbox appears to also consider _NET_WM_WINDOW_TYPE for the Alt-Tab switcher (_NET_WM_WINDOW_TYPE_DOCK is excluded for example).

Sway uses this for their view-impl wants_floating method, so I'm guessing with should be able to implement this type of logic without wlroots changes.