| Age | Commit message (Collapse) | Author |
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fl_Window::get_size_range()
|
|
|
|
A change to Fl_Input_Choice callbacks slipped into
fd791a068e39e06785adc44693f4c533d3d6c903.
This Commit removes that change. It may need to be
fixed and reapplied later in its own Commit.
|
|
|
|
|
|
|
|
|
|
Also, add comment about when call to gtk_surface1_set_modal() is useful or useless but harmless.
|
|
Add '$(LDFLAGS)' to build commands for libs, for details see STR 3434.
This applies to configure/make only, CMake builds are not affected.
|
|
|
|
|
|
- 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.
|
|
|
|
- src/fl_contrast.cxx:
- FL_CONTRAST_LEGACY: reset black/white threshold from 55 to 50
- FL_CONTRAST_CIELAB: change default contrast level from 55 to 39
- test/contrast.cxx:
- set default contrast mode to CIELAB
- add "random color" button to test random foreground colors (text)
- slightly increase terminal size
- make the Fl_Terminal widget the resizable() of the window
|
|
|
|
|
|
|
|
|
|
This has the Mutter compositor open modal windows at the center of their parent window
rather than at an unpredictable display position before this commit.
|
|
|
|
|
|
This DnD gives two data types of the dragged text: text and a gnome-specific type.
The code previously accepted DnD with 1 data type or 4 or more data types,
and processed situations with 2 or 3 data types in a special way that fails
with gnome source apps.
The new code processes situations with 2 and 3 data types just like other ones.
This works OK when dragging from gnome wayland apps.
|
|
|
|
|
|
- center (sub)menu arrow as good as possible
- adjust arrow sizes in Fl_Counter widget
- refactor "oxy" arrow drawing and centering in widgets
|
|
also fix typo mentionned -> mentioned
|
|
Changing _root->find_clicked(..) to just find_clicked(..)
includes the check of _root for NULL, which is probably better
than doing a repeat explicit check and early exit.
|
|
|
|
|
|
Also, remove this text from the doc of Fl_Menu_::down_box()
"If this is FL_NO_BOX then it acts like
FL_THIN_UP_BOX and selection_color() acts like
FL_WHITE, for back compatibility."
that was true only for the Windows platform and that required
selection_color to be replaced by white for menu items which is
not what FLTK 1.4 expects.
The new state of menu item drawings is as follows :
- all platforms draw menu items with the same symbolic colors
- selected items and menu titles are drawn with the selection color
as background color
- menu items are drawn by default with no box but can be given one
by Fl_Menu_::down_box(Fl_Boxtype)
- the text of selected items is drawn with the menu's color
unless fl_contrast() finds it does not make enough contrast with
the background (selection color) and substitutes it with a more
adapted color
- the Windows platform uses a visibly different hue for its default
selection color from what other platforms use
|
|
- improve centering the different arrows
- fix one bug that prevented correct positioning
|
|
... in thread: "FLTK 1.4 Menu Bar Style", started on May 6, 2024
This is about the little triangle (or similar) pointing right when
a submenu exists in a menu. The arrow form differs per scheme.
|
|
|
|
|