- 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.
This removes these warnings for each source file compiled
osxcross: warning: possibly dangerous include path specified: '-I /usr/include/freetype2'
osxcross: info: you can silence this warning via 'OSXCROSS_NO_INCLUDE_PATH_WARNINGS=1' (env)
when cross-compiling from Linux to macOS.
This would create these warnings for each source file compiled
osxcross: warning: possibly dangerous include path specified: '-I /usr/include/freetype2'
osxcross: info: you can silence this warning via 'OSXCROSS_NO_INCLUDE_PATH_WARNINGS=1' (env)
when cross-compiling from Linux to macOS.
... as reported in thread "Windows 11 crash (still investigating)"
of fltk.coredev, started on Apr 24, 2024.
This bug could only be triggered if a /subwindow/ wss hidden but was
not limited to Windows.
Visual Studio projects that link to the FLTK DLL (fltk::fltk-shared)
inherit the compile definition set by the DLL target and will be
compiled with "-D FL_DLL" as required w/o the user project having
to set this preprocessor macro explicitly.
Todo: documentation will follow...
Albrecht Schlosser