- documentation updates, alignment, formatting, version numbers
- fix widget order in test/keyboard_ui.fl
- replace hard-coded bit mask with 'FL_BUTTONS'
- add missing macro definition 'GET_XBUTTON_WPARAM' for MinGW
- reorder 'case' statements for button events (like in master)
> Backported from branch 'master' (1.4.0),
> commit 1259275316 (Jul 14, 2023)
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.
This file enables consumers to search for a particular FLTK version.
Note: backported from 'master' to support parallel installation of
1.3.10 (1.3.x) and 1.4.0 (1.4.x) or any higher version on one system.
This update makes sure to find and use a `fluid` executable on the
host (build system) and does no longer add the `fluid` target when
cross-compiling.
This makes PR #898 obsolete and fixes the reported issue.
- ensure that all required CMake policies are set to 3.15
- enhance CMake status report (add bundled library types)
- add erco's CMake instructions for building with NMake
- improve HTML docs (remove "custom" HTML footer)
- update ANNOUNCEMENT
... if GL or locale headers are not found. These headers will be
resolved by the Visual Studio SDK (backported from 1.4).
Also improve finding the GLEW library on Windows (named 'glew32')
(backported from 1.4).
Also update CHANGES file.
The compiler warnings were issued by MinGW with gcc 9.2.0.
Note: There are lots of compiler warnings left when building with
Visual Studio and/or NMake but these will not be fixed in 1.3.9.
All warnings have been fixed in 1.4.0 (current git 'master').
This support becomes very difficult with recent macOS versions for the
approach used in 1.3 based on undefining __APPLE__.
[In contrast, the approach used in 1.4 that doesn't mess with __APPLE__
is still compatible with recent macOS versions].
