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...".
This fix solves these warnings:
$ make html
[100%] Generating HTML documentation
/usr/local/src/fltk-1.4.x.git/src/Fl.cxx:2275: warning: explicit link request to 'include' could not be resolved
/usr/local/src/fltk-1.4.x.git/src/Fl.cxx:2263: warning: explicit link request to 'include' could not be resolved
The previous approach FLTK used to create OpenGL contexts under the X11 platform
followed a different code path to create contexts for OpenGL version 3 and above
than to create contexts for OpenGL versions 1 or 2.
The FLTK code followed exactly "Tutorial: OpenGL 3.0 Context Creation (GLX)"
of the official OpenGL wiki, see:
https://www.khronos.org/opengl/wiki/Tutorial:_OpenGL_3.0_Context_Creation_(GLX)
That code worked OK with Debian 11 and with any tested Linux configurations
in a VM running on Apple hardware. However, it failed with Debian 12 and later
on native Linux boxes to create GL3 contexts with the FL_DOUBLE flag.
That's what issue #1005 reports.
A first attempt to fix#1005 followed instructions given at:
https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXIntro.xml
which supposedly describe how to create OpenGL contexts with GLX.
That had no effect on issue #1005.
This commit erases all attempts to use OpenGL3-specific calls or even
the more modern glXCreateNewContext() function that appears with
GLX version 1.3. The committed code uses only OpenGL 1-age
functions to create OpenGL contexts for X11 windows.
Created contexts follow the "Compatibility Profile" which means they
are compatible with both modern OpenGL3-style and legacy OpenGL1/2-style.
This appears to fix issue #1005.
- 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
