- swap 3rd and 4th parameter of fl_contrast()
- change 'Fl_Fontsize fs' to a neutral 'int size' parameter
- clarify documentation of fl_contrast_level() and that different
contrast algorithms use different level values
- clarify that level 39 for the CIELAB mode results in "sufficient"
contrast, i.e. /readable/ text which is the only intention of
fl_contrast().
Reasoning: swapping the arguments looks more natural, i.e. the context
before another argument (size) is what one would usually expect. Since
the 'size' argument doesn't have be a font size, making it a simple
'int size' is more flexible and correct for future extensions.
- src/fl_contrast.cxx:
- FL_CONTRAST_LEGACY: reset black/white threshold from 55 to 50
- FL_CONTRAST_CIELAB: change default contrast level from 55 to 39
- test/contrast.cxx:
- set default contrast mode to CIELAB
- add "random color" button to test random foreground colors (text)
- slightly increase terminal size
- make the Fl_Terminal widget the resizable() of the window
- Remove find_library(LIB_GLEW ...) from 'resources.cmake'
- Use the variable FLTK_GLEW_DIR to "find" a user supplied GLEW library
for OpenGL3 example programs (examples/OpenGL3*.cxx).
Both static and shared libs (DLLs) are supported, but the static
library is preferred to avoid DLL dependencies.
- Define preprocessor macro 'GLEW_STATIC' by CMake compile definitions
if and only if the static glew library (glew32s) was found and linked.
The previous code defined 'GLEW_STATIC' unconditionally in the source
code which led to undefined references if a shared lib (DLL) was used.
- don't use pkg-config to find Cairo if FLTK_CAIRO_DIR is set
- use FLTK_CAIRO_DIR to locate Cairo headers and DLL if it is set
- otherwise try to find Cairo with pkg-config anyway
This prevents accidentally "finding" the system Cairo libs provided
by MSYS - which would tie the FLTK library and user programs to MSYS,
i.e. it would make FLTK programs depend on the MSYS installation.
... (add_library cannot create ALIAS target "fltk" because target
"fltk::fltk" is imported but not globally visible)
It turned out that this was due to a CMake feature that was changed in
CMake 3.18. This commit makes imported FLTK targets globally visible
for CMake versions less than 3.18.
This has the Mutter compositor open modal windows at the center of their parent window
rather than at an unpredictable display position before this commit.
This is intended for backwards compatibility with FLTK 1.3.x code
ported to 1.4.0.
Users defining FL_NO_DEPRECATE can compile old (1.3.x) code w/o
seeing lots of "deprecated" warnings. A legitimate use case is if
old (1.3) code is intended to be used with both FLTK 1.3 and 1.4.
FL_NO_DEPRECATE should NOT be defined if the user's code is targeted
at 1.4.x or later. Users should fix their code to be prepared for
the next minor release (e.g. 1.5.0).
Todo: document this.
This DnD gives two data types of the dragged text: text and a gnome-specific type.
The code previously accepted DnD with 1 data type or 4 or more data types,
and processed situations with 2 or 3 data types in a special way that fails
with gnome source apps.
The new code processes situations with 2 and 3 data types just like other ones.
This works OK when dragging from gnome wayland apps.
Changing _root->find_clicked(..) to just find_clicked(..)
includes the check of _root for NULL, which is probably better
than doing a repeat explicit check and early exit.
Also, remove this text from the doc of Fl_Menu_::down_box()
"If this is FL_NO_BOX then it acts like
FL_THIN_UP_BOX and selection_color() acts like
FL_WHITE, for back compatibility."
that was true only for the Windows platform and that required
selection_color to be replaced by white for menu items which is
not what FLTK 1.4 expects.
The new state of menu item drawings is as follows :
- all platforms draw menu items with the same symbolic colors
- selected items and menu titles are drawn with the selection color
as background color
- menu items are drawn by default with no box but can be given one
by Fl_Menu_::down_box(Fl_Boxtype)
- the text of selected items is drawn with the menu's color
unless fl_contrast() finds it does not make enough contrast with
the background (selection color) and substitutes it with a more
adapted color
- the Windows platform uses a visibly different hue for its default
selection color from what other platforms use
... in thread: "FLTK 1.4 Menu Bar Style", started on May 6, 2024
This is about the little triangle (or similar) pointing right when
a submenu exists in a menu. The arrow form differs per scheme.
