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
On a slow mechine or heavy load, we sometimes see de-synced SSD with
Thunderbird windows when shrinking it. Here's how it happened:
1. Labwc sends a configure event.
2. The configure event timeouts and labwc resets view->{pending,current}
with the old geometry.
3. Thunderbird updates the toplevel window geometry and the toplevel
surface size, but not the subsurface size. Then it sends a commit.
4. Since now the committed window geometry and view->pending are
different, the workaround for Qt apps is applied and the whole surface
extent is set to view->current. Thus SSD stays in the old geometry.
5. Thunderbird finally updates the subsurface size.
So, this commit fixes this conflict between Thunderbird and the workaround
for Qt apps by using the toplevel surface size instead of the whole
surface extent to update view->current.
If a client times out responding to a configure request then the
handle_configure_timeout() callback is run. This cleans up the pending
state and moves the view to the pending location, but keeps the current
size. The idea is to stop slow applications causing too much lag when
the user manipulates the window. This callback used
view_impl_apply_geometry() to actually apply the changes.
view_impl_apply_geometry() contains some heuristics to detect if we're
resizing a window from the top, left, or top-left, and if so to do the
expected behaviour of keeping the window's bottom/right corner in the
same place. However, that code was erroneously triggering in the case
when the user requests to change a window from maximized to fullscreen
but the client times out on the configure request.
handle_configure_timeout() decides to enact the movement of the window
but keep its size at the old size and tells view_impl_apply_geometry()
to do that.
The current view position and size is 0,64 1920x1016, the pending
position/size is 0,0 1920x1080, and the last committed size is
1920x1016. Looking at the current and pending position and size, the
height changes while the bottom edge stays in the same place so this
looks like a top-edge-resize and view_impl_apply_geometry() decides to
keep the window's bottom edge in the same place while setting the
position according to the last-committed size. This results in the
window staying at position 0,64 size 1920x1016 despite being marked as
fullscreen.
My solution to this is just to change handle_configure_timeout() to
directly change the view's position and call view_moved() if necessary.
The idea of handle_configure_timeout() is to action the window movement
now while discarding the size change, and let the size change take place
later on when the client catches up. The logic of
view_impl_apply_geometry() doesn't make sense in this case so just avoid
it entirely.
Fixes#1922
Applies drag resistance unidirectionally for horizontally/vertically
maximized windows, allowing them to be dragged without being untiled
immediately. When the distance of cursor movement orthogonal to the
maximized direction exceeds <resistance><unMaximizeThreshold>.
While dragging a horizontally/vertically maximized window, edge/region
snapping is disabled to prevent unintentional snapping and overlays.
This commit also includes some refactoring to simplify the logic.
xdg-shell protocol says:
All active operations (e.g., move, resize) are canceled and all
attributes (e.g. title, state, stacking, ...) are discarded for an
xdg_toplevel surface when it is unmapped.
So, when a xdg-toplevel is unmapped (not minimized), the corresponding
foreign handler should be destroyed to reset attributes.
Chromium sends 2 commits before the commit with a buffer attached. We
were just checking `wlr_box_empty(&view->pending)` to handle the cases
where an initially maximized/fullscreen client is windowed, but that
check was also returning true on the 2nd commit from Chromium, resulting
in an error message: "view has empty geometry, not centering".
71451173 validates the xdg-activation token more strictly by verifying
the source surface attached to the token. That improves the security by
preventing arbitrary focus-stealing.
However, not all clients attach a right source surface to the token or
use the received token for activation. For example, when a notification
client requests thunderbird to activate its window, thunderbird doesn't
use the token passed by the notification client and instead use their own
token, thus the activation is rejected as the surface attached to the
token is not focused.
We will add options to configure the policy for activation requests or
implement urgency hint in some way in the future and reland the source
surface verification.
The initial configure event is now sent explicitly by labwc rather
than by wlroots. We need to move the maximize/fullscreen logic to
the initial commit handling accordingly.
Updates #1956, fixes#1994, replaces #1995.
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.
wlroots < 0.17 didn't allow to reliably check the source surface of
an xdg activation request as it reset the surface to NULL when it
was destroyed before the token was used. This happens regularly for
notifications for example. Thus we treated the token as valid even
without checking for the source surface.
wlroots 0.17 added a new_token signal where we can attach information
to the existing token which we can then use when evaluating activation
requests. This patch implements that check.
See https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3514
which added support on the wlroots side.
We now re-run popup positioning (for both xdg-shell and layer-shell
popups) when the "reposition" event is received. This allows popups that
change size (such as qmpanel's applications menu) to be positioned
correctly.
xdg-shell v3 also gives the compositor some additional "hints" for popup
positioning (reactive, parent_size, and parent_configure_serial) which
are available but we don't make use of currently.
Before this patch, labwc would happily kill itself when the user
called the `Kill` action when any xwayland view had focus.
The reason this happened was that wlroots creates the xwayland
wayland client via socketpair() and thus a lookup of the pid
of the socket connection would return the pid of labwc itself.
This patch fixes that by implementing different pid lookup
mechanisms based on the view implementation backend.
Fixes: #1739
When growing or shrinking a view by snapping to an edge, a client may
ignore the requested size and instead keep its original size or
substitute a different (possibly constrained) size. In this case, the
view may not actually contact the snapped edge, and a subsequent snap
attempt will just keep re-trying (and failing) to contact the same ege.
To mitigate this, remember the last-snapped view, snapping direction and
offset of the snapping edge in snap.c; when re-attempting a snap for the
same view in the same direction, ignore the edge that was last "hit", to
allow snapping to progress beyond the problematic edge.
Move/resize requests from xwayland views and xdg toplevels should be
ignored when the view is not pressed.
This is relevant for touchpad taps with <tapAndDrag> disabled.
When the user taps the client surface (e.g. chromium and mpv) with the
setting above, libinput sends button press & release signals so quickly
that the compositor receives move/resize request from the client AFTER
the button release signal is processed, so `interactive_finish()` is
never called.
...and notify the client of the preferred output scale when doing so.
This should allow clients to better determine an optimal size if they
are initially configured (unmapped) with zero size.
In particular, this fixes an issue with foot:
https://codeberg.org/dnkl/foot/issues/1579
Applications may respond to pending resize requests either by ignoring
them or substituting alternative sizes (for example, when mpv constrains
resizes to keep its aspect ratio fixed). In these cases, view->pending
will fall out of sync with the actual view geometry. This will cause
problems when subsequent operations (e.g., MoveToEdge) use the pending
geometry to decide where to place the window.
To fix this, reset view->pending to be equal view->current when either:
1. The requested size change has been commited, to the scene graph, and
no subsequent changes are pending; or
2. The requested size change has been ignored by the client.
Need to handle new unified mapping, where mapping is attached to the
wlr_surface objects instead of their parents. Also, most of them require
a new associate event for xsurface objects, their surface member will be
NULL before this event is received.
Refactored by jlindgren:
- add struct mappable
- unify map/unmap logic
Qt applications occasionally fail to call set_window_geometry after a
configure request, but do correctly update the actual surface extent.
This results in a mismatch between the window decorations (which follow
the logical geometry) and the visual size of the client area. As a
workaround, try to detect this case and ignore the out-of-date window
geometry.
Fixes: #1194
This is a useful (if lesser-known) feature of at least a few popular X11
window managers, for example Openbox and XFWM4. Typically right-click on
the maximize button toggles horizontal maximize, while middle-click
toggles vertical maximize.
Support in labwc uses the same configuration syntax as Openbox, where the
Maximize/ToggleMaximize actions have an optional "direction" argument:
horizontal, vertical, or both (default). The default mouse bindings match
the XFWM4 defaults (not sure what Openbox has by default).
Most of the external protocols still assume "maximized" is a Boolean,
which is no longer true internally. For the sake of the outside world,
a view is only "maximized" if maximized in both directions.
Internally, I've taken the following approach:
- SSD code decorates the view as "maximized" (i.e. hiding borders) only
if maximized in both directions.
- Layout code (interactive move/resize, tiling, etc.) generally treats
the view as "maximized" (with the restrictions that entails) if
maximized in either direction. For example, moving a vertically-
maximized view first restores the natural geometry (this differs from
Openbox, which instead allows the view to move only horizontally.)
v2: use enum view_axis for view->maximized
v3:
- update docs
- allow resizing if partly maximized
- add TODOs & corrections noted by Consolatis
The logic was the same for xdg-shell and xwayland views, so move it from
the view->impl layer out to the view_move_to_front/back() functions.
view->impl->move_to_front/back() still exist for now, in case we want to
add xdg/xwayland-specific logic in future, but they now move only one
view and not sub-views.
This makes the code a bit more readable IMHO (and forces us to be
consistent with event handler function names).
Adjust scripts/checkpatch.pl to not complain.
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.
