Allow using vectors of bitmap bundles instead of wxImageList in the most
common controls using the latter: wxBookCtrl-derived classes (including
wxNotebook), wxListCtrl and wxTreeCtrl.
Also update more parts of wxAUI to use wxBitmapBundle.
See https://github.com/wxWidgets/wxWidgets/pull/2574
These accelerators are not shown in wxMenuItem label, but still will
work.
Implement support for them in all major ports and XRC.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
Previously, wxMediaCtrl would always automatically resize itself
whenever a video was loaded. If a wide video was loaded, this could
cause wxMediaCtrl to take up the entire space, hiding any other
widget(s) that might exist within the same sizer. Allow avoiding this
behavior by adding a new style, wxMC_NO_AUTORESIZE, which disables this
automatic resize behavior and allows handling the resize behavior
manually.
Take wxBitmapBundle instead of just wxBitmap in various public functions
and select the bitmap appropriate for the current DPI scaling when we
need to use it.
Note that this removes wxAuiScaleBitmap() which used custom scaling
logic that might be better than the generic approach used by
wxBitmapBundle, and so could result in a temporary regression in the
icons appearance in high DPI, but they will hopefully be replaced with
SVG versions soon, so that this shouldn't matter.
We need a valid window pointer to use the correct DPI scaling factor for
anything sizing-related, but this function didn't have any, so add one
to it now.
Unfortunately we need to have a default value for the new parameter for
backwards-compatibility purposes, but document that this parameter is
not really optional and must always be specified.
Also add wxWindow parameter to wxAuiTabContainer::SetRect(), which needs
it in order to pass it to this function.
Currently this window is only used for converting logical pixels to
physical ones, but it will also be used for selecting the correct bitmap
size in the upcoming commits.
Mention that wxTE_RICH2 should be used instead of wxTE_RICH and that it
can now be turned out automatically if the initial text is too long.
See #19303.
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>
Add a paragraph for keys where GetUnicodeKey and GetKeyCode both return
WXK_NONE, that GetRawKeyCode is platform specific, and that such keys
generate no wxEVT_CHAR event.
Add "since 3.1.0" for the constants introduced back in abd46cb99a (Add
support for multimedia keys to wxMSW and wxGTK, 2016-01-08) and also for
the new constants added in the previous commit.
Also document that WXK_LAUNCH_n keys are only generated by wxGTK.
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
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.
These functions allow avoiding using wxImageList explicitly in a couple
of places.
No real changes, this just prepares for adding new API not based on
wxImageList.
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 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.
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.
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.
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().
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.
