Unfortunately this *appears* to be a new constraint caused by the great
new features of Fl_Tabs like overflow handling etc. and fixing drawing
issues in the tab area (since FLTK 1.4).
However, this conflict has already been there in 1.3 but didn't cause
visual artifacts in normal use.
As discussed in the context of PR #1187 the previous return value '-1'
was misleading and undocumented. The docs mentioned only '1' and '0'.
User code that used the return value as documented (like a `bool`)
would make the wrong decision if the return value was '-1': true
(selected) instead false (out of range).
This commit fixes the code by doing what the docs define and clarifies
the documentation.
Further documentation improvements of Fl_Table (example code used a
method that is not defined in Fl_Table) and of Fl_Table_Row are
included as well.
Doxygen docs of two methods of Fl_Table_Row moved to the .cxx file
where they belong according to the CMP.
This reverts the improvement of #1139 in the default build which is
now only available with FL_ABI_VERSION=10401 or higher.
Users that need this improvement need to build with the required
ABI version by setting it with configure or CMake.
New compiler warning detected by g++ 14.2.0 building with CMake
in Release mode. This *temporary* fix suppresses the warning but uses
even larger fixed size buffers.
Todo: these nasty warnings caused by using fixed buffer sizes should
be removed by using std::string in FLTK 1.5.0.
This bit mask was added in commit 53b40f4138 in an attempt
to *document* reserved bits but it turned out that this mask could
have negative side effects on some newer compilers by propagating
the enum to an 'unsigned int' and issuing compiler warnings.
See this comment and follow-up's in fltk.general:
https://groups.google.com/g/fltkgeneral/c/7xrDkbkxiyw/m/rzEIJ7XhAgAJ
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.
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).
