Adding only 2 of 3 new examples is intentional (9 per menu level).
Figure numbers have been removed in all the HTML docs recently for
better maintainability.
add example(s) showing Albrecht's innovative overlap resizable
technique to the "How does resizing work?" documentation and tests
See "resizable question" original discussion thread under:
https://www.fltk.org/newsgroups.php?gfltk.general+v:39635
This undocumented macro is used on X11 and macOS platforms to
consolidate mouse move events, i.e. to collect some events and send
them later as one event. The old macro name CONSOLIDATE_MOTION has been
renamed to FLTK_CONSOLIDATE_MOTION since it is now a "global" symbol.
Users can define FLTK_CONSOLIDATE_MOTION in their build system, e.g.
on the compiler commandline, as 0 or 1 to disable or enable this
feature, respectively.
In FLTK 1.3 the default was 0 (OFF) on macOS and 1 (ON) on X11.
In FLTK 1.4 the default is always 0 (OFF).
This fixes focus box drawing on X11 for some broken graphics
drivers with line width zero as discussed on issue #156 titled
"Incorrect rendering on Alpine Linux".
This title is not entirely correct. The issue has been observed on
other Linux distros as well if the "modesetting" driver is in effect.
This does not fix rectangle drawing (missing pixels) in general which
is obviously caused by a similar or the same driver issue.
Declare Fl_Scroll::bbox() and Fl_Scroll::recalc_scrollbars() 'const'.
These methods don't change the Fl_Scroll widget.
Use Fl_Scroll::recalc_scrollbars() in Fl_Scroll::bbox() to simplify
the code and to avoid code duplication.
bbox() can now be called at any time and returns the correct values,
no matter if draw() has been called before.
The intention is to make it more convenient for developers to add
one or more test programs for their tests by editing only one
variable (extra_tests).
lib/README.txt: clarify where built libraries are located
documentation/src/basics.dox: clarify (C++) compiler command usage
and improve documentation of the fltk-config script
There's not much we can do if we find unknown data in the main
parser loop. The best we can do is terminating.
If we find a GIF trailer (0x3b) this means logical end of file.
If we get there in the main loop the GIF file is empty (no image).
This behavior is consistent with many other image viewers including
browsers (Firefox and Chrome).
This is part 1 and a prerequisite for the fix of issue #271.
It enables the user of this internal class (Fl_{BMP|GIF}_Image)
to test for read errors and EOF (end of file) while reading.
The method used to read data from memory got an optional third
argument 'const long datasize = -1)' to limit the size of the
memory block of data provided to the image reader. Default is -1
which means "unlimited" (backwards compatibility).
Using only two arguments (w/o size limit) is deprecated and should
only be done if the data size is not available.
