Take const pointer in GetConsensusSizeFor(), which only uses this
parameter to get the DPI scale factor, and CreateImageList(), using it
only to pass it on to GetConsensusSizeFor().
No real changes.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
Add another compatibility implicit constructor to allow the existing
code, directly passing XPM data to various functions that used to take
wxBitmap or wxIcon and now taking wxBitmapBundle, to work.
Closes#22566.
It doesn't seem to be useful and wasn't really specified in 2 out of 3
existing calls to this function and was probably wrongly specified in
the remaining one, so just remove it for now, it can always be added
later if we decide what exactly should it do.
Ensure that wxBitmapBundleImplSet and wxBitmapBundleImplRC use the same
logic for actually selecting the bitmap to upscale, and not just for
deciding the size that it must have, too.
No real changes, but this should make impossible for these functions to
diverge once again -- and also make it simpler to reuse the same logic
in any other wxBitmapBundleImpl-derived classes in the future.
Instead of taking an array of scales, call GetNextAvailableScale() to
get them.
This allows centralising the logic for returning the available scales in
a single place, where it will be reused in the upcoming commits.
Extract the logic determining the scale to use in a reusable
DoGetPreferredSize() function to allow reusing it in other places.
There are no real changes here, this commit just moved the existing
code to the new function, but because it also changed it from using
wxSize to double, even git --color-moved doesn't show it as an actual
move.
Ensure that wxBitmapBundleImpl full declaration is available when it is
compiled, at least OpenVMS compiler has trouble with compiling the call
to reset(), which involves using wxBitmapBundleImpl dtor, if it comes
before this class declaration.
Define wxBitmapBundleVariantData without using the standard macros that
only work for wxObject-derived classes, but using more or less what they
expand into.
This will allow using wxBitmapBundle with wxDataViewCustomRenderer
subclasses in the upcoming commit.
Allow creating wxBitmapBitmap from SVG image stored in an application
resource on the platforms where wxHAS_IMAGE_RESOURCES is defined.
On Windows, load the bundle from a resource with RT_RCDATA type and on
MacOS from a file with an extension "svg" placed in the "Resources"
subdirectory of the application bundle.
Closes#22061.
We often need the logical bitmap size when using it in size computations
involving window size, so add a function returning it directly to
wxBitmapBundle, similarly to wxBitmap::GetLogicalSize(), to avoid using
FromPhys() everywhere.
Also rename the existing wxBitmapBundle::GetPreferredSizeFor() to
GetPreferredBitmapSizeFor() to make it more clear that this is similar
to wxBitmap::GetSize() and so returns the size in physical units.
Closes#22056.
This is just a convenient wrapper for GetBitmap() that will be useful in
the classes using wxIcon in their public API to preserve compatibility
after switching to using wxBitmapBundle instead of wxIcon internally.
This new function will allow selecting the bitmap of the most suitable
size and automatically react to DPI scale changes (although this hasn't
been implemented yet) in all controls using image lists.
For now, only wxNotebook in wxMSW has been updated to work with it, the
other classes and ports will be updated to override OnImagesChanged()
instead of SetImageList() later.
Also update the notebook sample to use SetImages() rather than
SetImageList() -- which means that it doesn't show the icons any longer
in non-MSW ports, which haven't been updated yet.
Move the code for determining the size preferred by a bunch of bitmap
bundles from wxToolBar to wxBitmapBundle itself to allow reusing it from
other classes.
No real changes, this is just a refactoring.
This commit is best viewed with --color-moved git option.
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
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.
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.
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).
This first version provides only a generic implementation of
wxBitmapBundle using a collection of bitmaps and only supports using it
in wxToolBar in wxMSW and wxGTK.
More methods of creating wxBitmapBundle will be provided later and more
functions taking wxBitmap will be changed to take wxBitmapBundle later
too and, of course, all the other ports will be updated to use the new
API too.
