Select the "best" target rather than a random one out of a list of
suitable targets. The target selection algorithm would sometimes
select the wrong target and hence retrieve unexpected data.
This could happen in both copy-paste and drag-and-drop operations.
- fix undefined 'GC' if no window has been shown/drawn yet
- may still need to call fl_open_display() prior to offscreen-drawing
- improve documentation, add example code
Fix bug in CMake/posixScandir.cxx (backported from 1.4).
Fix table structure in test/help-test.html (backported from 1.4).
Clarify that the deprecated forms compatibility *may* be removed in
FLTK 1.4
Cherry-picking fix from FLTK 1.4 (master).
See report in fltk.coredev as of Jan 16, 2020:
"Fl_Input in readonly mode - wrong behaviour".
Summary: Drag and drop within a read-only Fl_Input (i.e. Fl_Output)
widget would not insert the dragged text (correct) but removed
the dragged text from the widget (error). This is now fixed.
Fl_Pack::draw() sometimes resizes itself. This must be followed
by a call to Fl_Group::init_sizes() as indicated in that function's doc:
"If you rearrange the widgets in your group, call this method to register
the new arrangement with the Fl_Group that contains them."
Revert commit 958d912ffc using 'XSetLocaleModifiers("@im=");'
which was incorrect (STR 3192).
Apply fix for STR 3502, using 'XSetLocaleModifiers("");' which appears
to be the correct solution for using X Input Methods (XIM).
Subject "Bug in 1.4 Displaying PNG under x64 Kernel x86 app." in flak.general
contains a report by Darren Legge that presents the problem,
and a later post stating the code modification does fix the problem.
This is an (edited) excerpt of https://www.fltk.org/roadmap.php in a
slightly different format (downloaded with `wget`) and redacted to
contain only FLTK 1.3 and 1.4.
Recent Linux distribution have replaced the freetype-config command
by pkg-config. The fix tries the new procedure with pkg-config and
falls back to freetype-config if the new procedure fails.
The given position to insert a new item was not checked against the
valid range so the program could crash if a position less than zero
or greater than children() was given. The position is now clamped to
the valid range, i.e. the item is either prepended or appended.
Fixes issue #18.
Backported from 1.4, commit 9b272cfa4e
macOS normally previews a dead key and then replaces the preview by the final text
after the second key is typed.
macOS ≥ 10.7 also opens an auxiliary window to help choosing among possible characters
after some keys (e.g., n, c, o, a) are pressed and maintained for a while.
The problem fixed here is that after an auxiliary window has been used,
dead keys are no longer previewed.
That problem emerged at some undetermined point before 10.14 and after 10.7.
