This function can be used to check if drawing on wxClientDC actually
works. This has to be a run-time, rather than compile-time, check
because in wxGTK3 this depends on the backend being used: wxClientDC
only doesn't work with Wayland, but does work with X11 (and, less
importantly, Win32) backend(s).
Currently the wxWindow parameter of this function is not used but it
could be useful in the future and it will be simpler to allow not
specifying it (by defaulting it to nullptr) than to add it later, so it
seems better to have it.
This makes behaviour more consistent across all platforms, as this flag
is always used in wxGTK and wxOSX, and might avoid some problems in
wxMSW, see #23982.
This corrects a problem introduced in 11ed91af8f (Add missing default
constructor of wxFileDialog in wxMSW, 2023-12-03) as m_data remained
uninitialized when default ctor was used.
See #24113.
wxIntProperty::DoValidation() overloads for wxLongLong_t and wxULongLong_t
parameters are not supported because for these types there are no direct
conversions to wxVariant.
Arguments of such types will be handled by overloads for wxLongLong
and wxULongLong.
This code was already used for Ctrl-C handling, refactor it into a
separate function that can be called from the application now.
This commit is best viewed with --color-moved-ws=ignore-all-space Git
option.
Closes#24124.
Although wxGenericTreeCtrl is not used under MSW by default, it still
doesn't hurt to adjust its metrics when DPI changes there.
Note that this shouldn't be done for the platforms using DIPs.
The icons positioning was broken by 53b4f4ddf2 (Use physical size in
wxImageList, 2023-11-03) because the logical size was calculated
incorrectly in the case when wxImageList was used for the icons and
ended up being 8x8 for 16x16 icons when using 200% scaling, which was
clearly wrong and resulted in the icons not fitting in the space
allocated for them because they actually took 32x32 physical pixels due
to scaling of all bitmaps from wxImageList.
Fix this by correctly taking account of the window DPI scale factor.
This is a bit roundabout because using FromPhys() later just undoes
this, but it allows to keep using the same code when using wxImageList
and wxBitmapBundle for storing bitmaps and so is simpler.
Note that we must only do this when wxImageList was provided by the
user, i.e. with the legacy code, but not when it was created internally
in addition to wxBitmapBundle, as in this case we recreate it on DPI
change using the correct, DPI-adjusted size, already, so restrict this
scaling to the case when we don't have wxBitmapBundle only.
This commit is best viewed ignoring whitespace-only changes.
This parameter was always "true" in the existing calls to this function
and the underlying UseClippingView() didn't support passing "false" to
it anyhow, so it seems simpler and more clear to just remove the
parameter.
It also avoids clang warnings about it being unused.
No real changes.
This fixes warnings about MAC_OS_X_VERSION_11_0 not being defined when
using older SDKs, as 21da0e128d (Change wxRendererNative to use
NSCell-based methods under Mac, 2023-11-12) used a wrong name for the
version constant: since macOS 11 these constants don't use "X" in their
names any longer.
Remove this and add a comment to the place where we define them to
document this not quite obvious naming convention.
Postpone the creation of the QStatusBar fields until the first call to
SetStatusText(). This is to account for any field control added by the
user and also to avoid having to call UpdateFields() multiple times.
wxSTB_ELLIPSIZE_XXX and wxSTB_SHOW_TIPS supports are also implemented now.
The statbar sample is also updated: The OnSize() handler is removed because
it doesn't do much. that is: it is defined to keep the bitmap centered in the
status bar field it occupies if it is resized. but this is already done by the
wxStaticBitmap control, at least under wxMSW, wxGTK3 and wxQt.
This is not necessary and, more importantly, results in a crash if you try
to recreate the status bar (which can be seen in the statbar example)
Also remove leftover QList declaration
This includes a static function to calculate Easter that can be used for
other authorities.
Document the wxDateTimeWorkDays and wxDateTimeHolidayAuthority classes.
Closes#24094.
This allows user codes to simply designate where their controls should
appear in the status bar without the need to handle wxEVT_SIZE
themselves.
They can still handle the event if the default positioning does not meet
their needs, but the new API is simpler and can be implemented for wxQt.
Closes#24092.
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.
We need to use a native clip view for things to behave correctly under
this OS version, otherwise scrollbars can be overdrawn by the window
contents.
Closes#24067.
Closes#24073.
And do nothing in this function if the arguments had been already
initialized, as it will make it more convenient to call from other
places.
No real changes.
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.
The problem was: wxClientDC draws in a QPicture owned by the DC. In the destructor,
QtPictureSetter sets the picture to be used by the associated window and generates
a paint event, then resets the picture when it goes out of scope before the paint handler
has a chance to replay the image. In this commit, this setup is changed so that window
owns the picture instead and is responsible for deleting it when it is actually used.
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.
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.
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.
