Calling this function from OnInternalIdle() is not always enough, so
call it before processing each and every event to ensure that CEF can
really do whatever it needs to be doing internally.
This doesn't seem to noticeably slow down the program and solves weird
problems, like embedded text boxes (e.g. search zones on the web sites)
not getting focus on click.
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.
This function is always called, even if the application prevents the
wxEVT_IDLE handler from being called, either by forgetting to Skip() the
event in its own handler of this message or by changing the global idle
event generation mode to wxIDLE_PROCESS_SPECIFIED.
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.
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.
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.
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).
Add these functions for consistency with SetStateImages() and to avoid
using GetStateImageList() in the treectrl sample, which can now use
GetStateImageCount() instead.
Unlike the existing SetStateImageList() function, the new one allows to
provide the high-resolution versions of the state images too.
Update the treectrl sample to use the new API.
Closes#23993.
Doing this must reset any existing image list, as some controls (notably
wxTreeCtrl) use the image list internally and keeping using it would
still show the old images even after resetting them.
Since the changes of 4d76a87015 (Make wxSearchCtrl inherit from
wxTextEntry in all ports, 2023-07-09, see #23697) GetEditHWND() returned
null for wxSearchCtrl which was considered to be correct because all
wxTextEntry functions were supposed to be forwarded to wxSearchTextCtrl
anyhow.
This wasn't really correct, however, as GetEditHWND() was also called
from SetHint(), resulting in an assert failure and falling back on
generic hint implementation which, while mostly working, suffers from
some problems that the native implementation doesn't have.
So make this function return the actual HWND used by the associated text
entry to fix this and allow SetHint() to work as before and also
forestall any problems due to not having the right HWND in the future.
See #23983.
Closes#23975.
This is currently implemented for single line control only. But unfortunately the
wxEVT_TEXT_MAXLEN event is only emitted when the Qt version used is 5.12 or higher.
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
