diff options
| author | ManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com> | 2026-01-14 16:16:25 +0100 |
|---|---|---|
| committer | ManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com> | 2026-01-14 16:16:25 +0100 |
| commit | 81c965f8e29c7b9fb68e9914d4223ab5fe293d1f (patch) | |
| tree | 73c3e9c3f753274800c86259e01d3aebdbb2a911 /documentation | |
| parent | d38b699432ab9c69a9e1a257cc4544db8ba1217e (diff) | |
Partial fix for the Windows platform of the emoji issue (#1360)
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.
Diffstat (limited to 'documentation')
0 files changed, 0 insertions, 0 deletions
