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...
The commit f288aea from Feb. 23rd introduced a
regression where children of subwindows were moved
inside the subwindow when only the subwindow itself
was supposed to move.
