| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
This commit removes changes in class Fl_Group introduced in 1c6a0c1.
|
|
line color (#995)
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.
|
|
|
|
|
|
menubar.
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.
|
|
|
|
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
|
|
menubar.
Fix some border cases.
|
|
menubar.
See "Menu navigation in FLTK is different from Ubuntu X11 navigation" in fltk.general.
Menubar wrapping is what macOS and gnome applications do.
|
|
Not easy to get it right in absence of any documentation for "GTK Shell" protocol.
|
|
|
|
|
|
|
|
Such max values must be checked to be larger than min values, else error may occur.
|
|
|
|
support key repeats
|
|
... by Brian Larsen
|
|
|
|
no code changes
|
|
|
|
|
|
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>
|
|
|
|
styleMask
|
|
|
|
|
|
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.
|
|
|
|
Some applications insist on sending XDND protocol version 5 and
rejected (ignored) FLTK as DND receiver because we allowed only
protocol version 4. Known apps: Google Chrome and Chromium.
This commit enables XDND protocol version 5 in FLTK programs as
DND receiver.
|
|
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
|
|
|
|
|
|
(#989)
|
|
|
|
|
|
|
