This is similar to 858248d055 (Fix declaration shadow warning in
wxHtmlHelpFrame, 2021-04-21) and fixes another -Wshadow from gcc 11 by
getting rid of the last parameter confusingly named as its type.
See #19153.
Hide wxOSX implementation details by storing NSImage associated with the
bundle in a separate global map instead of making it part of
wxBitmapBundleImpl itself.
See https://github.com/wxWidgets/wxWidgets/pull/2555
This function was defined in wxGTK and wxOSX, but not in wxMSW or the
other ports, but it can be useful there too, so make it public and
define it in common code.
These resource files didn't appear in the .bkl ones and so were not used
at all and were not worth being used anyhow, as they didn't differ
significantly from sample.rc.
This is required for high resolution bitmaps support and it will be
needed in other samples too, so use it for all of them.
This probably will result in some problems due to remaining bugs with
high DPI support, but it should make them more noticeable and so should
help with finding and fixing them.
This warning was introduced by the recent 999340f288 (Check that
wxImageList::Create() is not called more than once, 2021-10-17), fix it
by using NULL for HIMAGELIST which is a pointer internally.
Closes#19298.
This avoids resizing the bitmaps in some common use cases and is similar
to the previous commit doing the same thing for wxButton.
Notice that this introduces a slight change of behaviour, as
AdjustToolBitmapSize() now can reduce, as well as increase, the size of
bitmaps used, which is necessary in order to shrink the bitmaps when
moving from a higher DPI resolution display to a lower-resolution one.
This is not 100% backwards-compatible, but should only have not very bad
cosmetic effects.
Avoid scaling the bitmaps by using the preferred size for them.
This results in significantly better appearance without any real
drawbacks in practice at 125% and 175% DPI scaling in the common case
when just a single and double-sized bitmaps are available, and still
seems to be acceptable at 150% scaling in this case.
Using bitmaps of preferred size avoids scaling and results in much
better appearance, so add methods allowing querying the bundle about the
bitmaps it supports and implement them in the various implementations.
This is not actually used anywhere yet, but will be soon.
Getting errors due to "missing" Nano SVG headers can be confusing, as
it's not immediately clear why are they missing, so try to make things
more explicit by using __has_include(), if available, to test for the
header before including it and giving a better error message if it
fails.
It still won't help people not using C++17 or those not reading error
messages, but should be better than nothing.
Unfortunately even using CallAfter() doesn't allow to completely repair
the toolbar display after moving it to a display with a different
fractional scaling, e.g. from 125% to 175%. There are still some minor
but visible display artefacts in this case that we can't get rid of even
by resizing the window containing the toolbar programmatically -- even
though doing it interactively does help.
Recreate wxImageList used for the bitmaps internally with the bitmaps of
the size corresponding to the new DPI.
This commit is best viewed with --color-moved git option.
Take wxBitmapBundle in wxButton::SetBitmapLabel() and related functions
in order to be able to associate several bitmaps to be used in different
resolutions with the button, instead of just a single bitmap.
Just return a null image instead, as this function can be called when we
don't have any bitmaps too -- as it happens in the Button::Bitmap unit
test, for example.
Nothing here, including the event table for this class using
non-existing wxBitmapButton::OnSysColourChanged (which is just the same
as wxWindow::OnSysColourChanged, in fact), was needed any longer ever
since the changes of a6fd73d33a (implement wxBitmapButton as just a
wrapper for wxButton under MSW, 2009-06-15), so simply remove all the
unused stuff.
Existing code may call functions taking wxBitmap with wxIcon, due to an
existing conversion from wxIcon to wxBitmap, so we need to provide a
similar conversion to wxBitmapBundle for compatibility.
This reverts commit 4e366b2cfb as it the
code removed by it is still needed and removing it results in unit test
failures in wxBitmapToggleButton unit tests with both GTK 2 and 3.
See https://github.com/wxWidgets/wxWidgets/pull/2548
Don't say that it's only for MSW and GTK 3, as it's also available under
Mac. Also don't use "spellchecking" non-word in the description of a
spell-checking option.
No real changes.
Don't leave m_useMask and m_scaleFactor uninitialized -- even if this
probably doesn't matter, call Create() to make sure they have
well-defined values for the default-constructed objects.
Replace GtkImage with wxGtkImage if necessary, to ensure that we can
always use our own class, to profit from its support for high DPI
images, even for the buttons using stock IDs and so creating GtkImage by
default.
See #19288.
Use the appropriately sized bitmap instead of always using the (scaled
version of the) default one, as was the case since 97f6c85d9b (Add first
version of wxBitmapBundle and use it in wxToolBar, 2021-09-24).
With this change, toolbar bitmaps work correctly in 100% and 200% DPI
scaling.
The existing variants returning wxBitmap are insufficient for non-MSW
ports where the toolbar bitmap size is unavailable otherwise, as
GetToolBitmapSize() value doesn't really correspond to it (which is a
problem on its own, but there is not much that can be done about it by
now).
Having these functions allows to retrieve the actually used bitmap size
by using wxBitmapBundle::GetDefaultSize().
Minimal changes to the code to allow using bigger bitmaps from
wxBitmapBundle in high DPI instead of having to create individual
bitmaps with scale factor greater than 1.
Notice that this is not actually used anywhere in wxGTK yet, but will be
soon.
