- add CMake option 'OPTION_USE_STD'
- add configure option '--enable-use_std'
- move FL/Fl_String.H to src/Fl_String.H
- move FL/Fl_Int_Vector.H to src/Fl_Int_Vector.H
- remove Fl_String from demo program examples/callbacks.cxx
- remove Fl_Int_Vector from public header FL/Fl_Table.H
- some methods of Fl_Table are no longer inline
- add CMake option OPTION_USE_STD to allow std::string in some
selected functions and methods
Experimental, may be removed before release:
- use either Fl_Int_Vector or std::vector in Fl_Table depending
on CMake OPTION_USE_STD or configure --enable-use_std
Move all fl_filename* functions that use Fl_String to fluid
Main changes in fluid:
- add fluid_filename.h and .cxx
- include "fluid_filename.h" rather than <FL/filename.H>
Update fl_input(), fl_password() and test/ask
- add maxchar parameter to fl_input() and fl_password()
- fl_input_str() and fl_password_str() are optional and return
std::string if enabled (FLTK_USE_STD)
That commit's goal was to use an algorithm that does not assume
that number keys are at keycodes 10-19, which may not hold with
"special" keyboards. Unfortunately, the new algorithm requires
Mutter V12 and fails with Mutter V11, used by Debian 12.
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.
This concludes "handling shift + mousewheel" for all supported platforms.
Notes:
(1) Fl::e_state holds the current state of all mouse buttons which is
returned by Fl::event_buttons() - "plural form".
(2) Fl::e_keysym holds the "key" of the current event which can be a
mouse button, returned by Fl::event_button() - "singular form".
Unfortunately (sigh), the KDE Wayland compositor does not seem to support
correctly, that is, as described by the Wayland protocol, popup windows
that are taller than the display : there is no means to make it draw such popup
so that part of it is above the screen top, whereas the 3 other tested compositors
(Mutter, Weston, Sway) don't have this problem.
This commit implements a new approach to draw tall menu windows, and uses
it only with the KDE compositor : instead of asking the compositor to slide the
menu window up, the menu window remains at a fixed position and the graphics
inside the window is slided up.
This requires to add a member variable, int offset_y, to class menuwindow, that
gets used only for the Wayland platform and that contains the vertical offset by which
graphics to the menu window is moved, expressed in FLTK units. An accessor
to the address of this member variable is added to class Fl_Window_Driver.
