It's a handle, so make it a WXHANDLE rather than WXLPARAM and avoid
casting the handle when calling it (there is still a cast when calling
::SendMessage() inside this function, but this is unavoidable and this
cast was already there anyhow).
No real changes.
Use different members for storing wxBitmap and wxIcon instead of using a
single pointer for storing a heap-allocated copy of either of them
because this is simpler, more efficient due to avoiding unnecessary
conversions and RTTI, and will be simpler to generalize to using
wxBitmapBundle instead of wxBitmap in the upcoming commits.
As a side effect, don't assert in GetIcon() or GetBitmap() if there is
no valid icon or bitmap, as this is inconsistent with the other ports
and wasn't even consistent between these functions in wxMSW itself.
There should be no other changes in behaviour.
This function was used exactly once and it's simpler and more clear to
just inline it into Free() where it was called.
No real changes, this is just a small simplification.
For some reason, wxStaticBitmapBase methods were defined in the wrong
ctrlcmn.cpp file rather than statbmpcmn.cpp. Just move them there to
avoid confusion.
No real changes.
This commit is best viewed with --color-moved git option.
Make wxBitmapBundle compatible with bitmap scale factor > 1, both when
converting the latter to the former and when retrieving bitmaps from the
bundle.
See https://github.com/wxWidgets/wxWidgets/pull/2564
Use the scaled size, different from the default size, when constructing
wxBitmapBundle from an existing wxBitmap to keep the existing code using
scaled bitmaps working.
Add a unit test checking that this now works as expected under the
platforms where scale factor is used.
Bitmaps returned from this function must have the appropriate scale
factor, e.g. 2 in standard high DPI case, in order to be drawn at
correct size in the ports where logical pixels are different from the
physical ones, such as wxOSX and wxGTK3.
Notably, this allows wxGenericStaticBitmap to work correctly in high DPI
in these ports too.
This also allows to undo some of the changes done in 399b0ff9ae (Use
wxBitmapBundle instead of bitmap scale factor in wxGtkImage, 2021-10-16)
to wxGtkImage code and keep using the same code that had been used
before.
This will make it possible to change them later without breaking ABI,
which is probably worth paying the price of a function call (assuming
the compiler could de-virtualize this call and inline it before).
No real changes.
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.
Normally non-toplevel windows must have non-null parents, as creating
them with null parent would fail, but our own wxTabFrame used in AUI is
an example of a window which can have null parent because it's actually
never created at all. This does look like a pretty bad hack, but it's
very unlikely to happen accidentally, so relax the assertion check added
in the previous commit to allow for it.
Using a wrong parent for the window managed by the sizer of the given
window or, alternatively, inserting a window into a wrong sizer, seems
to be a common mistake when creating sizer-based layouts and results in
hard to understand visual problems (as typically the window with the
mismatched parent/sizer just remains stuck at some wrong location).
So try to help detect it sooner and provide more information about the
problem by checking the parent of the window either when it is added to
the sizer -- if we already know which sizer the window is associated
with at that moment -- or when associating the sizer with the window
later.
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.
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 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.
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.
