Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scrollwheel to use it for both
scrolling directions.
This concludes "handling shift + mousewheel" for all supported platforms.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scrollwheel to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch is different than the one in file 'scroll.patch' (STR 3521).
It takes care of distinct mousewheel delta calculation for vertical
and horizontal mousewheels and avoids the "fallthrough" case.
Note: macOS takes care of this, there's no special handling required.
To do: the Wayland platform still needs to be updated.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scroll button to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch has been provided by Manolo in file 'scroll.patch'
(see STR 3521).
Libdecor complicates what should be simple, to close a decorated window,
because it uses the titlebar after return from the closing callback function.
Thus, FLTK delays the sending of the FL_CLOSE event to the window,
only when libdecor runs in CSD mode.
The old version would send FL_MOVE events after dragging with more
than one mouse buttons pressed, as soon as the first button was
released.
The new version sends FL_DRAG until the last mouse button is released
and then FL_MOVE, as usual.
This change affects dragging only if more than one mouse button is
pushed and held while dragging. The order of pushing and releasing
mouse buttons does not affect the behavior.
Note: this may be somewhat confusing if the user enters out-of-range
values manually because they are overwritten immediately with valid
input but the effects seen in issue #749 are IMHO worse.
Notes:
(1) Fl::e_state holds the current state of all mouse buttons which is
returned by Fl::event_buttons() - "plural form".
(2) Fl::e_keysym holds the "key" of the current event which can be a
mouse button, returned by Fl::event_button() - "singular form".
