Note: it is *unusual* (not FLTK style) that Fl_Window::border()
returns 'unsigned int' instead of 'int'.
This should be investigated in FLTK 1.5 but maybe we can't change it:
it's been so already in FLTK 1.3 and maybe earlier.
In function ‘void innards(...)’:
src/drivers/GDI/Fl_GDI_Graphics_Driver_image.cxx:132:23:
dereferencing type-punned pointer will break strict-aliasing rules
BITMAPINFO &bmi = *((BITMAPINFO*)bmibuffer);
~^~~~~~~~~~~~~~~~~~~~~~~
Found with gcc 12 (MinGW cross compiler)
Also: use correct sizes (sizeof) rather than hardcoded values.
Note: 'FL_DOUBLE_WINDOW' *is* currently defined as 'FL_WINDOW+1'.
This commit doesn't change real code but prevents potential bugs
in the future if one of these constants would be changed.
Note: in commit a7328d940b
"FLUID: Imporving method name `can_have_children()`"
the file function_panel.cxx was edited w/o the corresponding
fluid (.fl) file.
This commit fixes this, assuming the .cxx file was correct.
This bit mask was added in commit 53b40f4138 in an attempt
to *document* reserved bits but it turned out that this mask could
have negative side effects on some newer compilers by propagating
the enum to an 'unsigned int' and issuing compiler warnings.
See this comment and follow-up's in fltk.general:
https://groups.google.com/g/fltkgeneral/c/7xrDkbkxiyw/m/rzEIJ7XhAgAJ
- fix missing doxygen version in PDF docs created by CMake
- remove unnecessary quotes ('...') from version numbers and
Git revisions (previously added for debugging purposes)
- fix navigation links at the bottom of tutorial pages (HTML only)
- remove 'D. Gibson' from documentation headers on his request
Note: one goal is to have to edit fewer version numbers in source
files for each release.
We may be able to generate some files by the build procedure (CMake)
to avoid editing them in the future (1.5.0 or later).
These types of boxes frame a background with a rectangular frame of another color.
The previous procedure to draw them was not robust to GUI rescaling creating cases
where space between the border and the background was not drawn.
The new drawing procedure for these boxes first paints the whole area (frame included)
with the background color and next draws the frame over the just painted rectangle.
No uncolored space is possible.
It was also necessary to very slightly modify Fl_Scalable_Graphics_Driver::rect()
used by the Windows and X11 (no Cairo) backends to make sure fl_rect(x,y,w,h)
exactly frames fl_rectf(x,y,w,h) without drawing outside the filled area.