In 9e3785f8cd, a heuristic was added to assume that NORMAL and DIALOG
window types were always focusable. (This was before we had the "offer
focus" mechanism in place.)
However, we should still call wlr_xwayland_surface_offer_focus() for
these views, in case they actually don't want focus. (This is uncommon
but has recently been seen with WeChat popups, which have both NORMAL
and UTILITY type.)
To make this possible, refine view_wants_focus() to return either
LIKELY or UNLIKELY for Globally Active input windows. This decouples
the question of "should we try to focus this view" from the actual
mechanism used to do so.
For longer cases, factor out the logic to new functions.
For very short cases, just move the declaration before the switch.
v2: in one case, replace the switch with if/else.
Offer focus by sending WM_TAKE_FOCUS to a client window supporting it.
The client may accept or ignore the offer. If it accepts, the surface will
emit a focus_in signal notifying the compositor that it has received focus.
The compositor should then call wlr_xwayland_surface_activate(surface, true).
This is a more compatible method of giving focus to windows using the
Globally Active input model (see wlr_xwayland_icccm_input_model()) than
calling wlr_xwayland_surface_activate() unconditionally, since there is no
reliable way to know in advance whether these windows want to be focused.
v2: add caution not to use view_offer_focus() directly
v3: remove obsolete comment
This commit moves the check against server->input_mode from the callers
of desktop_focus_view() into desktop_focus_view() itself. This
eliminates code duplications and makes it harder to mess up the window
stacking order while window switching.
I also added the same check in view_minimize() so that minimize requests
from panels never messes up the window stacking order (I think only this
should be described in the release note).
Eliminate corner extents and instead use cursor position to map SSD
borders and extents to corner contexts, with a size configurable by the
<resize><cornerRange> parameter. This simplifies extent handling,
eliminates bugs in the detection of corner context, and allows users to
expand corner targets if they wish.
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
Before this commit, `top` layers were hidden whenever there is a
fullscreen window in the corresponding output.
With this commit, `top` layers are hidden only when there is a fullscreen
window without other windows above it in the corresponding output.
A caveat is that `bottom` layer is still always hidden by a fullscreen
window.
Add custom field with subset of printf style formatting
to replace the original field formats.
Example:
<windowSwitcher preview="no" outlines="no" allWorkspaces="yes">
<fields>
<field content="custom" format="foobar %b %3s %-10o %-20W %-10i%t" width="100%" />
</fields>
</windowSwitcher>
Mono space font recommended. May need OSD width adjusted
Co-authored-by: @Consolatis (based on work done by them)
...to give keyboard focus to layer-shell clients if exclusive or on-demand
interactivity is set, so that menu popups can be navigated with the
keyboard. This still only works if the client is in top (or overlay)
layers. Support for bottom and background to be done as a separate patch
set.
Revert 06b19f0 to process layer-shell subsurfaces in
`cursor_button_press()`, but only when their parent layer-shell surface
has keyboard interactivity.
Fix bug in `get_cursor_context()` which resulted in layer-surfaces not
being detected correctly.
Background:
Commit 06b19f0 (issue #1131) disabled processing of layer-shell
subsurfaces in cursor_button_press() because when pressing a task in
Waybar (Gtk panel using layer-shell subsurfaces) the foreign-toplevel
minimize-raise action did not work correctly as the action logic relied on
the recipient window being activated and by clicking on the panel, the
panel itself was both surface-focusd and activated (and thus the window
de-activated).
The un-intended consequence was that by not responding to layer-subsurface
cursor buttons presses, layer-shell clients (such as panels) were not
given keyboard focus if they indeed wanted it by setting exclusive or
on-demand keyboard interactivity.
The good news is that that following @jlindgren90's refactoring (various)
the only place where we call `view_set_actived()` is in
`focus_change_notify()` in `seat.c` and we now only do it for views
(bb8f0bc).
Another side-effect (positive) of 06b19f0 was that a Waybar dnd bug was
fixed (pointer-serial-number validation failure).
Have tested with sfwbar, waybar and tint (test-panel) the following
results:
- Minimize-raise works even when on-demand keyboard interactivity is set
- Keyboard interactivity is given popup-menus (sfwbar and tint) when the
panels are in the top layer (support for bottom will be as a separate
patch set)
- Waybar dnd still works (even when hard-coding keyboard-interactivity)
References:
- bb8f0bc960
- 40ce95a68c/src/seat.c (L481-L483)
- 40ce95a68c/src/dnd.c (L24)
- https://github.com/johanmalm/tintFixes: #1572
Also share common config option (rc.window_switcher.criteria) in osd.c and
desktop.c to make sure the window lists are always consistent.
Configure with `<windowSwitcher allWorkspaces="yes|no">`
This is undesired when a focusable popup (e.g. applications menu) of an
unfocusable view (e.g. XWayland panel) is closed.
This reverts commit f6e3527767.
We already allow some xwayland-unmanaged surfaces to take focus on map,
if indicated by wlr_xwayland_or_surface_wants_focus(). But once these
surfaces lose focus, they never regain it again.
Add desktop_focus_view_or_surface() and call it in the appropriate
places to allow these views to regain focus in the usual ways (e.g.
clicking on them or focus-follows-mouse).
Commit 7e72bf975f changed behavior to not automatically focus xwayland
views using the "Globally Active" input model (WM_HINTS.inputs = false
but WM_TAKE_FOCUS listed in WM_PROTOCOLS).
One undesired side effect of this change is that when a dialog is
closed, the parent window is not re-focused if "Globally Active". This
issue is seen for example with JDownloader. It can be solved taking a
similar approach to what is done for unmanaged xwayland views: allow
automatic re-focus between views sharing the same PID.
Note that it's difficult to completely solve all of the focus issues
with Globally Active views without proper WM_TAKE_FOCUS support.
Implementing proper support is difficult since it requires wlroots
changes and would also mean waiting for a message round-trip in
desktop_focus_topmost_view().
Fixes (partially): 7e72bf975f
("view/xwayland: avoid focusing views that don't want focus")
We were checking for a locked session in desktop_focus_view(), but there
are several other call sites of seat_focus_surface() which were missing
such a check. Any one of those could cause the lock screen to lose focus
(making the session impossible to unlock) or another surface to gain it
(breaching the session lock).
To fix the issue, make any call to seat_focus_surface() no-op when the
session is locked. Add a specific seat_focus_lock_surface() function
which is the only way to bypass the check and is called only from
session-lock.c.
... especially regarding whether a (view *) parameter may be NULL. It's
confusing when some functions accept NULL and others don't, and could
trip someone up.
I'm partly to blame for the inconsistency, since (if memory serves) I
added view_is_tiled() and view_is_floating(), which do accept NULL.
In detail:
- Make view_is_tiled() and view_is_floating() no longer accept NULL.
- Rename view_isfocusable -> view_is_focusable for consistency with
other view_is_ functions.
- Eliminate view_inhibits_keybinds() as it only existed to safely accept
NULL and check a single flag, which can be checked directly.
- Add assert(view) to remaining public view_ functions to catch
accidentally passing NULL.
- Inline inhibit_keybinds() into view_toggle_keybinds(). It is closely
related and not called from anywhere else; inlining it allows
eliminating an extra assert() which is now impossible.
Some X11 applications (MATLAB is known to be one) apparently still use
the outdated "globally active" input focus model, in which they declare
they don't want the window manager to give them input focus, but expect
to be able to take it explicitly themselves via XSetInputFocus().
Such applications are not a good fit for the Wayland world, and may have
issues even with remotely modern X11 window managers that prevent such
"focus stealing". Labwc certainly doesn't (and won't) allow it. However,
to avoid breaking such applications entirely, let's still allow the user
to give focus by clicking in the window.
For the sake of applications that legitimately don't want to be given
input focus (such as taskbars or other "panels"), we still don't give
focus to them automatically when another view is closed, and they aren't
shown in Alt-Tab.
This reverts commit cae96b0cce.
XWayland views can self-declare that they don't want keyboard focus via
the ICCCM WM_HINTS property. Most of the logic is already in place to
avoid giving focus to such views (e.g. taskbars).
Add a couple of missing pieces to make this work:
- Hook up view_isfocusable() to look at WM_HINTS for XWayland views
- Adjust desktop_focus_topmost_mapped_view() to skip unfocusable views
- Connect to wlr_seat_keyboard_state's focus_change event.
- Add view_from_wlr_surface(), which does what the name says.
- Use focus_change event along with view_from_wlr_surface() to update
server->focused_view and set SSD states via view_set_activated().
- Eliminate desktop_focused_view() since server->focused_view should be
reliably up-to-date now.
- Eliminate view_focus/defocus() since we can now just call
seat_focus_surface() directly.
Make desktop_focus_view() always switch to the workspace containing the
view being focused. It doesn't make much sense for an invisible view to
have the keyboard focus.
Also add an optional "raise" parameter to desktop_focus_view(). This
allows the common pattern of desktop_focus_view() + view_move_to_front()
to be reduced to a single function call.
Our current approach to handling the focused/active view is a bit
confusing. In particular, it's hard to be sure when server->focused_view
is or isn't in sync with the real wlroots keyboard focus.
Try to clean things up a bit. In particular:
- Add comments to server->focused_view and desktop_focused_view() to
clarify that they should match, but it's not guaranteed.
- desktop_focused_view() now prints a warning if it detects that
server->focused_view is out of sync. We should keep an eye out for
this warning, and if we see it, try to figure out why it happened.
- For consistency, use only "focus/defocus" as the verbs in function
names rather than "activate". This is a bit arbitrary, but the idea is
that focus is the primary action while the active/inactive state is a
side effect.
- view_focus/defocus() replace view_set_activated() and now update both
focus and active/inactive state, to try to keep them in sync.
- Add comments at view_focus/defocus() to warn against calling them
directly (we should generally call the desktop.c functions).
- desktop_focus_view(NULL) is now forbidden and is no longer handled as
a special case to clear the focus. This was (at least to me) a
surprising behavior and caused trouble when working on another change.
- To maintain existing behavior, desktop_focus_topmost_mapped_view() now
explicitly clears the focus if there are no mapped views.
There should be no behavioral change here.
...to reduce code duplication.
The function populates an array with views which meet any set of critera
from:
- current-workspace
- no-always-on-top
- no-skipWindowSwitcher (window-rule)
Make src/osd.c use this new interface. Note that always-on-top views are
still filtered out from the window-switcher and that desktop_cycle_view()
needs to be re-worked before always-on-top views can be opted in.
