For views that are initially maximized or fullscreen and have no
explicitly specified position, we need to center the stored natural
geometry, or the view may end up partially offscreen once unmaximized/
unfullscreened.
X11 clients may request to be initially fullscreen or maximized by
setting hints in the _NET_WM_STATE property. For some reason, we are
currently only honoring fullscreen requests but not maximize.
The fixes issues with GTK apps (notably Firefox, but others as well)
not starting maximized.
There is a remaining issue that the window position may not be set
correctly after unmaximizing. This will be fixed in a follow-up commit.
When a parent view has multiple sub-views (dialogs) visible, focusing
one sub-view ought to raise it above the others. This doesn't currently
happen -- focusing a sub-view raises the whole group of views together,
but has no effect on the relative stacking order between them.
This seems like a simple oversight in xdg/xwayland_view_move_to_front()
that's pretty easy to fix.
Add FIXMEs to deduplicate this logic in future.
Tested with HomeBank: the Import dialog pops up an additional Open File
dialog, which before this change appears behind the Import dialog (and
clicking on it does not raise it to the front). After this change, the
Open File dialog appears in front as expected.
Assume that Globally Active xwayland views do want focus if they want
window decorations (according to _MOTIF_WM_HINTS). This is a stop-gap
fix to ensure that various applications (mainly Java-based ones such as
IntelliJ IDEA) get focus normally and appear in the window switcher. It
would be better to match based on _NET_WM_WINDOW_TYPE instead, but that
property isn't currently available through wlroots API.
Fixes (partially): 7e72bf975f
("view/xwayland: avoid focusing views that don't want focus")
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")
This allows identifying XWayland views using the ICCCM "Globally Active"
input model. Later commits will improve handling of these views.
No functional change in this commit.
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.
The unmap() handlers should only call desktop_focus_topmost_view() if
the unmapped view was the focused view. Unmapping a view that was not
focused should not change the focus.
I expect this rarely had any effect in practice; it would only matter in
a focus-follows-mouse config where some view other than the one on top
was focused. But it still seems better to fix.
Rather than repeating the logic in two places, create a small
view_impl_unmap() helper. Perhaps more common "unmap" logic could be
moved there in future.
Check that wlr_layer_surface_v1_from_wlr_surface() doesn't return NULL.
This may be unnecessary with wlroots 0.16 (not sure) but doesn't hurt
and reduces the delta to the wlroots-0.17 branch.
If an xwayland-unmanaged surface was focused belonging to the same
application as the focused view, allow the view to remain active. This
fixes an issue with menus immediately closing in some X11 apps (try
LibreOffice with SAL_USE_VCLPLUGIN=gen).
Fixes: 4028a9482f
("seat: use focus_change event to update focused/active view")
Use the same fix/workaround as in output_update_for_layout_change() to
make sure that the cursor is also visible after (re-)enabling an output
in handle_output_power_manager_set_mode().
This was forgotten in 65bd32d625
Reported-by: @jonhiggs (thanks)
Also stop treating the synthetic layout change sym as modifier
but still prevent it from being added to the set of pressed keys.
Additionally slightly reformat the code.
... 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.
Before this patch, we were storing the key in our pressed set
and didn't remove it which in turn caused all further keybinds
to fail. The behavior was dependent on the exact flow of press
and release events and was most obvious when using
XKB_DEFAULT_OPTIONS=grp:alt_shift_toggle
We now simply treat it as a modifier and thus do not store it
in the pressed set.
Fixes: #1129
The modifiers can be used in keybinds via M-key and H-key
Additionally adds support for:
- Mod1 (same as A)
- Mod3 (same as H)
- Mod4 (same as W)
- Mod5 (same as M)
This is compatible with the format used by Openbox.
(http://openbox.org/wiki/Help:Bindings#Syntax)
Mod2 (NumLock) and Caps are still not supported due to
their locking behavior but could theoretically be added.
Fixes: #1061
Currently, if the output layout changes while the session is locked,
the lock surfaces may end up wrongly positioned, which looks bad and
may reveal some of the user's workspace underneath.
To prevent this, re-align the scene trees and reconfigure the lock
surfaces when the output layout changes.
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.
Replace action_str_from_arg() and action_get_first_arg() with
action_get_str().
Two reasons:
- This optimization reduces neither LOC nor amount of work done during
the arguments processing, but requires two additional functions.
- Logging only the first argument of an action creates an illusion that
only one argument was given. Instead of confusing the user just log
the fact that the action is being handled.
Introduce function action_get_arg() and a set of thin wrappers around
it. This function is responsible for finding the argument and checking
it's type, while the wrappers only to do the necessary type casting.
Features such as icons, gradients and drop-shadows were declined in the
early phases of the project to focus on designing the fundamental building
blocks well without pressure to implement additional features which may
have compromised good design decisions.
As a core team we are not against these features per se other than when
they sacrifice the ability to run well on low spec hardware, or
disproportionately increase code complexity and long term maintenance
burden.
xsurface->data is presumed to be a (struct view *) if set, so it must be
left NULL for an unmanaged surface. Otherwise view_from_wlr_surface()
may return a (struct xwayland_unmanaged *) where a (struct view *) was
expected, leading to a crash.
valgrind backtrace:
Invalid read of size 1
at 0x48F8FFC: wlr_scene_node_set_enabled (wlr_scene.c:903)
by 0x124C9F: ssd_set_active (ssd.c:323)
by 0x124C9F: ssd_set_active (ssd.c:318)
by 0x124C9F: view_set_activated (view.c:215)
by 0x118851: focus_change_notify (seat.c:353)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x48FC8F2: wlr_seat_keyboard_enter (wlr_seat_keyboard.c:298)
by 0x119E60: seat_focus.lto_priv.0 (seat.c:473)
by 0x1248FD: seat_focus_surface (seat.c:491)
by 0x1248FD: unmanaged_handle_map (xwayland-unmanaged.c:51)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x490FC91: surface_commit_state (wlr_compositor.c:499)
by 0x56A24F5: ffi_call_unix64 (unix64.S:104)
by 0x569EF5D: ffi_call_int.lto_priv.0 (ffi64.c:673)
Address 0xa0e15ff30788b68 is not stack'd, malloc'd or (recently) free'd
Fixes: 4028a9482f
("seat: use focus_change event to update focused/active view")
