- Fix handling of delta encoding that change vertical position
- Fix handling of end-of-line encodings that are given mid-line
- Removed unnecessary computation for linepos
Add regression tests for the bitmaps using RLE and loading which
previously didn't work correctly.
Closes https://github.com/wxWidgets/wxWidgets/pull/2590Closes#19318.
This should make the explicit casts such as added in 8db55e9653
(Explicitly cast enum to int inside CHECK(), 2019-09-30) and the
previous commit unnecessary, result in better messages if a test fails
and allow the other tests to still run after the failing tests, as we
use CHECK() instead of CPPUNIT_ASSERT(), which maps to REQUIRE(), now.
Do the same thing for the just added tests as was already done in
8db55e9653 (Explicitly cast enum to int inside CHECK(), 2019-09-30) for
the other ones.
This is a rather drastic solution, but warnings given when
cross-compiling this file with MinGW are annoying, really fixing them is
not completely trivial and risks conflicting with the upstream changes
later, and we don't need the TIFFPrintDirectory() function defined in
this file anyhow, so just exclude it from the build.
Closes https://github.com/wxWidgets/wxWidgets/pull/2587
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>
Refactor the existing code to allow using an already existing
accelerator instead of always extracting it from wxMenuItem.
This is not used yet, but will be in the next commit.
This simple struct combines both the accelerator code and flags and is
simpler to work with than two different variables.
It will also allow reusing this functionality in the upcoming changes
more easily.
No real changes yet.
This is simpler and results in much better results when scaling the
bitmaps up currently (in fact, there is probably a bug either in
wxBitmap to/from wxImage conversion in wxGTK or wxImage::Scale() itself,
as the results are too bad to be correct when using the mask).
This commit is best viewed ignoring whitespace-only changes.
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.
Let wxToolBar itself do it if necessary to create the disabled tool
button, there is no need to create the disabled bitmap ourselves as the
toolbar will do it at least as well and possibly better, if the native
control has some better way of greying out the toolbar buttons.
This is required to be able to implement an object delegating actual
images display to another one, as e.g. wx{List,Tree}book do with
wx{List,Tree}Ctrl.
Using the default-constructed wxBitmapBundle object makes more sense
(and might be marginally more efficient) for the default value of a
wxBitmapBundle parameter.
No real changes.
wxIMPLEMENT_DYNAMIC/ABSTRACT_CLASS* is documented to be used with a
semicolon, though it is not mandatory.
Not touching headers yet, to avoid -pedantic warnings in user code.
See https://github.com/wxWidgets/wxWidgets/pull/2584
`AC_HELP_STRING` and `AC_CANONICAL_SYSTEM` are deprecated past autoconf
2.70+. A quick runthrough with `autoupdate` brings `wxwin.m4` in line
with this.
Closes https://github.com/wxWidgets/wxWidgets/pull/2585
Change from old `m_statusItem` API to new `[m_statusItem button]` API
because the former is now deprecated and the new one does automatic
image scaling.
Closes https://github.com/wxWidgets/wxWidgets/pull/2573
It may not be obvious how to build the tests, so add a section
explaining this to the existing file containing the instructions about
writing the tests and add a README to the tests directory itself to
increase chances that this file will be found -- hopefully anybody
interested in the tests will look at the README in the directory
containing them.
Use GetBitmapBundle(), via a helper GetPageBitmapBundle() function which
is going to be useful elsewhere too, rather than GetImageList(), as the
latter only works if the images were set using SetImageList(), while the
new version does the right thing both in this case and when the images
were set using SetImages().
Return the image list set via {Set,Assign}ImageList() if SetImages()
hadn't been called to make this function return the correct image list
in any case, both when using the old wxImageList API and the new one
using wxBitmapBundle.
This commit is best viewed ignoring whitespace-only changes.
It should be possible to call this function on wxWithImages objects
contained in derived classes too.
This commit is best viewed with --color-moved git option.
Still no real changes, but this makes the code simpler and more robust
and prepares the way for adding wxListCtrl methods taking vectors of
bitmap bundles.
