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.
- May need a better method name.
- This makes the gap between the image in a label and
the label text user settable.
- Can be tested using test/label app
- append underscores to private varaibles per CMP
- add public Fl_Help_View::copy() and Fl_Help_View::text_selected()
- add public Fl_Help_View::copy_menu_text
- fixes some of the focus handling
- add pulldown menu to copy selected text
Language wrappers can have major issues with FLTK auto deleting
all children of a group if a group is deleted. This event gives individual
widget the opportunity to override auto delete.
As a follow-up to the discussion I used the posted screenshot demo
(thanks to Greg), redesigned it using Fl_Grid, and added it as a
new test program, including Makefiles and CMakeLists.txt.
New file: test/line_style_docs.cxx to create screenshot. Note that the
old test/line_style.cxx is not obsolete, it can be used to test the
line styles interactively.
Docs have been updated in both chapter "Drawing Things" and the
function description.
Also added the new demo to test/demo.menu under "Images for Manual...".
- 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.
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.
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>
The previous procedure using CGWindowListCreateImageFromArray()
is obsoleted in macOS 15.0 .
The new procedure requires an additional framework: ScreenCaptureKit;
FLTK uses it only for macOS ≥ 15.0
- swap 3rd and 4th parameter of fl_contrast()
- change 'Fl_Fontsize fs' to a neutral 'int size' parameter
- clarify documentation of fl_contrast_level() and that different
contrast algorithms use different level values
- clarify that level 39 for the CIELAB mode results in "sufficient"
contrast, i.e. /readable/ text which is the only intention of
fl_contrast().
Reasoning: swapping the arguments looks more natural, i.e. the context
before another argument (size) is what one would usually expect. Since
the 'size' argument doesn't have be a font size, making it a simple
'int size' is more flexible and correct for future extensions.
