Don't bother creating a separate object file for just a few lines of
code in the generic wxIcon implementation, just inline them into
wx/generic/icon.h.
There should be no need to ever have any non-trivial code here as
generic wxIcon is the same thing as wxBitmap anyhow.
The list of the languages to install the message catalogs for has to be
hardcoded in the bakefile currently, so update it to ensure that all the
available catalogs are installed.
Fixes#24880.
Closes#24887.
Add wxAuiSerializer and wxAuiDeserializer classes and SaveLayout() and
LoadLayout() functions in wxAuiManager using them.
Show how these classes can be used to use XML for storing AUI layout in
the sample.
See #24225.
When we install out-of-tree, i.e. with a non-empty DESTDIR, the
wx-config symlink is broken: the target of the symlink is not rooted
in DESTDIR.
It would seem the obvious solution would be to prefix the target of
the symlink with $(DESTDIR) and be done with it. That would solves
cross-compilation cases, but would not fix native build when the
install is done in a staging area to prepare a binary package (e.g.
Linux distributions à-la Debian do that for example).
A way to make the symlink work in both cases is by making it relative.
ln has been supporting a --relative option since coreutils 8.16,
released 2012-03-26, more than 12 years ago now; it is relatively safe
to assume that distributions of today do have an ln that supports that
flag.
For systems that do not support that flag (e.g. *BSD, MacOS), fallback
to creating a non-relative symlink, on the assumpion [0] that on those
systems, DESTDIR is most probably never used. Eventually, in case
creating both symlinks fails, keep doing a copy as the ultimate
fallback.
[0] https://github.com/wxWidgets/wxWidgets/pull/24622#issuecomment-2184047170Closes#24622.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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.
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>
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.
Bill Su
Vadim Zeitlin
Scott Talbert
Yann E. MORIN
Maarten Bent
ali kettab
Viachaslau Lisouski
Stefan CsomorandVadim Zeitlin
Antti Nietosvaara
Artur Wieczorek
AliKet