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.
This was apparently to fix an Intellij focus issue, but I don't see any
issues with Intellij currently, and the logic is wrong when the parent
XWayland surface doesn't want focus (e.g. an XWayland panel with a
focusable applications menu).
PR #1301 did partly revert the first variant because
`lab_wlr_scene_output_commit()` (which uses the `output->pending`
state in contrast to `wlr_scene_output_commit()`) was deemd to
cause 'frozen' frames during video playback (#1273).
We are now back at using `lab_wlr_scene_output_commit()` for
unrelated reasons and the cause of the original issue #1273 was
likely that `wlr_scene_output_send_frame_done()` was only sent
on a successful commit. This was changed to always be sent.
So lets restore the flicker free nested resize as well.
Support `wrap` in view_get_adjacent_output(). This means that when seeking
an adjacent output in a particular direction from an output that is
already furthest in that direction within the layout, rather than
returning NULL, wrap around from the leftmost to the rightmost, or topmost
to the bottommost and vice versa.
Example usage:
<action name="MoveToOutput" direction="right" wrap="yes" />
Wrap is disabled by default to keep the user interface consistent.
Exclude none (zero) from the bitmask test , otherwise
the bitmask test is always true when click method is
configured to 'none' and as a result the configuration
will be skipped.
Preliminary fix for #1525.
Based on the protocol we should also revert all
previously correctly committed outputs. #1528
is doing just that but may cause regressions so
we need a short term solution and then deal with
potential issues in #1528 after the release.
This uses the new `view->outputs` bitset to calculate the intersection
with *all* outputs the view is currently visible on.
This ensures that the invisible resize handle works across outputs
while still making sure that it won't leak into neighboring ones just
because it is positioned closely to an output edge (either manually,
maximized or snapped via SnapToEdge or SnapToRegion).
Co-Authored-By: @johanmalm
Fixes: #1486
Reported-By: @lurch
...to edges actually encountered by motion during interactive moves and
resizes.
In addition, ignore edge resistance and attraction for minimized views.
...in view_move_to_edge. If a view is fully within the usable area of
its original output, it should be fully within the usable area (if
possible) on its new output.
This ensures that client-side decorations (and maybe other client
behaviors) behave intuitively during interative moves, but means that
drag to snapped position -> drag to maximize -> un-maximize
will put the window back to its natural geometry (saved before the first
snap) rather than back to the snapped position. This is a change in
behavior, but a) simplifies the logic a bit, because the tiled state is
always in sync with the window geometry and b) in some sense is "more
correct", because the window has been "visually" un-tiled the minute the
window starts dragging.
Note that maximizing using an action (including the button) a window
that has been snapped and then un-maximizing the window will put the
window back to the snapped position, as it always has.
