Commit ec68806354 ("xwayland: Honor size increments from
WM_SIZE_HINTS") adjusted only the window width/height according
to the size hints. If resizing from the top or left edge of the
window, we also need to adjust the window position to keep the
bottom or right edge from jumping around.
...and call it from desktop_move_to_front() in order force an enter event
on the surface below the cursor when cycling views.
Fixes#162 and #225
Inspired by PR #164 - just restructured it a bit.
Suggested-by: @bi4k8
Co-authored-by: Consolatis <35009135+Consolatis@users.noreply.github.com>
Prevents a single action like ToggleDecorations + ToggleMaximize to
position the view somewhere with negative coordinates when unmaximizing.
It may still position the view on negative coordinates but later commit
events will fix the position. This issue only exists on xwayland because
there are no configure serials which we could use to ignore all
repositioning until we are at the latest desired state.
This is necessary for menus in X11 apps to work properly.
Otherwise, any region of the menu that extended out beyond the main
application window was not receiving any mouse input.
Adapted from sway's code.
Patch releases only contain backwards compatible changes (mainly bug
fixes) so we want to allow them. This fixes the build with the recently
released wlroots 0.15.1 and uses the same version constraints as other
projects that depend on wlroots (e.g., Sway).
Add the 'cycleViewPreview.core' option to rc.xml to enable previews of
the selected view when cycling between windows. Default this option to
be disabled to match current behavior.
This will still prevent touchscreens or other absolute pointers to
function correctly after switching the TTY when using a multi
screen setup. But that is still better than segfaulting.
...in preference to views and other layer surfaces (except those in the
OVERLAY layer which always go first)
Fixes issue #207 where a BOTTOM layer popup lost mouse focus when a
terminal was behind it.
The "pressed" status of the mouse button is stored per-binding, and
the first binding activated causes us to break out of the loop that
cleared the "pressed" status -- as a result, some statused weren't
cleared when another binding was activated.
The bug could be seen when clicking the maximize button on a window
and then moving the mouse: the DRAG action would continue to move
the window (unmaximizing it) even though the mouse button was no
longer held.
By moving the cursor slightly after the second press (but before
the second release) it was possible to accidentally trigger both a
DOUBLECLICK and a DRAG action. Doing this on the titlebar would
cause the window to maximize and then immediately unmaximize, which
feels very "glitchy".
As a simple fix, don't allow a press event that is triggering a
DOUBLECLICK to also trigger a DRAG (or CLICK) on the following
release event.
Note: Openbox avoids the issue by processing DOUBLECLICK on the
second release event. If the cursor moves before that, the DRAG
wins out and the DOUBLECLICK isn't processed.
