Such thread names can be shown by some debuggers, and depending on
the OS and compiler versions used, they can be visible in process
lists and crash dumps.
Co-authored-by: PB <PBforDev@gmail.com>
No real changes, but don't complicate the constants definitions
needlessly just to avoid changing the numeric value of WXK_LAUNCH_APP
constants as nobody should rely on them anyhow.
Not doing it simplifies things and allows to condense the mapping from
GDK keys to wx ones.
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.
