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.
Strictly spoken, commit 3fbd4f944f introduced a regression on Windows.
The additional table entry VK_OEM_PLUS overrode the old behavior
because the value of VK_OEM_PLUS is 0xbb (see comment in code).
Note: if enabled, then the usual global scaling shortcuts don't work
and scaling by shortcuts is disabled.
This is intended for testing and not for normal usage.
This work is based on PR 1068 (patch by @CendioHalim) and
extended to store button status (4,5) in Fl::event_state() like
it's done for other mouse buttons (1-3).
Changes:
- new symbol: FL_BUTTON4 = side button 1 = "back"
- new symbol: FL_BUTTON5 = side button 2 = "forward"
- modified : FL_BUTTONS now includes bits for two side buttons
Note: the status of these new buttons is not maintained by X11,
therefore we need to maintain them in internal variables for
this platform.
... as proposed by Manolo in a private mail.
This patch allows to detect "ctrl+'-' on keyboards with digits in
uppercase positions (e.g. French)" but this is only preliminary for
FLTK 1.4.0.
Windows keyboard handling should be revised in FLTK 1.5.0 or higher.
This seems to have been left over from when mouse text selection would start a text selection on the left side of the character and always extend the selection to include the character under the cursor.
We now perform text selection based on whether the selection spans across the horizontal center of a character and so this next_char() causes the endpoint of the selection to be incorrectly shifted to the right.
- fixes copy/paste operation that would place pasted types wrong
- improves paste into folded and unfolded groups
- improves duplication of multiple types
- much improved placement of types that don;t fit at the
requested position
- some more testing will follow in the next days