X11 defines Xf86Launch[0-9a-f], which are then also defined as
GDK_KEY_Launch[0-9A-F].
Unfortunately, keys which are not mapped are just plain ignored and the
application is then not able to receive these keyboard events at all.
The original PR https://github.com/wxWidgets/wxWidgets/pull/157 mapped
only LaunchA/B to WXK_LAUNCH_APP1/2, this patch adds the whole range of
keys and keeps LAUNCH_A/B as aliases for WXK_LAUNCH_APP1/2
Define CopyFromIcon() directly in wxBitmapBase for the non-MSW ports, as
it was implemented exactly in the same way in all ports using this class
anyhow.
This means this function is not virtual any longer, but this shouldn't
be a problem as it was never supposed to be overridden in application
code and this couldn't be done with wxMSW, where it never was virtual in
the first place, anyhow.
No real changes, just a simplification.
We must call SetInitialSize() in Create() in order to take the size
argument passed to ctor/Create() into account -- it was completely
ignored previously.
But calling SetBitmap() must not change the initial size, as it can also
be done later, so just change the current size there instead (which is
consistent with wxMSW version and original behaviour, so keep it like
this, even though it's not totally clear if all ports do it).
Remove the now unused wxGenericStaticBitmap::GetBitmapSize().
Instead of defining them, slightly differently, in all the non-MSW
ports, define them once in wxStaticBitmapBase.
No real changes, this is just a simplification.
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.
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.
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.
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.
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.
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.
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.
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.
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).
