Better default sizes for text based widgets and menu managers
Better Menu refresh on custom text heights
Smarter positioning of menu bars and groups inside tabs
Fixes wrong include guard
Complete type hierarchy in Fl_Types doc
Window now derives correctly from Group
Menu Items now correctly (functionally in FLUID) derived form Button
Menu Buttons have a better hierarchy
Fixing two possible crash bugs where Input_Choice was assumed to be a Menu_
Hoping I have not degraded the original code!
According to the reported issue this warning appears when using
gcc 13.1.0 (rev7, MinGW-W64).
it's very likely a new warning and a false positive because the
buffer is used as an output parameter, but anyway.
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.
See fltk.general, thread "Is handling simultaneous Left-click and
Right-click drags supported?" from Jul 12, 2023
Status: FL_DRAG operation is terminated when one mouse button is
released, even if more than one button is actually down. Subsequent
mouse movement is reported as FL_MOVE rather than FL_DRAG, this is
under investigation.
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".
