I like the new common/edge.h. I don't like how inconsistently we use it.
Current situation:
- enum wlr_edges and wlr_direction are designed to be used as bitset,
and are defined compatibly
- enum lab_edge is *also* designed to be used as bitset, but
incompatible with the others (LEFT/RIGHT come before UP/DOWN)
- we use an inconsistent mix of all three *AND* uint32_t (usually with
the WLR_EDGE constants rather than the LAB_EDGE constants), and
convert between them on an ad-hoc basis, sometimes implicitly
Let's clean this up:
- reorder enum lab_edge to be compatible with the two wlr enums
(check this by static_assert)
- use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges)
- add constants for the remaining possible combinations of the 4 edges
- use lab_edge for all internal edge/direction fields, consistently
- add lab_edge_is_cardinal() as a sanity check before casting to
enum wlr_direction, and then eliminate all of direction.c/h
Instead of "enum wlr_edges direction", we now have
"enum lab_edge direction" which is not that much better. At least we
are now clear that we're overloading one enum with two meanings.
Currently, the dependencies between foreign-toplevel[-internal],
ext-foreign, and wlr-foreign are cyclical and a bit complex.
I suggest we reorganize it into a simpler hierarchy:
foreign-toplevel/
-> foreign.c/h
-> (depends on) ext-foreign.c/h
-> (depends on) wlr-foreign.c/h
The refactored code is smaller and (IMO) easier to follow.
In detail:
- Add include/foreign-toplevel folder mirroring src/foreign-toplevel
- Split foreign-toplevel-internal.h to ext-foreign.h and wlr-foreign.h
- Eliminate ext-/wlr-foreign.c -> foreign.c reverse dependencies
(including internal signals and foreign_request* functions)
- Make struct foreign_toplevel private to foreign.c
Lightly tested with qmpanel (which uses wlr-foreign-toplevel).
v2: reorder foreign-toplevel internal API funcs
In addition to <snapping><range>, <snapping><cornerRange> configures the
distance from the screen corner to trigger quater window snapping.
Also, new values "up-left", "up-right", "down-left" and "down-right" are
allowed for <action name="(Toggle)SnapToEdge" direction="[value]"> and
<query tiled="[value]">.
- Send xdg_toplevel.wm_capabilities
- Send xdg_toplevel.configure_bounds so that clients can map a window that
fits within the usable area, without relying on
view_constrain_size_to_that_of_usable_area() which is called after map.
- (The new "suspended" state should be handled by wlr_scene in the future)
This prevents a crash observed by the scaled-icon-buffer listening
to the `view->events.set_icons` signal before it is initialized.
For this to happen, the application needs to use the kde decoration
protocol and set it on the xdg_surface before creating the xdg_toplevel.
Fixes: #2798
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.
In some cases, we would schedule a configure event but not record that
we had done so, leaving view->pending_configure_serial incorrect. This
caused incorrect handling of in-flight commits that had not yet taken
the new configure into account, such as assuming that the client had
ignored the configured size and incorrectly resetting view->pending.
Fixes: #2774
Adding -Wshadow will prevent unintentional variable overrides.
Also, wrapping switch cases with declarations with braces will make our
logic more robust by limiting lifetimes of variables.
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.
This ensures all event listeners are removed before the emitting
wlroots object is being destroyed. This will be enforced with asserts
in wlroots 0.19 but there is no reason to not do it right now either.
This change in wlroots 0.19 is implemented via commit
8f56f7ca43257cc05c7c4eb57a0f541e05cf9a79
"Assert (almost all) signals have no attached listeners on destroy"
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
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.
