- Restrict FL_BUTTONS mask to only three valic mouse buttons.
Pseudo mouse buttons 4-7 are used for FL_MOUSEWHEEL events and
are no longer reflected in Fl::event_buttons().
- Return only state of mouse buttons 1-3 in Fl::event_buttons().
Buttons 4-7 are not "sticky" (used for FL_MOUSEWHEEL).
- Keep undefined keyboard related bits in Fl::event_state() for
backwards compatibility and transparency. These bits may be masked
out in a later release.
- Document Fl::event_state() bits for X11 in src/Fl_x.cxx.
Note: this is a bug fix for X11 only, Wayland and other platforms are
not affected.
Horizontal mousewheel events use pseudo button numbers 6 and 7, resp.,
similar to vertical mousewheel events which use buttons 4 and 5.
The old code erroneously sent FL_RELEASE events for buttons 6 and 7
although it was prevented for buttons 4 and 5 explicitly.
... after filename "expansion" with current directory.
This is done when the entered filename is relative. The old behavior
was confusing and error prone.
Also: improve documentation of Fl_File_Chooser::value(const char *).
Clarify behavior and side effects of this method.
Fl_Tree changed to support system color themes (PR #995)
merging CyprinusCarpio's mods carried over from from issue #972.
* Fl_Tree: use named (colormap) colors to support system color themes (see issue #972). changed connectorcolor() default from gray ramp color to FL_INACTIVE_COLOR (Fl_Color(8)), and similar named colormap colors for icon drawing.
* Fl_Tree ⊞ / ⊟ icons (and on macs, ▶ / ▼icons) are now drawn w/fl_draw() functions instead of with xpm bitmaps for colormap control
---------
Co-authored-by: Greg Ercolano <erco@seriss.com>
This fix requires to be able to recognize whether Fl_Wayland_Window_Driver::resize() is called
by a resize operation of an encompassing widget or not.
To do that, private static int variable group_resize_depth_ is added to class Fl_Group
and an accessor to this variable is added to class Fl_Window_Driver.
Slight behavior change of Fl_Menu_Bar relatively to 1.3: left and right arrow keys
when pressed in the first (resp. last) (sub)menu of a menubar wrap to the menu
at the other end of the bar. Also, left and right arrow keys open the previous
(resp. next) menu of the bar when pressed in a submenu.
Rationale: macOS, gnome and Windows apps equipped with a menubar do that.
- add Fl_Choice widget for layout comparison
- rewrite button callbacks
- improve layout and other details
This is a follow-up to issue #978, "merging" the existing input_choice
demo with "choicetest_v3" as mentioned.
This addresses some border case issues in Fl_Choice wrt erco's
recent Fl_Input_Choice modifications. As Albrecht writes in issue #978:
- The width of the (simulated) menu button in Fl_Choice is shrunk
if the height of the widget is lower than 20 for some schemes.
This (a) is inconsistent, (b) doesn't look good, and (c) doesn't
match the better layout of the Fl_Input_Choice widget after your patch.
- The constant height (+/- 8) of the divider line in some schemes
would overlap the border of the widget if the widget's height is
smaller than about 19. You fixed this in your patch and I "stole"
your [erco's] fix for Fl_Choice.
- The divider line and the box borders of Fl_Choice and Fl_Input_Choice
didn't align properly. I fixed this in my Fl_Choice patch as well
(IMHO this is the right place to fix it).
Differences in size of arrows and overall look varies
with different schemes applied for issue raised by Philip Rose
first on fltk.general:
Subject: Discrepancy between Fl_Choice and Fl_Input_Choice
This method also returns the data pointer of the removed timeout.
This new method is generally useful for user code and particularly
necessary to fix issue #991.
Co-authored-by: Albrecht Schlosser <albrechts.fltk@online.de>
This allows FLTK apps to use the recent frameworks when they run on recent
macOS versions even if the minimum supported macOS version of these apps is more
ancient than the framework.
