| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
(#1127)
|
|
(#1127)
|
|
palette.
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.
|
|
cont'd
|
|
cont'd
|
|
This option can be used to disable pen/tablet support if there are
build problems on a particular platform or build system (e.g. MinGW)
so users can continue to build FLTK 1.5.
Users can also choose to disable pen support if they don't need it.
|
|
|
|
|
|
|
|
|
|
|
|
cont'd (#259)
|
|
The fix puts the first window an app creates on the screen containing the mouse,
because the present window creation code needs to know on what screen a created
window is going to appear before creating it.
|
|
Use the current mouse position to estimate the
position where the mouse left the window. Not
perfect, but much better than repeating the last
move coordinates.
|
|
... according to CMP
|
|
|
|
This creates the base for #1263, but does not fix it yet.
|
|
This turned out to be more complicated than just to delete a function
because it was used internally, and the callback signatures were a bit
flaky. I also added a lot of documentation to clarify matters.
FL/Fl.H: document idle callback signatures, make some internal
functions of class Fl private, add public Fl::idle() accessor (read-
only), add Fl::add_idle(Fl_Old_Idle_Handler cb) to enable using
old-style idle callbacks w/o 'data' argument.
FL/forms.H: replace Fl::set_idle() with Fl::add_idle().
src/Fl.cxx: rename private Fl::idle_ with trailing underscore.
src/Fl_System_Driver.cxx: use new public accessor Fl::idle() to access
Fl::idle_ which is now private.
src/Fl_add_idle.cxx: improve documentation, clarify idle callback
matching, add example code in docs, rename methods, add overloaded
Fl::add_idle(Fl_Old_Idle_Handler cb).
src/Fl_win32.cxx: use public Fl::idle() rather than private member.
src/drivers/Unix/Fl_Unix_System_Driver.cxx: same as above.
src/Fl_cocoa.mm: same as above.
|
|
The commit has all platforms send the FL_FULLSCREEN event when a window is created fullscreen.
|
|
- remove configure stuff from more README files
- move documentation/README.txt to README.documentation.txt
|
|
|
|
|
|
Found with warning level: /W3
|
|
Possible via the Win+Shift+Left/Right keyboard shortcuts
|
|
|
|
|
|
|
|
|
|
... as reported today by Ian on fltk.general in thread
"Mingw-32 compile issue with new 4/5 mousebutton hooks (fltk-1.4)"
|
|
Strictly spoken, commit 3fbd4f944f0a 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).
|
|
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.
|
|
|
|
Fl_Window::get_size_range()
|
|
|
|
|
|
|
|
|
|
no code changes
|
|
|
|
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scrollwheel to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch is different than the one in file 'scroll.patch' (STR 3521).
It takes care of distinct mousewheel delta calculation for vertical
and horizontal mousewheels and avoids the "fallthrough" case.
Note: macOS takes care of this, there's no special handling required.
To do: the Wayland platform still needs to be updated.
|
|
Pure platform specific files like 'src/*_win32.cxx' are excluded from
doxygen processing and don't need doxygen specific guard macros.
Document this fact prominently at the beginning of each file.
Fix exclude patterns and remove duplicates from Doxyfile.in.
|
|
Windows created when another window was grab()'d would always become
dependents under WIN32, hiding them when the grabbed window was hidden.
|
|
|
|
Most of the old code was a leftover of STR 3454 (which fixed winsock
issues).
Also removed an old comment about usage of Windows WSAAsyncSelect()
and why it had been removed (related to Windows socket functions).
|
|
(no code changes)
|
