New compiler warning detected by g++ 14.2.0 building with CMake
in Release mode. This *temporary* fix suppresses the warning but uses
even larger fixed size buffers.
Todo: these nasty warnings caused by using fixed buffer sizes should
be removed by using std::string in FLTK 1.5.0.
1) Improve and clarify documentation:
- update, reformat, and reorder parts of CREDITS.txt
- make sure that documentation appears in doxygen docs
- add '\since 1.4.0' to documentation of new methods and functions
- remove doxygen's '\brief' where not required (we're using
JAVADOC_AUTOBRIEF = YES)
- clarify screen scaling, scaling factor, and related stuff
- add more info about backwards compatibility for X11 specific code
2) Update dependencies
After comparison with older versions I realized that the gtk+ specific
"chevron style" was previously used *exclusively* in Fl_Scrollbar.
Unfortunately I had picked this style as template for all arrows.
GitHub Issue #1117 requested to add an option for users to change the
arrow style but after my investigation I decided to use the "old style"
(triangles) for all schemes (except "oxy" that has its own drawing
methods).
**IF** it turned out that we need the gtk specific drawing for scrollbars
we could easily reactivate the "chevron style" by adding yet another
arrow type - but I hope this is not necessary.
Enlarging and reducing wdth and height needed to be treated
seprately when the bottom right corner of the resizable would
overshoot the final size of the tile.
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.
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.
