Option: ./configure --disable-test build test programs (default=yes)
Thanks for the patch(es) to @michaelbaeuerle.
I added `make test` to be able to build the test programs from the
FLTK root directory if FLTK was configured with --disable-test.
- it's no longer necessary to take care of the change in the layout of "struct libdecor"
between versions ≤ 0.2.2 and > 0.2.2 of libdecor
- version > 0.2.2 contains MR131, that is, it defines LIBDECOR_WINDOW_STATE_RESIZING
so the hack to emulate it is no longer necessary
- CMake option FLTK_USE_SYSTEM_LIBDECOR now requires libdecor version > 0.2.2
to be activated, otherwise the bundled libdecor is used
- what will be the libdecor version after 0.2.2 (0.2.3? 0.3.0?) is not known as of today
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.
This commit makes the default FLTK build setting use libdecor
as packaged in Linux when the build system contains packages
libdecor-0-dev and libdecor-0-plugin-1-gtk in version ≥ 0.2.0.
Otherwise, FLTK uses the bundled version of libdecor.
This includes situations where package libdecor-0-dev is
present in an earlier version.
- add CMake option 'OPTION_USE_STD'
- add configure option '--enable-use_std'
- move FL/Fl_String.H to src/Fl_String.H
- move FL/Fl_Int_Vector.H to src/Fl_Int_Vector.H
- remove Fl_String from demo program examples/callbacks.cxx
- remove Fl_Int_Vector from public header FL/Fl_Table.H
- some methods of Fl_Table are no longer inline
- add CMake option OPTION_USE_STD to allow std::string in some
selected functions and methods
Experimental, may be removed before release:
- use either Fl_Int_Vector or std::vector in Fl_Table depending
on CMake OPTION_USE_STD or configure --enable-use_std
Move all fl_filename* functions that use Fl_String to fluid
Main changes in fluid:
- add fluid_filename.h and .cxx
- include "fluid_filename.h" rather than <FL/filename.H>
Update fl_input(), fl_password() and test/ask
- add maxchar parameter to fl_input() and fl_password()
- fl_input_str() and fl_password_str() are optional and return
std::string if enabled (FLTK_USE_STD)
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.
- 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.
This variable has never been used in the code. Configure and CMake
look for a *working* libpng (HAVE_PNG) and set variable HAVE_PNG_H
if the header <png.h> can be included.
The alternative to include <libpng/png.h> is always used in the #else
clause and doesn't need its own config variable. Configure and CMake
log what they find, hence this extra variable is not necessary.
