Even if <xlocale.h> exists, the whole API that wx requires (specifically
strtod_l() and similar) may not be available. This is the case
on e.g. OpenIndiana (SunOS).
On OpenIndiana (SunOS) the result is different when compiled as C,
and the C++ result is what matters to wxWidgets.
Fixes compilation of src/common/strconv.cpp on OpenIndiana.
In configure moved WX_ARG_FEATURE(regkey outside of if.
Have configure under windows skip linking to X11.
Have configure check for "USE_WIN32" instead of for "wxUSE_MSW".
wxUSE_FSWATCHER
wxUSE_SNGLINST_CHECKER
wxUSE_SOCKETS
wxUSE_DIB
While we have to keep these conversions enabled by default, they are very
dangerous as they can result in silent data loss on any system not using a
locale with UTF-8 encoding, i.e. always under MSW.
Allow mitigating this by defining wxNO_UNSAFE_WXSTRING_CONV when compiling the
application code using the library, which makes these conversions invisible to
the user code, and so can be used without recompiling the library.
Also add wxUSE_UNSAFE_WXSTRING_CONV which can be set to 0 when compiling the
library to disable these conversions globally for all applications using it.
Closes#11830.
Compile accessibility support on Windows by default now that the generic
wxDataViewCtrl control implements accessible interface. After the
changes from 7dab555f71, accessibility
support is much more lightweight and doesn't interfere with normal win32
behavior, so this change shouldn't affect accessibility-unaware code in
any way.
The changes in 065135adcc caused AVKit to be linked even when the deployment target was set to 10.7 or 10.8 which would not be available on the target machine. The deployment target is now checked before using AVKit.
QTKit has been removed from OS X 10.12 SDK.
QTKit has been superseded by AVFoundation since OS X 10.7.
Since wxWidgets >= 3.1 requires 10.7 anyway there is no reason to support the old API.
Additionally the AVFoundation implementation may use AVKit (available since 10.9). It will be used when available and the deployment target is met.
Closes https://github.com/wxWidgets/wxWidgets/pull/337
Since OS X Sierra 10.12 QTKit has been removed. wxMediaCtrl for OS X already had a fallback to AVFoundation implemented. This makes sure this will be used and the correct media Frameworks are used for linking.
Add a new class allowing to store passwords and other sensitive information
using the OS-provided facilities.
Add implementations for all the main platforms, documentation and a new sample
(which contains an ad hoc unit test as the real unit test for this class would
probably be a bad idea as it wouldn't run in non-interactive contexts and
could show OS level dialog boxes if it did).
The implementation using XSendEvent() with classic input events can't work
with GTK+ 3 anyhow because it uses XInput2 which is incompatible with them, so
warn the user about this and don't compile useless code into the library.
The check added in 841af56084 was not good
enough, some MinGW versions do have imagehlp.h, but don't define all the API
functions we need in it. Luckily, we can check for this simply by verifying
that API_VERSION_NUMBER is big enough.
Closes#17451.
AX_CXX_COMPILE_STDCXX() macro does not define HAVE_CXX11 when C++11 is
required (and not optional, as with --enable-cxx11), so the build was broken
when --with-cxx=11 was used under OS X as -stdlib=libc++ was not used.
Fix this and also leave only a single AX_CXX_COMPILE_STDCXX() check for C++11,
this saves us ~1000 lines in configure.
MinGW64 and TDM-GCC come with imagehlp.h and can compile the code using debug
help API too, so enable wxUSE_DBGHELP when using these compilers by default
and also allow enabling it via a configure option.
Use the macro versions from 2.24.29 and 3.18.8 (latest available in Debian for
GTK+ 2 and 3 respectively) to fix the detection of pkg-config which was
incorrect in the old gtk-2.0.m4.
Closes#17027.
Latest versions of CppUnit removed cppunit-config and use pkg-config instead,
so try the latter if the former is not found to detect CppUnit under Fedora 24
for example.
Closes#17387.
There are just too many of these warnings because GTK+ people are extremely
deprecation-happy and like marking functions which need to be used for the
code to work with the older GTK+ versions as deprecated. Because of this, in
many cases we have no choice but to continue to use the now deprecated
functions and the only way to avoid them is to pepper the code with the
pragmas doing this. Disabling the warning globally seems like the lesser evil
because not disabling them at all is worse than useless as the flood of the
unavoidable deprecation warnings hides any real ones that might occur.
Due to recent changes in utils, stdpath and the removal of carbon, building on
OS X was broken by various compiler errors and linker issues.
Closes https://github.com/wxWidgets/wxWidgets/pull/210
The results of the checks for the command line options are not useful to show
as presumably the user already knows which options were used for invoking
configure, and so the results of these checks are known as well (with the only
exception of --with-xxx options when configure detects whether to use the
system or the built-in version of the library on its own, but we already
summarize the results of these checks at the end anyhow).
Just don't flood the user with all the messages about checking this and do our
job silently.
Cocoa has been the default toolkit in wxWidgets for a long time. There is really no good reason to use Carbon in 2016 and this removes a lot of unused and unmaintained code.
It doesn't make much sense to have dependencies on the system libraries when
using a built-in library as this makes the binaries using wxWidgets unportable
to the systems without the matching versions of these libraries which was
probably the goal if the built-in library is used.
