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.
This patch also changes the semantics of scaled_icon_buffer: rather than
calling scaled_icon_buffer_set_app_id() every time an app_id is set, we
can now call scaled_icon_buffer_set_view() just once so that multiple
scaled_icon_buffers bound to a window are automatically updated when an
app_id is set or new icon is set via xdg-toplevel-icon-v1.
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
Ref: 1133bc15ceb2c2bcb6df692acda6bfa39a292ab5
("Transparently restack xwayland surfaces")
In addition, MR 4772 makes sure the hidden windows are stacked at the
bottom, just like what we did with XWAYLAND_VIEW_HIDDEN.
The view->impl functions do not directly support mapping a view while
minimized. Instead, mark it as not minimized, map it, and then minimize
it again.
Fixes: #2627
Before this commit, when a normal window is raised, xwayland thought it's
above always-on-top (AOT) windows even though it's actually below AOT
windows in the scene. This means mouse scroll events may be unexpectedly
sent to normal windows below AOT windows even when the cursor is hovering
over a AOT window.
So this commit fixes it by notifying the correct stacking order (where AOT
windows are placed above normal windows) to xwayland every time the
stacking order is updated.
Other benefits of this commit are:
- It makes the code more readable and predictable by aggregating logic
about stacking order management in xwayland (e.g. shaded windows or
windows in other workspaces should be notified to xwayland as being
placed at the bottom).
- As server->last_raised_view is removed in the previous commit, we were
notifying the stacking order to xwayland every time a window with dialog
windows is clicked (not when clicking a topmost window without dialogs,
due to some optimization in wlroots). This commit fixes this by caching
the window stacking order in xwayland_view->stacking_order and notifying
it to xwayland only when it's updated.
We were skipping in view_move_to_front() if the raised view is already
cached as server->last_raised_view. But this was prone to bugs that
windows cannot be raised even though they are actually not placed at the
top in the scene.
This happened when a window is mapped but view_move_to_front() is not
called in view_impl_map() for some reason. Example cases were:
- a window is minimized before being mapped (#2627)
- a window is mapped while window switcher is active (#2629)
Also, this problem was the root cause of #1640 and #2582, though they are
already fixed.
Therefore, this commit removes server->last_raised_view. In order to
eliminate unnecessary communications between labwc and xwayland (ref:
db591d1), I'll introduce another caching mechanism in the next commit.
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).
...when app_id is NULL.
Make sure view_get_string_prop() never returns NULL because it is so easy
to misuse. Same for the respective xwayland/xdg impl methods in case
anyone decides to (incorrectly) call them directly in future.
Fixes: #2453
The previous revert fixed the problem of stuck modifier keys with
keybinds in Blender, but made Firefox show its menu bar with Alt-*
keybinds. This is fundamentally inevitable due to the limitation of
wayland protocol, but at least for the default Alt-Tab keybind for
window switcher, we can mitigate this problem by clearing the keyboard
focus when the window switcher is activated. This is what KWin does, and
we decided to follow that.
So in this commit, keyboard and pointer focus are temporarily cleared
while Move/Resize, window switcher and menu interactions and restored
after them. We slightly deviate from KWin as KWin doesn't clear the
keyboard focus while Move/Resize, but it solves our existing problem
that Firefox shows its menu bar after dragging it with default Alt-Drag
mousebind, and this is what Mutter does.
We considered other solutions, but they don't work well:
1. Send wl_keyboard.{leave,enter} every time keybinds/mousebinds are
triggered. This solves the Firefox's menu bar problem, but that
sounds like a workaround and sending unnecessary events every time is
not desirable.
2. Send release events for both modifiers and keys even when they are
bound to keybinds. This is what Mutter is doing, but it looks like an
implementation issue and violates wayland protocol.
We have several wlr_output_* functions which are just wrappers around
corresponding wlr_output_state_* functions and don't actually touch the
wlr_output itself. These probably made some sense historically, but IMHO
they are just confusing now. So remove them and call wlr_output_state_*
directly.
Rename wlr_output_commit() (still useful) to output_state_commit().
...to replace padding.{width,height} to minimize breaking changes with the
visual appearance of the titlebar.
With the diverging labwc specification for the titlebar (listed below)
we have to choose between (a) not supporting the padding.{width,height}
option which exist in many extant Openbox themes to keep titlebar height
(almost) the same; or (b) making the allocated button areas much smaller
and not keeping the default hover going all the way to the edges. All in
all it just seems a lot simpler and cleaner to break this link to the
openbox spec.
Examples of previous change driving the requirement for this change:
- SVG and PNG support which often results in large icons with hover
effects.
- Theme option window.button.{height,width}
- Larger default areas for icons (26x26)
In way of an example, Numix theme sets a padding.height of 6 which would
have resulted in a titlebar 12px taller without this change.
In the case of an initially-maximized view which is taking a long time
to un-maximize (seen for example with Thunderbird on slow machines), we
may end up in handle_configure_timeout() with an empty pending geometry.
In that case we have no great options (we can't center the view since we
don't know the un-maximized size yet), so set a fallback position.
v2: check wlr_box_empty() before comparing pending and current
Fixes: #2191
The default `titleLayout` is updated to `icon:iconify,max,close` which
replaces the window menu button with the window icon.
When the icon file is not found or could not be loaded, the window menu
icon as before is shown.
The icon theme can be selected with `<theme><icon>`.
This commit adds libsfdo as an optional dependency. `-Dicon=disabled` can
be passsed to `meson setup` command in order to disable window icon, in
which case the window icon is always replaced with a window menu button.
I intended to fix this quite some time ago but didn't get around to it.
I don't think there's any good reason why we need to un-fullscreen a
view when its output is disconnected. We can handle it the same as a
maximized view, and move it to a new output (remaining fullscreen) or,
if all outputs are disconnected, just leave it as-is.
This is helpful for a media-center use-case, where you have just one
view (e.g. Kodi) fullscreen all the time, but the TV might appear to be
disconnected if you switch it to a different source.
Tested with a couple different scenarios:
1. Single output disconnected and re-connected: view stayed fullscreen.
2. Secondary output disconnected: view stayed fullscreen but moved to
the primary output, and the layer-shell panel on that output was
hidden as expected. When the secondary output was re-connected, the
view was moved back (still fullscreen) and the panel on the primary
appeared again.
Fixes: #864
Adds following settings:
<placement>
<policy>cascade</policy>
<cascadeOffset x="40" y="30" />
</placement>
"Cascade" policy places a new window at the center of the screen like
"center" policy, but possibly shifts its position to bottom-right so the
new window doesn't cover existing windows.
The algorithm is copied from KWin's implementation:
df9f8f8346/src/placement.cpp (L589)
Also added some helper functions to manipulate `wlr_box`.
Currently, initially maximized (or fullscreen) xdg-shell views exhibit
one of two issues:
- some (e.g. GTK and Qt apps) paint an initial frame un-maximized
(before the "map" event) and only maximize in a later commit
- others (e.g. foot) maximize immediately without flicker, but never
store a valid natural size, so we end up using a fallback (640x480)
Under KWin, neither of these issues occur, so I looked into what labwc
is doing wrong. It seems that:
- wlroots internally sends an initial configure event with a size of
0x0 to all xdg-shell views. This requests the client to set its own
preferred (a.k.a. natural) size.
- For an initially maximized/fullscreen view, the initial configure
event should contain the maximized/fullscreen size rather than 0x0.
In labwc, this means we have to call wlr_xdg_toplevel_set_size()
earlier, i.e. from the new_surface event. Tracing with WAYLAND_DEBUG
shows that the initial configure event now has the correct geometry,
matching KWin behavior. With this change, GTK and Qt apps no longer
paint an incorrect un-maximized frame.
- However, this means that all xdg-shell views now suffer from the same
issue as foot, where we never receive a commit with the un-maximized
(natural) geometry. The correct way to get the natural geometry seems
to be to wait until we want to un-maximize, and send a configure
event of 0x0 at that point.
Sending a configure event of 0x0 when un-maximizing is a bit annoying as
it breaks some assumptions in labwc code. In particular:
- view->natural_geometry may now be unknown (0x0), requiring various
wlr_box_empty() checks sprinkled around. I added these in all the
obvious places, but there could be some code paths that I missed.
- Positioning the newly un-maximized view within view_maximize() no
longer works since we don't know the natural size. Instead we have to
run the positioning logic from the surface commit handler. This
results in some extra complexity, especially for interactive move.
See the new do_late_positioning() function in xdg.c.
Some TODOs/FIXMEs (non-blocking in my opinion):
- The view_wants_decorations() check is now duplicated in both the
new_surface and map event handlers. I'm not sure if this is necessary
but it seemed like the safest approach for now. More testing would be
nice, particularly with various combinations of config and client SSD
preferences.
- Aside from the interactive move case, the "late positioning" logic
always centers the view when un-maximizing, and does not invoke any
of the smart placement logic. If we want to invoke smart placement
here, I'd appreciate someone with more knowledge of that code to take
a look and figure out how to do that correctly.
Thonny (Python IDE made with Tk) may set the window geometry to 1x1 and
maximizes the window before mapping. This set `view->natural_geometry`
to 1x1, so labwc tried to restore the window geometry to it on
unmaximize, causing validation errors in `ssd_update_geometry()` as its
width and height are smaller than `LAB_MIN_VIEW_{WIDTH,HEIGHT}`.
This commit fixes it by not allowing geometries smaller than
`LAB_MIN_VIEW_{WIDTH,HEIGHT}` in `view->natural_geometry`.
