Vcpkg defaults to installing packages for x86-windows, and from the
perspective of x64 builds, the packages installed just cannot be
found -- and the reason is not very obvious.
Having an example with commands that will install both x86 and x64 is
probably the right thing to do in this day and age -- and if somebody
only wants one and not the other, seeing a package name with architecture
specified helps with guessing how to achieve that.
Closes#22075.
These functions have better names than the existing GetScaledXXX() ones,
so add them to be able to use them in the new code, even if we still
keep the old ones for compatibility.
Now wxMSW also stores the scale factor, even if it doesn't use it in its
GetScaledXXX(), so it doesn't seem useful to have this symbol for
distinguishing the platforms with and without bitmap scale factor
support, when we can just use wxHAS_DPI_INDEPENDENT_PIXELS instead in
the only place where this was used.
And as this symbol was added quite recently, in 2c1f4c002d (Add
wxBitmap::SetScaleFactor(), 2021-10-23), we can hopefully just remove it
without breaking any existing code, if we do it right now.
Using wxHAS_ prefix is more consistent with all the other similar
symbols, using wxHAVE_ was a mistake, that we have to pay for by
preserving the old name now (as it is actually already used in some code
outside of the library).
The fact that it's used also shows that it's better to document this
symbol, even if just to explain that it normally shouldn't be used, as
we can't really hide it anyhow.
We need to be able to change the scale factor of the bitmaps returned by
wxBitmapBundle::GetBitmap(), so add a function allowing to do this.
Also add wxHAS_BITMAP_SCALE_FACTOR allowing to check whether this
function actually does something non-trivial and explain in the docs
that GetScaleFactor() always returns 1 on the platforms where this
symbol is not defined.
Unlike the existing wxHAS_IMAGES_IN_RESOURCES constant defined only
under MSW, the new one is also defined under Mac and could be defined
for the other platforms/ports later (e.g. wxQt could probably support it
too).
It's unfortunate that two very similar constants are needed, but it
doesn't seem wise to change the meaning of the existing constant, as
this would change how the commonly used wxICON() and wxBITMAP() macros
behave and would break all our own samples that use them for their frame
icon but don't embed this icon into the bundle resources under Mac.
Do change the toolbar sample to use the new constant however, as this
one does include the bitmaps it uses in its bundle under Mac.
Note that this support is still incomplete, notably we don't have
*_vc17.sln files yet and the official build scripts haven't been updated
to build MSVS 2022 binaries neither.
Make configure behaviour consistent with CMake the default value of 0
for wxUSE_LIBLZMA in setup.h under MSW.
This also means that dependency on the system liblzma is not picked up
by default when --disable-sys-libs configure option is used, as this was
rather unexpected.
Using non-PCRE system regex library, which was the only build variant
when wxHAS_REGEX_ADVANCED was not defined, is not supported any more, so
simplify the code by not testing for it.
Add yet another wxDEPRECATED_XXX macro, this one simply expanding to
C++14 [[deprecated]] attribute if it's available and nothing otherwise.
It's a bit ridiculous to have so many different macros for deprecating
things, but the new one is useful because the standard attribute can be
used to deprecated enum elements, which is impossible with MSVC-specific
__declspec(deprecated).
In newer doxygen versions, the label was being used as the caption
for the image and not appearing in the 3rd column. The only way to
really fix this seems to be to make the image the last column so that
it doesn't eat the remaining text (there is no way to escape it
apparently).
Currently this simply links to the existing port-specific installation
instructions, but this should provide a less confusing and more
prominent entry point than the existing topics.
Events and sizing is more important than Unicode or i18n, so put them
first.
Also "important" doesn't really mean anything, so use a hopefully more
clear section name.
Warning about gettext versions earlier than 0.10.35 is pointless,
as even 0.10.35 is from 2001, and so old it isn't even available
on GNU mirrors anymore. We shall not recommend a specific version in
the first place.
The proper way to start a new translation is to use msginit to initialize
a .po file -- just copying the .pot leaves many fields to their default
values, which the translator would need to fill in manually (the
Plural-Forms: field in particular).
