Use wxOSX_USE_NSCELL_RENDERER to allow setting it to 0 to revert to the
old code.
Note that the new version is Objective C++, so the old .cpp file had to
be renamed to have .mm extension.
Closes#24053.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
When the wxWidgets sources are in a path containing '++', CMake would
show errors on the command line:
[cmake] RegularExpression::compile(): Nested *?+.
[cmake] RegularExpression::compile(): Error in compile
This happens because the full path was interpreted as a regular
expression when creating the source_groups. Without wxSOURCE_DIR the
regular expressions still match and create correct source groups, so
remove it.
Closes#22738.
Closes#23943.
This has the advantage of returning libraries in their load order, which
is more useful than the unspecified order that was used before.
It also means that this function now has a chance of working under other
systems such as FreeBSD, which also provides dl_iterate_phdr().
This reverts 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23) and all the commits which tried to
fix the breakage caused by it.
While the original change had merit, it seems to be too difficult to fix
all our build systems to avoid embedding manifest when defining this in
the code, like samples/sample.rc does, so revert this change for now.
Maybe it can be reintroduced in the future after switching to some other
build system.
Remove support for unsupported MSVS versions earlier than 2015
and Windows versions earlier than 7 from CMake build as they are not
supported any longer.
Also update wxUSE_GRAPHICS_GDIPLUS and wxUSE_GRAPHICS_DIRECT2D comments
in wxMSW setup.h to remove mentions of unsupported Windows XP but do
mention that MinGW-w64 can use Direct2D.
Closes#23787.
Don't embed the manifests explicitly when wxUSE_DPI_AWARE_MANIFEST is
set any more, as this is done by wx/msw/wx.rc after the changes of
5d630caabd (Make it enough to predefine only wxUSE_DPI_AWARE_MANIFEST,
2023-08-23).
No real changes, just avoid warnings from autoconf 2.71 when
regenerating configure.
Note that double brackets must be used around any code using brackets to
preserve them during the expansion.
There is no reason not to use pkg-config nowadays and this allows to get
rid of some third-party m4 files, which is always nice, and avoids
warnings about GTK 3 and 4 macros being obsolete when regenerating
configure with autoconf 2.71.
This should have been done in c2e5749443 (Fix crash when reading
truncated GIF image, 2023-07-02), but was forgotten there -- so do it
now, and add a comment reminding not to forget it the next time.
See #23409.
Disable warnings while compiling the tests to avoid unnecessary noise in
the CMake output/error files (because we don't really care about
warnings in the test code at all) and also, and more importantly, to
ensure that the tests don't fail even when -Werror is specified in the
CMAKE_CXX_FLAGS globally, as it may happen when wxWidgets is used via
add_subdirectory() from a superproject.
See #23665.
This is the standard and there doesn't seem to be any contemporary
systems where this is not the case. The configure check for it was
originally added in 101c20d554 (attempting to fix sa_handler signature
for IRIX, 2000-04-01), but IRIX is not supported/doesn't exist any
longer, so don't waste time on checking for this.
The real motivation for this change is that the test failed in CMake
builds, showing just
-- Performing Test wxTYPE_SA_HANDLER_IS_INT - Failed
in the log and then resulting in -fpermissive warnings when assigning
wxFatalSignalHandler to sa_handler and it's simpler to just remove the
check than to debug it.
See #23664.
libwebkit2gtk-4.1 has the same API as libwebkit2gtk-4.0, except that the
former links with libsoup-3.0 and the latter links with libsoup-2.4.
Fixes#23630.
Checking LOCATION{_CONFIG} property on interfaces is only supported since CMake 3.19.
Also check the LOCATION and IMPORTED_LIBNAME properties for possible library locations.
Fixes#23632
CMake's has built-in support for checking xkbcommon using FindX11 since
3.18.
But because older CMake versions are supported, add our own module that
checks if the header and library is available.
See #23410.
Closes#23613.
XPM files demonstrating the use of wxBitmapBundle in the XRC files
were not copied when building the XRC sample with CMake.
This should have been part of eaa769a (Use wxBitmapBundle in
wxBitmapComboBox XRC handler, 2022-02-09).
Closes#23612.
This fixes several minor bugs in the loading of `BI_BITFIELDS` bitmaps,
related to handling different header sizes and the colour and alpha
masks.
Closes#23601.
The wxThreadSpecificInfo object created by wxThreadSpecificInfo::Get()
was only released by the wxThreadInternal's cleanup, which meant that it
was leaked if wxThreadSpecificInfo::Get() was called by a thread not
created by wxThread, e.g. when using std::async or std::thread.
Fix this by simply using C++11 thread_local and removing the entire
wxThreadSpecificInfo machinery entirely.
See #23535.
Closes#23543.
This doesn't make any sense, native image list implementation is only
needed for interoperability with the native controls which are not used
by wxUniv, so always use the generic version in it instead.
This fixes link problem due to using wxAppProgressIndicator from the
common wxGauge code, see 11a5b83e2c (Add OS X implementation of
wxAppProgressIndicator., 2015-02-15) and seems to be better than adding
checks for wxUniv there, as this is part of "platform" functionality
rather than "toolkit".
This also pulls in wxTaskBarButton code.
Dark mode support for native controls is not needed in this port, but we
still need DWM-related stuff to make the window title bar use the dark
mode if necessary, so just include all this code in wxUniv.
This symbol is similar to the existing wxNO_IMPLICIT_WXSTRING_ENCODING
and can be defined when building the application (as opposed to when
building the library) to disable implicit wxString conversions to
pointer types, i.e. char*, wchat_t* and void*.
This makes the just added wxUSE_CHAR_CONV_IN_WXSTRING library build
option unnecessary, so remove it.
wxString is always based on std::[w]string since 2c0c727f49 (Remove wx
own wxStringImpl implementation, 2022-11-16) and all containers use
standard containers by default too now -- and there is a separate
wxUSE_STD_CONTAINERS for this anyhow.
The only remaining use of wxUSE_STL was as the default value for
wxUSE_STD_STRING_CONV_IN_WXSTRING option, but it's not really needed
for this neither, and this option can just be set to 0 by default.
Also add wxUSE_CHAR_CONV_IN_WXSTRING which can now be set to 0 too to
disable all unwanted implicit conversions (even "safe" ones, to wide
strings, in addition to the unsafe ones to narrow strings that could be
already disabled with wxUSE_UNSAFE_WXSTRING_CONV) to allow people who
don't want to have any implicit conversions at all to do it.
Keep --enable-stl configure option for compatibility, but warn if it is
used to tell people that it is not needed any longer.
Somewhat incredibly, this file, added back in 2bda0e1738 (added some
wxMSW stuff, 1998-05-20), never contained anything but some commented
out code and so was always totally useless.
Finally remove it.
This is mostly, even if not completely, compatible with the previous
default build using wxUSE_STD_CONTAINERS=0, so try enabling this by
default again. Hopefully it should work better now than the last time we
tried it, see 01871bf642 (Add wxUSE_STD_CONTAINERS and turn it on by
default., 2011-03-30) and the subsequent 7311debd0d (Don't use the
standard containers by default., 2011-05-13).
See #22718.
Use the key code corresponding to the key in the US keyboard layout for
the key down/up events even when not actually using US layout, as this
is much more useful than simply returning 0 as was done before.
It also is compatible with the behaviour of the other ports.
Closes#17643.
Closes#23379.
See #23410.
