Currently, we anchor the right/bottom edge of the view whenever the top/
left edge is moving (current.x/y != pending.x/y). Doing so doesn't make
much sense when the right/bottom edge is also moving. In that case it's
probably best to move the view (or at least its top/left corner)
directly to its final position.
The most noticeable effect of this change is with views that don't
accept their requested size exactly when tiled or maximized (examples:
havoc, xfce4-terminal). Previously, their right-bottom corner would be
aligned with the screen edge, leaving gaps on the left and top. Now the
top-left corner will be aligned and the gaps will be on the right and
bottom. This is still not ideal, but IMHO less surprising to the user.
- Make view_discover_output() static
- Call view_discover_output() only for floating views
- Deprecate view_output(); make it use view->output when possible
This can be used to better control Virtual Machines, VNC clients, nested
compositors or similar. All keybinds other than ToggleKeybinds itself are
disabled when first called, a 2nd call will restore handling of all keybinds.
Fixes#738Fixes#810
...to increase xwayland and xdg-shell encapsulation and to avoid passing a
function pointer as an argument in `xwayland_move_sub_views_to_front()`
which is inconsistent with labwc design patterns.
Rename view-impl.c to view-impl-common.c
Move function declarations that are common to view-implementations from
view.h into view-impl-common.h
This fixes an issue with havoc not having a valid size on map().
Investigation showed that xdg_surface->current.geometry is set only by
the xdg_surface::set_geometry protocol message, which is optional. If
set_geometry is not called, then we are supposed to compute the size
from the surface buffer(s). wlr_xdg_surface_get_geometry() already
accounts for this, so we just need to use wlr_xdg_surface_get_geometry()
instead of reading xdg_surface->current.geometry directly.
The fix caused a couple of issues:
1. Ignoring client configure requests caused some clients to hang
and not repaint correctly. We are supposed to synthesize a
ConfigureNotify event when ignore/override a client configure
request, but this isn't possible with current wlroots.
2. Setting view->natural_geometry from client configure requests
resulted in overwriting good values with bad in some cases (e.g.
with tiled xfce4-terminal in xwayland mode).
For now, revert the fix. This does allow clients to mess with view
positioning for maximized/fullscreen/tiled views, but right now the
alternatives seem worse.
The original specific issue (VLC undoing its fullscreen geometry)
is arguably a bug in VLC anyway.
This reverts commit 09599861ac.
A fullscreen view currently has its output specified twice by:
- struct output *output
- struct wlr_output *fullscreen
view->fullscreen may also become a dangling pointer if the output is
disconnected, because view_on_output_destroy() clears view->output but
not view->fullscreen.
To eliminate the redundancy and the dangling pointer, let's change
view->fullscreen to a Boolean and rely on view->output to specify the
output.
Along the way, change a few related usages of struct wlr_output to
struct output as well.
No functional change intended.
v2: Don't allow entering fullscreen on disabled output (makes
conditions for entering/leaving fullscreen symmetric)
v3: Use output_is_usable() helper
view->impl->move() is a specific case of view->impl->configure().
To reduce code duplication, we can use view->impl->configure() for
pure moves (without resize) as well.
xwayland's move() function also possibly contained a race condition
when there was a pending resize, as it used the current surface
width/height rather than the pending width/height. This is fixed.
wlr_output_layout_get() returns NULL for disabled outputs.
Backtrace (abbreviated):
#0 lab_wlr_output_layout_layout_coords at ../src/ssd/ssd_extents.c:33
#1 ssd_extents_update at ../src/ssd/ssd_extents.c:133
#2 ssd_extents_create at ../src/ssd/ssd_extents.c:95
#3 ssd_create at ../src/ssd/ssd.c:161
#4 decorate.part.0.lto_priv.0 at ../src/view.c:637
#5 decorate at ../src/view.c:636
#6 view_set_fullscreen at ../src/view.c:716
#7 view_adjust_for_layout_change ../src/view.c:745
#8 desktop_arrange_all_views ../src/desktop.c:52
#9 output_update_all_usable_areas at ../src/output.c:495
#10 output_update_for_layout_change at ../src/output.c:263
#11 do_output_layout_change at ../src/output.c:423
#12 do_output_layout_change at ../src/cursor.c:267
#13 output_config_apply at ../src/output.c:334
#14 handle_output_manager_apply at ../src/output.c:354
Before this patch, configuring a surface with a new size,
immediately followed up by one or more view_move() calls
would move the surface to the new coordinates immediately
without waiting for the resize. This caused visual glitches
when for example dragging a maximized window: the position
would change but the size was still that of a maximized
window.
This patch fixes that by just ignoring view_move() requests
(but still updating view->pending) if there is a configure
request pending. Once the client commit comes in the new
size will be applied as usual.
It was not working before because in the case of wayland
we are only dealing with sizes as wayland has no notion
of a global position. A wayland client would thus not
necessarily respond to a configure request which sets
the same size again. This causes us to also not apply
a new position set in view->pending because there may
be no commit from the client in those cases.
We previously worked around this issue in some parts
of the code to check our new sizes against the pending
ones and if they were the same we would call view_move
instead. That had two issues:
- Not all parts of the code did that which could end up
delaying the positioning either to the next completely
unrelated xdg commit event or to the next view_move call
- The code started to repeat itself, e.g. the same condition
with calls to either view_move or view_move_resize based
on the result
This patch fixes it by doing the check in the xdg configure
handler instead. Xwayland is unaffected by this issue as we
are always configuring a xwayland client with both, position
and size.
