In order to avoid drawing anomalies with wxGCDC on HiDPI displays, the shift
must be half a logical unit rather than half a device unit, and it needs to be
applied regardless of the scale factor. An exception is made for the zero-width
(one logical pixel) pen, which uses a half logical pixel shift. This reverts
d43b2862c3 (Fix drawing rectangle with width 1 pen using wxGCDC and HiDPI, 2023-04-25)
See #23485
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.
Use wxOSX_USE_NSCELL_RENDERER to allow setting it to 0 to revert to the
old code.
Note that the new version is Objective C++, so the old .cpp file had to
be renamed to have .mm extension.
Closes#24053.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
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.
It was unexpected and annoying that using keyboard in wxGenericTreeCtrl
could find the item completely different from the expected one because
it could open a currently collapsed branch and find an item deep under
it instead of the item visible on the screen, so change the code to only
find the visible items when typing their label in the control.
This is similar but not totally identical to the existing
GetNextVisible() as it doesn't require the initial item itself to be
visible (notably, it could be the hidden virtual root).
It is also more efficient than the old GetNextVisible() implementation
calling GetNext() in the loop until finding a visible item, as it avoids
looking inside collapsed items in the first place.
Just check if the scale factor has changed when getting a "configure"
event for a TLW as we're guaranteed to get one when the scale factor
does change, according to GTK documentation (and it does seem to work).
Closes#19290.
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.
Don't mention thoroughly outdated desktop environments such as Gnome 1
and don't make this X-specific as the situation is not at all better
with Wayland.
Do mention IsAvailable().
See #18081.
Closes#24028.
Although this is not ideal, it may still happen and sometimes can even
give acceptable results, e.g. using (16, 32) and (24) bitmap bundles
can actuall works nicely enough at x2 scaling if 16px bitmaps are
upscaled by the factor of 3.
To make this work, request the explicit physical bitmap size and
override its scale factor to ensure the resulting bitmap has the correct
logical size.
The new function does the same thing as the Mac-specific
OSXMakeDPIFromScaleFactor() that it replaces but is also defined in
wxGTK where it will be used too.
This allows to dump a bitmap to a disk file in order to examine it
outside of the debugger when debugging.
Note that at least MSVC and gdb are not smart enough to allow calling
wxBitmap::SaveFile() directly.
Take const pointer in GetConsensusSizeFor(), which only uses this
parameter to get the DPI scale factor, and CreateImageList(), using it
only to pass it on to GetConsensusSizeFor().
No real changes.
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.
No real changes, just refactor the code to reset all drag-related
variables in a single function instead of doing it manually in several
places.
As this function also resets m_clickTab, which could previosuly remain a
dangling pointer, change the code to get its value before calling it.
Ensure that all of them are initialized, including m_clickTab, which
didn't seem to be always initialized before.
No real changes (as m_clickTab doesn't seem to have been used before it
was initialized).
Passing an invalid index to this function results in a crash, so ensure
this doesn't happen -- at the very least this would have turned the
crash fixed by the parent commit into "just" an assert failure.
Fix using outdated click position in wxAuiTabCtrl mouse handlers, which
resulted in an invalid wxEVT_AUINOTEBOOK_DRAG_MOTION event being
generated and a crash while handling it.
Ensure that we reset m_clickPt when resetting m_isDragging too so that
we don't decide that we're dragging if the mouse enters the window with
the left button already pressed after a previous drag.
Closes#24027.
It made sense to emphasize its use when this was the recommended way to
set up MSVS projects, but now the simplest (and hence recommended) way
to do it is using wxwidgets.props file, so make the manual setup
instructions more generic as they're most likely to be used with
non-MSVC compilers.
We had instructions for building wxWidgets with MinGW but not for
building the applications using wxWidgets, so add them too now in the
hope that it will be helpful to people who struggle to find the options
to use for building -- or at the very least to the people who have to
answer the questions about this, as they could now just point to these
instructions.
