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.
For some obscure reason finding the jpeg lib *after* configuring for
local zlib and/or local png lib failed and thus switched to using the
local jpeg unexpectedly. Searching for jpeg libs before png/zlib fixes
this issue.
Note: this is a pragmatic fix (aka workaround) rather than fixing the
underlying issue. It would be interesting to find out why this happened.
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
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.
