The test computed the top-level window's target size by adding a fixed
50px margin to its outer (SetSize/GetSize) dimensions, assuming that
would leave enough room for window decorations plus the 260x300
child. But on platforms with substantial client-side decorations
(e.g. GTK3 under GNOME/Wayland, where title bar + resize margins can
total ~90px vertically), that margin isn't enough, so the child
window ends up clipped below its expected size. Comparing against and
setting the client size instead makes the requested area correct
regardless of how large the actual decoration overhead is.
These tests use several fixtures deriving from each other and running the
same tests, so define the test cases for all of them using a helper macro.
Also merge setUp() and tearDown() into the fixture ctor and dtor.
No real changes.
Assisted-by: Claude Opus 5
Get rid of the CppUnit compatibility macros in the GUI test files not
requiring any special handling: replace the test suite classes with Catch
fixtures, setUp()/tearDown() with the ctor/dtor and CPPUNIT_ASSERT_XXX()
with CHECK().
Tests using wxUIActionSimulator don't use WXUISIM_TEST() any more but
check EnableUITests() at the beginning of the test itself instead.
The pseudo test PseudoTest_Inversed in the wxSlider tests is replaced with
GENERATE() rerunning the tests for both normal and inversed sliders.
No real changes.
Assisted-by: Claude Opus 5
Some DC implementations can normalize the requested font when it is selected
into the DC. Save the font actually returned by the DC after applying the
font changer, and verify that clipping restores that realized font.
After the changes of 55be0ed986 (Stop using GDK functions for parsing
colours names, 2024-12-16) we didn't find non-legacy named colours with
spaces in their names any longer, as we matched the name exactly (except
for the case) but the new colour names don't always use spaces.
Fix this by allowing to use spaces anywhere in the colour name and just
stripping all of them before looking the colour up.
Closes#26782.
Don't mirror coordinates passed to GDI functions in RTL layout as they
already mirror them internally, resulting in incorrect coordinates being
used. As a consequence, wxDC::LogicalToDevice() now always returns
unmirrored coordinates, even in RTL layout, which is consistent with
wxGTK3 and wxQt.
Also fix scaling even in LTR layout by using ::ScaleWindowExtEx().
See #26398.
Previously this was only needed in TransformedWithMatrixAndStdEx() which
verified that conversion actually worked, but not in the non-Ex version
using individual coordinates as it only verified that the conversions
failed, which they also did under Wine.
But now that they should work (and do, under native Windows), we need
the same workaround there as well.
Also make sure that we output the warning message about the workaround
not being needed any longer only once and only if it's really not needed
(if it's used for some values, we still have to keep it, even if it's
not used for the other ones).
Both DeviceToLogical{X,Y}() and DeviceToLogical() taking wxPoint were
virtual, with the latter implemented in terms of the former by default,
which meant that overriding only that function, but not the ones taking
X/Y coordinates individually, could result in inconsistent behaviour,
which is exactly what happened in wxMSW.
Make it impossible for this to happen by only allowing to override the
functions taking wxPoint (or wxSize for "relative" variant) and
reimplementing the functions working with individual components in terms
of the virtual functions.
The same goes for LogicalToDevice() and "Rel" variants.
As an important side effect, this fixes a bug in wxDC::StretchBlit() in
wxMSW when using RTL layout as the code there used LogicalToDevice{X,Y}
functions that didn't return the correct values before this commit.
Update the tests to not test for the wrong behaviour of per-coordinate
translation functions now that they behave correctly. Also remove the
tests checking that per-coordinate translation doesn't work when the
transformation matrix includes a rotational component.
Update the documentation to emphasize that converting both coordinates
at once is preferred.
See #19344, #26266.
Due to rounding errors, this test would fail under wxMSW if the region started
at x=2*n, and would fail under wxQt if it started at x=2*n+1. So relax the check
by using 1 as a position tolerance.
This whitespace was annoying as it was getting automatically removed by
the contributors working with the editors respecting the settings in our
own .editorconfig and so resulting in patches that mixed significant and
whitespace-only changes.
Remove it once again (this has been already done before in 8fbca5cb70
(Remove all trailing spaces, 2019-01-30) but apparently only partially)
to avoid the problem.
Replace most 'neither' words introduced after 2b0ee48ef7
(Fix double negatives used with 'neither', 2023-11-25)
with 'either'.
All changes are to comments only.
Closes#24999.
Add test verifying that the ellipse is drawn in the expected way, even
if this is not really intuitive because it can overflow its bounding
rectangle.
Closes#24620.
The changes of 538eafc78b (Fix bug with wrong GetIndexToUpscale() return
value, 2022-06-03) were wrong but happened to work when there were no
down-scaled versions of the bitmap in the bundle.
But in general, we shouldn't use the previous index, but the index just
before the one with the most appropriate scale, so do this, and extend
the unit test to check for this scenario too -- previously it would fail
due to an assert failure when we tried to upscale a previously
downscaled bitmap.
This shouldn't normally happen, but if it does, e.g. because all the GDI
resources have been exhaused, we still shouldn't crash, so check for
this.
Also add a (disabled by default as it could be potentially dangerous to
run it) test checking that we don't crash in this case.
See #24703.
Smaller bitmap was inserted in a wrong place, resulting in the entries
array not being sorted by bitmap size any longer and completely breaking
the logic of GetBitmap() which relied on it being sorted.
In particular, this meant that we kept recreating smaller version of the
first bitmap in the bundle again and again when the function was called
for the bitmap of the same size, which resulted in unbounded resource
consumption and, eventually, a crash.
Fix this by inserting the bitmap in the right place and add a unit test
checking that the number of GDI objects remains more or less constant
even after creating a lot of bitmaps.
Closes#24703.
The overloads taking a scalar were never defined, even though they had
been declared in the very first version of this code back in 72e7876ba5
(wxMSW update for CW, wxMac updated, 1999-12-03).
Closes#24604.
The size passed to Create() should be interpreted in the same way as the
size passed to CreateWithLogicalSize() and in wxMSW this means that it
should _not_ be scaled.
This makes the size of the bitmap returned by this function overload
consistent with wxDC::GetSize(), so it looks like the right thing to do,
even if it's a backwards-incompatible change.
Closes#24559.
We assumed that bitmaps with the same height also have the same width,
but this is not necessarily true and if it did happen, GetBitmap()
failed it postcondition of returning the bitmap with the requested size.
Fix this by rescaling the closest bitmap to have the correct width even
if it already has the correct height.
Also enhance the bitmap comparator used for sorting to work correctly
with the bitmaps of the same height but different width.
Closes#24434.
GetNextAvailableScale() returned wrong result when the bitmap size was
not exactly divisible by the scale, but this didn't matter for square
bitmaps because multiplying the default size by the not quite correct
scale still rounded to the correct size.
This was not the case for non-square bitmaps, however, as all our
computations use only bitmap height and dividing bitmap width by the
exact scale and multiplying it by the scale computed from the scaled and
unscaled height values could result in a value different from the
initial one, as shown by the newly added unit test, which failed before
this commit.
Fix this by computing the ratio of the bitmap to the base one and then
multiplying this ratio by the bitmap scale.
Closes#24433.
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.
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.
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.
Blake-Madden
Vadim Zeitlin
Scott Talbert
Richard
AliKet
ali kettab
Maarten Bent
AliKet
Lauri Nurmi
Bill Su
Paul Cornett
Tim Eliseo