- Fl_Grid: force layout() on resize() - needed for GL subwindows
- test/cube.cxx:
- use end() in constructor of class cube_box
- ensure not to change the current group when adding a button
- FL/Fl_Grid.H: header file
- src/Fl_Grid.cxx: implementation
- examples/grid-simple.cxx: simple example program
- test/cube.cxx: use Fl_Grid for layout
- test/grid_alignment.cxx: test cell alignment and other functions
- test/grid_buttons.cxx: demo program as discussed in fltk.general
- test/grid_login.cxx: like test/flex_login.cxx but with Fl_Grid
- test/flex_login.cxx: modified to match test/grid_login.cxx
- remove static variables and functions
- make move_intersection() virtual
- add (protected) cursor access methods
These changes were inspired by STR 2791 where the user proposing an
enhancement was not able to subclass Fl_Tile properly. This commit
fixes the mentioned issues and enables subclassing without copying
internal code.
... "when there's no current window".
Silently ignore GLUT function calls that need a current window if the
current window is NULL, return 0 from functions that return an 'int'.
Check if window is shown in Fl_X11_Gl_Window_Driver::swap_buffers().
This would issue "XRequest.nnn: GLXBadDrawable 0x0" on X11 otherwise.
Note: the chosen implementation to ignore GLUT calls silently appears
to be compatible with GLUT (3.7) whereas FreeGLUT 3.0 would issue error
messages and exit. The latter could be implemented as well but would
be much more work.
The user can add an arbitrary number of highly configurable
shell commands through the setting panel. The commands can
be saved as user preferences, inside the .fl file, or exported
to an external file. Shell scripts can be limited to individual
platforms, can have shortcut keys, etc. .
* documentation will follow
* support to call `fltk-config` will follow
This code was (and is still) commented out but it *would* trigger
a "stack buffer overflow" error *if* uncommented.
The new code demonstrates how a binary object (Fl_Preferences 'bed')
can be dumped to a preferences file in binary format (if activated).
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)
See fltk.general, thread "Is handling simultaneous Left-click and
Right-click drags supported?" from Jul 12, 2023
Status: FL_DRAG operation is terminated when one mouse button is
released, even if more than one button is actually down. Subsequent
mouse movement is reported as FL_MOVE rather than FL_DRAG, this is
under investigation.
* 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
Flushing the Cairo context is necessary on Windows to make Cairo
drawings appear on the device (screen). This new method makes it easy
for user code to do this correctly after using Cairo drawings.
- add Fl::cairo_flush(cairo_t *)
- document Fl::cairo_flush(cairo_t *)
- reformat Cairo doxygen docs and code (partially)
- use the new method in Fl_Cairo_Window
- use the new method in test/cairo_test.cxx
- other minor (text) changes in test/cairo_test.cxx
- add test/cairo_test to the demo menu (test/demo.menu)
On the Windows platform Cairo drawings must be flushed explicitly.
This is done in Fl_Cairo_Window after calling the draw callback but
it was neither done nor documented in test/cairo_test.cxx when using
another type of Window with its overloaded draw() method, i.e. when
FLTK was configured with --enable-cairoext or CMake OPTION_CAIROEXT.
Note: user code must either explicitly flush the Cairo drawings as
done here or destroy the Cairo context which is not done in this demo
because the Cairo context should be kept alive.
- 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.
