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.
Issue #144
Add `#define _POSIX_C_SOURCE 200809L` to avoid the error below:
../src/cursor.c: In function 'cursor_update_focus':
../src/cursor.c:271:2: warning: implicit declaration of function
'clock_gettime' [-Wimplicit-function-declaration]
271 | clock_gettime(CLOCK_MONOTONIC, &now);
| ^~~~~~~~~~~~~
../src/cursor.c:271:16: error: 'CLOCK_MONOTONIC' undeclared (first use in
this function)
271 | clock_gettime(CLOCK_MONOTONIC, &now);
| ^~~~~~~~~~~~~~~
../src/cursor.c:271:16: note: each undeclared identifier is reported only
once for each function it appears in
../src/cursor.c: In function 'is_double_click':
../src/cursor.c:486:16: error: 'CLOCK_MONOTONIC' undeclared (first use in
this function)
486 | clock_gettime(CLOCK_MONOTONIC, &now);
| ^~~~~~~~~~~~~~~
...and call it from desktop_move_to_front() in order force an enter event
on the surface below the cursor when cycling views.
Inspired by PR #164 - just restructured it a bit.
Suggested-by: @bi4k8
If we don't switch focus, we want the close button to close the window associated with it, not the current focus window.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
this was broken when we moved to swallowing mouse events that triggered "Frame"-context mouse bindings. layer surfaces don't run mouse binding logic, so they need mouse events unconditionally forwarded.
in order to allow the Move action to be bound to "press" on mouse binding contexts that also have "click" bindings, we should not short-circuit event processing when the input_mode is not passthrough (the "normal" mode). doing so seems to have been intended to prevent mouse bindings from being triggered during move/resize/menu interactions, but this does not seem to occur in practice. instead, `cursor_button`'s early return in this case caused the "release" side of "click" bindings to be ignored if their "press" side began an action that changes input_mode (e.g. Move).
the cleaner way to fix this interaction would be to use "drag" rather than "press" for Move bindings, but implementing "drag" is more complexity than I want to include in this changeset.
this change is its own commit to make it easy to bisect for, in case it causes regressions.
Use environment variables XCURSOR_THEME and XCURSOR_SIZE to set cursor
theme and size respectively. Default size is 24.
Find icons themes with the command below or similar:
find /usr/share/icons/ -type d -name "cursors"
cursor_rebase() sets the cursor icon and sends a motion-event to the
surface below the cursor. It is made public in anticipation of using it
in various view_* functions.
We are probably playing a game and we don't want to be resizing the window when trying to duck/jump whatever.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
