- separate layout and contents of example text widgets
- use Fl_Grid for more flexibility in the layout of the main window
- reformat some parts but not all code to FLTK style
- add comments, fix font style calculation ("near fixed pitch")
- add tooltips with user instructions to some of the widgets
- add "rainbow" emoji as colored emoji example
- reformat contents of the "unichar drop box"
- fix: comparison of integer expressions of different signedness
- rename confusing variable 'l' to 'len' (l can be confused with 1)
- minor comment and code formatting
This commit should not change the behavior.
It's possible to build and run FLTK 1.5 with its use of C++11 for macOS 10.7 and SDK 10.7.
This commit makes 10.7 the required minimal version of macOS to build and run FLTK 1.5.
This test is specifically intended to disable Pen/Tablet support on
classic MinGW (32-bit) platforms that lack required symbol definitions
although Pen/Tablet support might be supported by the Windows system.
This test can be extended for other platforms, but for now it's
performed only on Windows.
- It is expected that all emojis listed in the Wikipedia "emoji" article
as of early 2026 are recognized as single glyphs by FLTK text widgets.
- Document functions fl_utf8_{next|previous}_composed_char()
relatively to the notion of "emoji sequence".
- Remove signed/unsigned comparison compilation warnings.
- use demo strings in UTF-8 encoding rather than converting them
which also simplifies the code
- replace some hard-coded width and pos. values with constants
- enlarge width of text widgets (left column) of the main window
- replace display of Unicode range U+D800 ... U+DFFF with a text
explaining that this space is used by UTF-16 surrogate pairs to
prevent warning messages about invalid Unicode text.
This commit adds support of another type of composed characters: flags.
It also fixes Fl_Text_Buffer::prev_char() and Fl_Text_Buffer::next_char()
that must use Fl_Text_Buffer::byte_at() to access to the content of the text buffer.
This commit makes platforms Windows and macOS compute string widths
with the same mechanism as what is in place for platforms Wayland/X11:
- the width of a string containing a single codepoint is computed and
memorized in the table of character widths;
- the width of a string containing several codepoints is computed as
such rather than as the sum of the widths of its composing characters.
The result is that FLTK text widgets input and draw correctly also
complex emojis encoded with context-dependent codepoints.
Function fl_utf8_remove_context_dependent() is no longer necessary.
This commit introduces function fl_utf8_remove_context_dependent() that removes
from an UTF-8 string its context-dependent codepoints. Platforms macOS, Wayland
and X11 call this function to process UTF-8 text received from a character palette
as input to FLTK text. This makes sure FLTK text-editing widgets process textual input
equally and consistently across platforms, especially emojis entered via a palette.
Platform Windows creates a series of separate system events to input an emoji
via the character palette. For this reason, function fl_utf8_remove_context_dependent()
is not used by this platform which does internally the same filtering of context-
dependent codepoints.
The character palette allowing to input emojis in text generates in some cases a series
of unicode points to represent a single emoji. These series contain various kinds of
unicode points with context-dependent meaning. This commit prevents such context-
dependent unicodepoints from being inserted in FLTK text because FLTK text edition
mechanism is not ready to handle properly context dependency in edited UTF-8 text.
This fixes input of emojis to Fl_Input and Fl_Text_editor widgets under Windows with the emoji palette.
Most emojis have a Unicode point > 0xFFFF and therefore are encoded as a surrogate pair
by Windows which uses UTF-16. Thus, Windows sends 2 consecutive WM_CHAR messages to the
window and gives one member of the pair each time. After the second WM_CHAR message arrived
FLTK is able to enter the emoji in its text. Windows may also send "variation selectors" and
zero-width Unicode points when dealing with emojis. FLTK just skips them.
Windows also translates some Unicode emojis into 1 emoji + 1 other Unicode point: for example
"woman pilot" produces "pilot emoji" + "woman" unicode point. FLTK now handles
this gracefuly.
This fix also prefixes the windows class names with "FLTK-" under Windows to prevent
collisions with Windows-reserved class names. That fix is necessary for the emoji palette
to be usable in some scenarios. That fix is still under debate and may evolve in latter commits.
