This notably fixes crash with SVGs using 1 stop gradients.
Relax the check in a test added in #24064 as it doesn't quite pass with
the new version -- this is somewhat suspicious but as it wasn't really
clear where did the original tolerance of 3 come from, it doesn't seem
to be a huge problem to increase it to 4 neither.
Closes#24213.
This function should be used instead of CreateWithDIPSize() in portable
code, the latter is currently often used to do what this function is
doing, but this only works correctly in wxOSX and wxGTK3 but not wxMSW.
We can't rely on file /sys/power/state always existing, so just skip the
test (with a warning) instead of failing it if it does not exist, as is
the case at least under s390x and seemingly other non-desktop platforms.
Closes#24197.
Co-authored-by: Cliff Zhao <qzhao@suse.com>
For some completely mysterious reason we don't get the expected mouse
click events when running under AppVeyor, something might be covering
the window and stealing the clicks for itself there.
As there doesn't seem to be anything to do about it, just skip the test
in this case.
Closes#24082.
This parameter wasn't used for anything as it specified the encoding of
the data contents in memory and not the encoding of the XML file as
might be believed, so it only created unnecessary confusion.
See #24167.
Try making this test more robust as well as it also sporadically fails
on AppVeyor.
Also simplify it a bit, checking for each of the expected events in turn
instead of checking for their total number at the end.
Using "argc" and "argv" for parameter names triggers C4458 with MSVS
2022, warning about hiding class members with the same names.
As we can't rename the latter, rename the parameters to avoid this.
This test doesn't use the native header but somehow still fails on
AppVeyor and locally a very failure can be reproduced if the mouse is
moved while the test runs, so check for this here too.
This includes a static function to calculate Easter that can be used for
other authorities.
Document the wxDateTimeWorkDays and wxDateTimeHolidayAuthority classes.
Closes#24094.
Fix wxBitmapBundle::FromSVG(), which renders incorrectly on GTK and add
wxHAS_PREMULTIPLIED_ALPHA to make the code dealing with alpha more clear
and correct.
See #24097.
The previous ToCDouble() function accepted leading spaces, a starting +
sign, and hex strings. std::from_chars() does not accept spaces or +,
and requires a special flag to convert hex strings, so handle this
manually to preserve the old behaviour of this function.
This is similar to the changes done for ToCULong() in #24022.
Closes#24089.
All previous relevant platform-specific tests have been changed to use this
symbol. Also, samples/image now premultiplies conditionally, correcting a
visual anomaly on wxGTK.
Replace user-specified empty constructors and destructors with the
compiler-generated versions, which has a number of advantages for code
generation, in addition to being more clear.
Closes#22965.
Closes#24058.
Refactor wxImageList and convert it to use physical pixels and
add support for high DPI state images wxTreeCtrl using the new
wxImageList.
See #24000, #24033.
When the original messages language matches the language of the locale
being used, these strings can be used directly and so AddCatalog()
should still return true for them but it didn't do it any more after the
changes of 94b1a17aeb (Add AddAvailableCatalog() and use it in
AddStdCatalog(), 2023-09-30).
See #18227.
Closes#24019.
Closes#24037.
This seems to be the only way to fix using this class, which is
fundamentally incompatible with high DPI support, with bitmaps of
different logical but identical physical sizes.
By using physical size we ensure that the code chopping up the provided
bitmap in multiple images doesn't do it with the bitmap having the same
physical size but a different logical size from all the other bitmaps.
And, conceptually, logical size of the bitmaps in it really shouldn't
matter to the image list as it doesn't have a scaling factor and so
can't do anything useful with the logical size.
Moreover, we can't add wxImageList::SetScaleFactor() neither because
this class is, by design, supposed to be shareable between different
controls which may use different scale factors, so it doesn't make sense
to speak of the scale factor of the image list itself.
This undoes the changes made in the generic implementation back in
c374eefd34 (Fold wxOSX-specific wxImageList into generic version,
2018-10-30) and also eb52e86553 (Take into account scale factor of
images added to wxImageList, 2021-04-03).
Also update a couple of places where wxImageList is still used to use
physical sizes. Unfortunately some others can't be easily fixed, e.g.
global wxFileIconsTable would have to be completely rewritten.
Finally, add a unit test checking that things work as expected now:
previously the size of 24x24 bitmap in the image list containing
(scaled) 32x32 bitmaps would be 21x21 due to sub-bitmap extraction
kicking in.
Closes#23994.
Unlike the traditional C functions, std::from_chars() doesn't skip
leading whitespace and doesn't accept the leading "+" sign, so we need
to skip them explicitly to preserve the behaviour of ToLong() in the
previous wxWidgets versions.
Do use std::from_chars<unsigned long>() in it as otherwise values
greater than LONG_MAX failed to parse.
Handle negative numbers explicitly to still parse them in this function
as well, as needs to be done for compatibility.
Add a test case for the previously failing numbers.
Closes#23957.
When using non-integer scale factor, we need to round the result of the
multiplication by it instead of truncating it for consistency with the
behaviour of wxBitmap::CreateWithDIPSize() and the other places where we
do this, including wxOSX version of this function.
Add a simple unit test checking that this works correctly (it would fail
with wxGTK before).
No real changes, just don't put the test not using raw bitmap access
inside the section guarded by "#if wxHAS_RAW_BITMAP".
This commit is best viewed with Git --color-moved option.
