This opens many customization possibilities beyond those provided by
wxWebView API and also allows to process CEF IPC messages much more
efficiently than what is possible using wxEvents.
Closes#24336.
It shouldn't, and now doesn't, use these libraries directly and
shouldn't depend on them to avoid introducing unnecessary requirements
for the applications which use it without XRC.
Previously this was used only for linking the samples, which ensured
that they found the libraries directly referenced by them, but this
wasn't enough to find the libraries referenced indirectly, via another
library (e.g. wxxml used by wxxrc internally but not necessarily
referenced by the sample using XRC) because DT_RUNPATH is not used in
this case, as documented in Linux ld.so(8).
Ensure that such libraries are found nevertheless by setting runpath
for all the libraries too.
Note that it would probably be more logical to just get rid of
SAMPLES_RPATH_FLAG and use DYLIB_RPATH_FLAG everywhere, but this would
result in a ton of changes, so keep the old variable for now and just
set it to the same value to avoid this and keep the possibility to
change it to a different value if necessary later.
wxMSW could already be compiled for ARM with MSVC, but due to not
defining any ARCH_SUFFIX for ARM, makefile.vc used to place objectsi
and libraries to the same folder as x86 objects and libraries.
A completely different question is what kind of Windows runs on 32-bit
ARM, and whether one can run regular desktop apps on it.
This commit mimics what f69dbaa1 did for ARM64, and adapts it for ARM.
Closes#24222.
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.
Just include wxWebViewChromium in the webview library if it's enabled
during the build.
There doesn't seem to be any reason to build a separate library for it,
it's not really different from the other disabled by default wxWebView
backend (Edge).
And now that we don't need to link with an extra library, there is also
no need to have a separate webview_chromium sample, so just add a
possibility to run webview sample itself using Chromium backend by
setting WX_WEBVIEW_BACKEND environment variable.
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.
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.
Add MSW-specific wxDarkModeSettings class which can be used to customize
the colours used in the dark mode (and will be also used for other
customizations in the future).
This commit is best viewed using Git --color-moved option.
Using generic implementation doesn't work any longer since the switch to
using composited windows (i.e. turning on WS_EX_COMPOSITED) by default
as drawing using wxClientDC has no effect.
So implement wxOverlay in a different way by using a layered window
covering the original window and drawing on it instead. This is similar
to Cocoa implementation of wxOverlay.
Closes#23047.
This resulted in its base class wxNavigationEnabled<wxBookCtrlBase>
being instantiated both in the application itself (when using it
directly) and inside the wx DLLs (when using another class using the
same base class, but defined in the DLL, such as wxAuiNotebook) and gave
linking errors.
Work around this by explicitly defining wxCompositeBookCtrlBase,
corresponding to this base class, ourselves and export it from the DLL
so that it's the single instance which is always used.
Closes#22805.
Drop disabled by default and pretty useless memory tracing code and all
the overlapping and poorly documented build options related to it.
Remove memory.cpp entirely and update all the make/project files, but
preserve the now completely trivial wx/memory.h for compatibility and
also keep including wx/string.h from wx/object.h as it seems like a lot
of existing code actually depends on this, even if it should not.
Replace the options in the propgrid sample with a couple of other
debug-related options that were not used before to avoid leaving the
"Debugging Section" completely empty.
Add experimental wxApp::MSWEnableDarkMode().
For now this is very incomplete and just uses the basic API for setting
the preferred application mode, which only works for the standard
dialogs and popup menus, but it's a start.
Support of dark mode is also limited to Windows 10 20H1 and later, but
this should, hopefully, be not a problem in practice as few people
should be using pre-2020 Windows 10 versions by now.
There is no need to have them as they were identical for all platforms.
This basically reverts 5b87bd6c0b (Split wxPanel in wxPanelBase and
platform-specific files., 2011-03-20) as, 10+ years later, it turns out
that we're not going to have more MSW-specific parts, but none of them.
No real changes.
Always use thread_local as we can rely on compiler TLS support working
under Windows 7 and later.
There are some known problems in MinGW thread local variable support,
but they only affect (obsolete) 32-bit builds and will hopefully be
fixed in this compiler soon.
See #22917.
