This is necessary because wlroots backported a patch containing
cursor name aliases to the 0.16 branch. That internal mapping
does not alias "grab" to "grabbing" because it is not technically
part of the cursor-names spec.
To keep the "grab" cursor working on systems with no cursor theme
available (or in an unusual location) change the trigger for our
internal cursor name aliasing to "grab".
See wlroots commit 1e345c74c3ca5d2575aa975d4d9af87cd0c7ba13
Alias existing cursor defaults to cursor-spec cursor names
for further details.
- Store a pointer to the `struct view` in `struct ssd`
- Pass `struct ssd *` instead of `struct view *` to ssd functions
- Add `ssd_get_margin()` convenience function
Add xdg_surface_from_view() + xwayland_surface_from_view() accessors
that assert() the view is of the expected type before returning.
Fix a real bug in xdg.c parent_of() that dereferenced
`view->xdg_surface->toplevel` without first checking `view->type`.
The goal of the new accessors is to catch similar bugs in future.
IMHO it encourages better design (by making dependencies more obvious)
to have source file/header file pairs like view.c/view.h, rather than a
monolithic header like labwc.h with everything in it.
I don't think we need to break up all of labwc.h at once, but maybe we
can start pulling it apart bit by bit as it's convenient.
Also:
- Move "struct border" to ssd.h so that view.h can use it without pulling
in all of labwc.h.
- Add a missing required #include within scaled_font_buffer.h (forward
declaration of "struct font" is not enough).
Currently, snapping to a screen edge and then snapping to maximize
results in both the natural_geometry and tiled state of the view
getting messed up. After unmaximize, the view ends up in a weird
state (tiled location but natural/untiled size).
There are also a couple of sketchy things going on in the code:
- interactive_begin() pokes its own values into view->natural_geometry
to force view_maximize() to set a particular geometry.
- interactive_end() "fixes" view->natural_geometry after calling
view_maximize() to save the original geometry from the start of the
interactive move/resize.
To fix all this:
- Adjust/expand the API of view.c so that the interactive.c can
avoid this "back door" of overwriting view->natural_geometry
directly.
- Save the natural geometry and the tiled state of the view in
interactive_begin() when starting to move the view. When done,
interactive_end() will update the tiled state if appropriate but
*not* overwrite the natural geometry.
Mouse bindings, unlike key bindings, are made within contexts which
represent what was clicked/dragged. The context 'Frame' refers to the
entire window frame including both the window decorations (if any) and the
client window itself. It is typically used for alti + left/right click to
move/resize the window.
'Frame' is a special case in that when a button is bound in this
context, the action will not be forwarded to the client, which is what
we describe with the 'consumed_by_frame_context' variable.
@Consolatis determined that apparently the extra "clear focus"
event confuses the drag source during drag-and-drop.
Fixes drag-and-drop of files into folders within the same Thunar
window.
Attempting to open a GTK3 menu and activate a menu item in it,
using a single mouse motion (press-move-release), was broken due
to GTK apparently expecting to receive leave/enter events when the
cursor enters the menu (XDG popup).
To fix the issue, allow leave/enter events when the cursor is
moved between an XDG toplevel and popups of the same.
v2:
- Use (struct view *) as proxy for toplevel in comparisons
- Update seat->pressed.surface when entering/leaving popups
v3:
- Go back to using get_toplevel() rather than (struct view *)
Fix a couple of glitches seen when exiting interactive move/resize:
- Cursor briefly set to left_ptr rather than the correct cursor image
- Cursor not updated if the view being moved/resized is destroyed
Also make sure to exit interactive mode if the view is going fullscreen
(labwc gets very confused otherwise).
Code changes in detail:
- Factor out set_server_cursor() which will set the correct cursor
image for non-client areas (either XCURSOR_DEFAULT or one of the
resize cursors).
- Unify the logic from cursor_rebase() and process_cursor_motion by
factoring out cursor_update_common(). This corrects some logic
discrepancies between the two, which should be a good thing(TM).
- Remove the extra cursor_set(XCURSOR_DEFAULT) from interactive_end()
and instead rely on cursor_update_focus() to do the right thing.
- Simplify cursor_button() by just calling interactive_end() when we
want to exit interactive mode.
- Call cursor_update_focus() from view_destroy() if the view had mouse
focus or was being interactively moved/resized.
v2: Eliminate force_reenter parameters and figure out automatically
when we need to re-enter the surface.
v3: Rename wlseat -> wlr_seat.
v4: Simplify client/server cursor logic.
- When XDG and XWayland views are positioned (view_moved()).
- When unmanaged XWayland surfaces are mapped, unmapped, or moved.
Do not update cursor focus during an out-of-surface drag.
Along with the existing call in desktop_move_to_front(), this
should hopefully cover the majority of cases where the cursor focus
could get out-of-date, with the possible exception of layer-shell
surfaces.
...when pointer moves off the xdg-shell surface which is possible when
for example grabbing a scroll-bar or selecting text.
Clamping results in undetected pointer motion when applied in the
direction of movement (for example clamping at view->y masks vertical
movement when the y-coordinate is greater than view->y), which in turn
can appear as sporadic to the end-user.
Previously, motion events for a cursor which had been pressed on a surface
and then moved out of the surface were only sent for XDG and X11 surfaces.
This patch includes layer surfaces as well.
Fixes#483
X11 apps expect to be able to receive motion events outside
the window area (this is necessary for client-side move/resize
handles to work properly). So do not clamp the motion
coordinates for XWayland surfaces.
Before this change, attempting to enlarge an XWayland window
using a client-side resize handle resulted in the window size
lagging behind the mouse cursor quite severely, since each
motion event was in effect allowed to expand the window by
only a few pixels. The closer the initial button-press was
to the edge of the window, the worse the lag would be.
