Todo: fluid-shared can't (yet) be built agains the shared fltk lib
because of some linker errors. Needs investigation.
Note: fluid-shared is basically a test program to demonstrate linking
against the shared FLTK libs but doesn't work yet using VS (MSVC).
This is no problem for the functionality.
fl_filename_absolute can no generate a path using arbitrary source paths.
Fl_Menu_ adds find_item_with_user_data and find_item_with_argument
Fl_String adds find(string, start)
This is intended to reduce layout calculation and resizing of child
widgets until necessary before the Fl_Flex widget and all its
children are drawn in Fl_Flex::draw().
With this commit users no longer need to call layout() to layout the
Fl_Flex widget and its children properly unless they change widget
sizes or show/hide children.
Tabs were drawn incorrectly when children's box was not FL_NO_BOX
Current solution is cleaned up and always redraws tabs area
without leaving breadcrumbs behind
This method should greatly improve the overlapping calculations.
Tested with super wide and super many tabs.
Also documented every method in the class.
... so they are not inherited by consumers of the library.
Remove 'add_definitions(-DFL_LIBRARY)' from src/CMakeLists.txt
This is not necessary, see CMake/fl_add_library.cmake
Don't set obsolete property 'CLEAN_DIRECT_OUTPUT' which was removed
in CMake 2.8.0.
That commit's goal was to use an algorithm that does not assume
that number keys are at keycodes 10-19, which may not hold with
"special" keyboards. Unfortunately, the new algorithm requires
Mutter V12 and fails with Mutter V11, used by Debian 12.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scrollwheel to use it for both
scrolling directions.
This concludes "handling shift + mousewheel" for all supported platforms.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scrollwheel to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch is different than the one in file 'scroll.patch' (STR 3521).
It takes care of distinct mousewheel delta calculation for vertical
and horizontal mousewheels and avoids the "fallthrough" case.
Note: macOS takes care of this, there's no special handling required.
To do: the Wayland platform still needs to be updated.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scroll button to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch has been provided by Manolo in file 'scroll.patch'
(see STR 3521).
Libdecor complicates what should be simple, to close a decorated window,
because it uses the titlebar after return from the closing callback function.
Thus, FLTK delays the sending of the FL_CLOSE event to the window,
only when libdecor runs in CSD mode.
The old version would send FL_MOVE events after dragging with more
than one mouse buttons pressed, as soon as the first button was
released.
The new version sends FL_DRAG until the last mouse button is released
and then FL_MOVE, as usual.
This change affects dragging only if more than one mouse button is
pushed and held while dragging. The order of pushing and releasing
mouse buttons does not affect the behavior.
Note: this may be somewhat confusing if the user enters out-of-range
values manually because they are overwritten immediately with valid
input but the effects seen in issue #749 are IMHO worse.
Notes:
(1) Fl::e_state holds the current state of all mouse buttons which is
returned by Fl::event_buttons() - "plural form".
(2) Fl::e_keysym holds the "key" of the current event which can be a
mouse button, returned by Fl::event_button() - "singular form".
Unfortunately (sigh), the KDE Wayland compositor does not seem to support
correctly, that is, as described by the Wayland protocol, popup windows
that are taller than the display : there is no means to make it draw such popup
so that part of it is above the screen top, whereas the 3 other tested compositors
(Mutter, Weston, Sway) don't have this problem.
This commit implements a new approach to draw tall menu windows, and uses
it only with the KDE compositor : instead of asking the compositor to slide the
menu window up, the menu window remains at a fixed position and the graphics
inside the window is slided up.
This requires to add a member variable, int offset_y, to class menuwindow, that
gets used only for the Wayland platform and that contains the vertical offset by which
graphics to the menu window is moved, expressed in FLTK units. An accessor
to the address of this member variable is added to class Fl_Window_Driver.
Pure platform specific files like 'src/*_win32.cxx' are excluded from
doxygen processing and don't need doxygen specific guard macros.
Document this fact prominently at the beginning of each file.
Fix exclude patterns and remove duplicates from Doxyfile.in.
... if _WIN32_IE is not defined. Older MinGW versions would
otherwise not define SHGFP_TYPE_CURRENT which is needed since
commit 5a4e7caa54 that fixes
GitHub issue #710: "Fl_Preferences not stored on Windows 10".
This commit is based on Ian's work as discussed in fltk.coredev, thread
"fltk-1.4 build error in Fl_WinAPI_System_Driver.cxx with 32-bit mingw"
on Apr 20, 2023.
This initialization would prevent changing the 'selectbox' type
automatically when changing the FLTK scheme.
It would also require to set the FLTK scheme *before* the constructor
of Fl_Tree_Prefs (i.e. Fl_Tree) is executed which is unexpected and
error prone for user code.
It is up to the user program to set another boxtype after the
constructor if needed.
- add public getter and setter for
- document the new methods
- document that these methods are not yet used internally
- remove unnecessary friend declaration 'NEEDS_KEYBOARD' flag
- simplify Fl::focus(Fl_Widget *) using the new methods.
Unfortunately `execute_process(COMMAND pkg-config ...)` used for
CMake versions lower than 3.4 appends a trailing newline ('\n')
to the output variable which must be removed.
Replace double slash '//' returned by pkg-config with a single '/'
for consistency (applies to all CMake versions).
Tested with CMake 3.2.3 but we should probably raise the minimal
CMake version to a more recent version in the future.
See GitHub issue #710: "Fl_Preferences not stored on Windows 10"
Summary: don't use the undocumented registry key "Shell Folders",
use function SHGetFolderPathW() instead although this function is
meanwhile deprecated (but available since Windows XP).
Note: tested with 32-bit build running on Windows XP (works).
The previous attempt to fix this issue in commit
dcb4c39956 missed to remove the keyword
'struct' in the offending statement. This new commit actually removes
the compiler warning.
This allows to bypass what looks like a Cairo bug:
FLTK_SCALING_FACTOR=1.7 bin/test/tabs
click on tab2
---> crash
But no crash with other scaling factor values (e.g., 1.8).
* interactive layout alignment rewritten
* interface for new alignment rules
* new alignment dialog box
* user defined layout rules added
* layout rules can be stored in projects, settings, and external files
* Valgrind verification
- remove separate libfltk_cairo to avoid cyclic dependencies, but
- keep a dummy libfltk_cairo in 1.4.0 for backwards compatibility
- move cairo/Fl_Cairo.cxx to src/Fl_Cairo.cxx
- add preliminary Cairo support for Visual Studio (MSVC)
Static linking is not affected by this change, but users building
with hand-made Makefiles will have to remove libfltk_cairo starting
with FLTK 1.4.0. The dummy library can be linked for backwards
compatibility but it will be removed later (in 1.4.x or 1.5.0).
The shared FLTK library libfltk.{so|dylib|dll|..} depends on libcairo
if and only if FLTK is built with one of the Cairo options. This has
always been the case for OPTION_CAIROEXT but is now also true if only
OPTION_CAIRO is selected, i.e. FLTK programs linked with a Cairo
enabled shared FLTK library will also be linked with libcairo. The same
is true for configure options --enable-cairo and --enable-cairoext,
respectively.
Preliminary Cairo support for MSVC now detects a Cairo installation
using the CMake variable FLTK_CAIRO_DIR which must be set by the user.
Note that this feature is temporary and may be changed in the future
for a better and more comfortable version.
Refactor the internal class HV_Edit_Buffer by deriving it from the
the recently extended Fl_String class.
The class HV_Edit_Buffer still needs some "special" methods but the
code could be simplified substantially.
- add true unittest and Fl_String testing
- interface and printout are similar to gtest
without requiring external linkage.
just run `unittest --core`.
- new Fl_String API
- extended API to fl_input_str and fl_password_str
- co-authored-by: Albrecht Schlosser <albrechts.fltk@online.de>
... and fix a typo.
This warning was reported for gcc 12.2 (MinGW-w64 / MSYS2) but may have
appeared in earlier gcc versions (gcc 9.4 is not affected).
It's very likely that this warning needs '-O2' or '-O3' to be issued.
Compiling Fl_Native_File_Chooser_WIN32.cxx...
fl_dnd_win32.cxx:436:11: warning: private field 'm_EnumF' is not used [-Wunused-private-field]
FLEnum *m_EnumF;
^
1 warning generated.
Fl_Native_File_Chooser_WIN32.cxx:378:19: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
bool unixpath = IsUnixPath(_directory) | IsUnixPath(_preset_file); // caller uses unix paths?
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||
Fl_Native_File_Chooser_WIN32.cxx:378:19: note: cast one or both operands to int to silence this warning
1 warning generated.
Most of the old code was a leftover of STR 3454 (which fixed winsock
issues).
Also removed an old comment about usage of Windows WSAAsyncSelect()
and why it had been removed (related to Windows socket functions).
ManoloFLTK