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.
This is intended for backwards compatibility with FLTK 1.3.x code
ported to 1.4.0.
Users defining FL_NO_DEPRECATE can compile old (1.3.x) code w/o
seeing lots of "deprecated" warnings. A legitimate use case is if
old (1.3) code is intended to be used with both FLTK 1.3 and 1.4.
FL_NO_DEPRECATE should NOT be defined if the user's code is targeted
at 1.4.x or later. Users should fix their code to be prepared for
the next minor release (e.g. 1.5.0).
Todo: document this.
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
- remove build option FLTK_USE_KDIALOG replaced by an Fl::option() option
- new run-time option OPTION_FNFC_USES_KDIALOG
- make options OPTION_FNFC_USES_KDIALOG and OPTION_FNFC_USES_ZENITY
false by default
- add mention of new program fltk-options in the doc of Fl::option()
- change logic of choice of the native file chooser under X11/Wayland:
the zenity and kdialog choosers are opt-in; otherwise the GTK file chooser
is used, unless opted out with OPTION_FNFC_USES_GTK
- document that zenity may be interesting for sandboxed apps
- document that both zenity and kdialog make member functions
Fl_Native_File_Chooser::filter_value() inoperable
More precise: ... if the last picked item is in a "detached submenu",
i.e. in one addressed by another menu item with the FL_SUBMENU_POINTER
flag set.
Also: document *why* this is the case, and what the result value is.
- Add 'int Fl_Terminal::handle_unknown_char(int drow, int dcol)'
to write the "unknown" character to the intended display position.
- Define Fl_Terminal::unknown_char as a static variable to avoid
redundancy. In the future this might be overridden by users.
Some old platforms (NetBSD, AIX) implement the common stdio "putchar()"
function as a global macro which poisons the global namespace, preventing
all C and C++ programs from using "putchar()" as a function or method.
There was a long thread about this in fltk.coredev during the period
Mar 25 2024 ~ Apr 4 2024, subject "RFC: Fl_Terminal::putchar() in public API"
as to why we have no choice but to not use putchar() as a method name.
Some of these accessor methods should be private so they can't be used
by user code but - due to compiler issues - they must be public for
HP-UX 11.11 (for details see GitHub Issue #937).
Works now much better with old C99 and C++98 standard compilers.
Fixed: C++ comments in C files and headers included by C files.
There are still some warnings with C90 though but these would be
hard to fix and left as-is for now.
test/fractals.cxx: some arrays were too small by 1, or the compiler
warned at least (false positive?). Anyway, it's fixed now.
* Improve horizontal interactive selection
* Using half-character positions to implement selection
similar to Fl_Input.
* Add word and line selection
* Fix vertical position of text
Clear was setting characters to a space using the current style,
but if the style left Dim/Bold/Inverse (etc) enabled, that was being
used to affect the clear character, and thus affected clearing screen.
Seems weird tho; what if one wants to do a cleol (\033[K) on a screen
that is all inverted text; is there no way to use inverse mode for
clearing to the end of line? Or to delete a character?
Fixed a bug in the handling of xterm color 39 + 49, which avoids
applying Dim/Bold if default color is the special "see through" color
0xffffff00. A test will be added to test/terminal to excercise this
in a follow up commit.
Renamed CharStyle::?gcolor_uchar() -> CharStyle::?gcolor_xterm()
for a consistent naming convention.
Changed fltk_fg_color() from a static func to a CharStyle method
because it needs to access the defaultcolor for the special cases
for xterm colors 39 and 49.
Made CharStyle::attr_color() private, as per Jonathan Griffitts request
in issue #909.
Improved docs regarding effects of Dim/Bold for xterm and non-xterm color
methods.
Fl_Terminal::text?gcolor_xterm() methods now use CharStyle::?gcolor_xterm()
methods, removing the duplicate code logic.
This is a big commit and there are too many changes to list them all.
The main changes are:
- rename all CMake build options to 'FLTK_*'
- export library targets with namespace (prefix) 'fltk::'
- standardize shared library target names with suffix '-shared'
- set public build properties on libraries for consumers
- document library names and aliases in README.CMake.txt
- document changes in "Migrating Code from FLTK 1.3 to 1.4"
- partial backwards compatibility for old user projects
Included but not directly related changes:
- fix Windows (Visual Studio) DLL build
- add CMake function fl_debug_target() to show target properties
- don't build test programs if FLTK is a subproject
- internal: reformat CMake code: remove space before '('
Thanks to Matthias and Manolo for their help, testing, and feeback.
Fl_Window_Driver::set_popup_window() is to be used to declare a window should be
positioned relatively to a previously mapped other window. This allows a platform
to process such windows differently from other windows if needed.
Menu and tooltip windows are so declared.
A call to Fl_Window_Driver::set_popup_window() also allows to distinguish a real
menu or tooltip window from a window marked by Fl_Window::set_menu_window()
or by Fl_Window::set_tooltip_window() but that's not a real menu or tooltip.
New member function bool Fl_Screen_Driver::screen_boundaries_known() returns
true by default. A platform where the position of windows inside a screen is hidden
(e.g., Wayland) returns false. This allows FLTK to refrain from trying to make sure
a computed position is inside a screen.
This addresses some issues pointed out by GitHub Issue #875.
Documentation lacked details about Fl_Multi_Label assignment and
correct memory handling.
The new methods
- Fl_Menu_Item::image_label(const Fl_Image *) and
- Fl_Menu_Item::multi_label(const Fl_Multi_Label *)
provide a cleaner interface to assign images and Fl_Multi_Label's
to menu items.
examples/howto-menu-with-images.cxx: carify some issues, fix leak,
and use new Fl_Menu_Item::multi_label(const Fl_Multi_Label *).
This library is no longer needed in FLTK itself. There is only one
demo program (test/forms.cxx) that uses it if it is built. The demo
program displays a message if fltk_forms is not available.
The default is 'enabled' for backwards compatibility but this may
be changed to 'disabled' in a future version.
- the current UI for fallback/default/original shortcut was
confusing, so I remove it until we find something better. I
kept the values so we can reinstate a better interface without
changing the API.
- add fl_draw_radio(...) to standardize radio button drawing
- src/Fl_Light_Button.cxx: use fl_contrast() to determine color of
radio button and check (light) button check marks, and use
new fl_draw_radio() method
- src/Fl_Menu.cxx: same as src/Fl_Light_Button.cxx and use
fl_draw_check() instead of "manually" drawing the check mark
(forgotten in an earlier update)
- add Fl::args_to_utf8() to convert commandline arguments to UTF-8
This new function closes the gap that previously only Visual Studio
applications converted their commandlines to UTF-8.
Tested with MinGW, MSYS2/MinGW-w64, and Visual Studio (2019).
- some documentation missing
- Fl_Tile::resize() not satisfying yet
- minimums work, maximums currently ignored
- 0 size children may make program hang
Although this was not strictly necessary I decided to implement the
proposed patch, but in a slightly different way.
This adds a static public method for internal use only but it wouldn't
do any harm if a user called it.
New public methods:
void clear(void);
void clear(Fl_Color val);
old protected methods made public:
void clear_screen(bool scroll_to_hist=true); // ESC [ 2 J
void clear_screen_home(bool scroll_to_hist=true); // ESC [ H ESC [ 2 J
void cursor_home(void); // ESC [ 0 H
test/terminal modified to test these, and added separate tests
for both the API and ANSI code ways to do these ops.
textcolor() needed for consistency, color() behavior documented.
Both added to the test/terminal app.
Elaborated on the special background "see through" color value + behavior,
tested with color() in test/terminal app.
