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.
Document which pointers can, and can't, be null and when exactly is the
stored bitmap valid, as this is far from being immediately obvious.
No real changes.
Pass wxSize by const reference instead of "const" value.
Note that passing wxSize by value might be not such a bad thing,
actually, but we use const reference for it everywhere else, so do it
here as well for consistency (and the original intention was to do it
like this, missing "&" was just a typo subsequently propagated through
copy-pasting).
No real changes.
Passing non-const data is inconvenient and error-prone, as data can't be
used again after it was modified by Nano SVG, which resulted in the
button using SVG bitmap not working any longer in the toolbar sample
after recreating the toolbar.
So make it easier to do the right thing, while still keeping the
overload taking non-const data for the situations when avoiding an extra
copy is worth it.
Add nanosvg submodule and use it in the generic implementation of this
function.
This is incomplete yet and, notably, doesn't cache the rasterized
images, but already shows that using SVG images works (at least in the
toolbar sample).
