It was incorrectly called wxAppConsole::YieldFor() but the function was
moved from wxAppConsole to wxEventLoopBase back in dde19c2180 (second
part of #10320: move wxApp event handling functions to wxEventLoopBase
(in particular move Yield() functions); add backward compatible
redirections to wxApp; update docs; remove global lists wxPendingEvents
and wxPendingEventsLocker, 2009-02-15).
Closes#24095.
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.
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.
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.
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.
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.
Add a note explaining that when creating a button sizer with this
method, one of the buttons will be usually made the default.
See #23992.
Closes#24001.
This method is needed to determine the sorted state of a control derived
from wxItemContainer without knowing the actual derived control class.
Closes#23971.
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.
Also make it clear that wxCHOICE_{HEIGHT,WIDTH} constants are not really
used for anything.
Closes#23949.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Mark it as deprecated in the documentation without deprecating it
formally in the code, as it seems to be used in some existing code and
there is no urgency to remove it, but using it in new code still doesn't
make any sense.
Closes#23945.
The new function only returns true if the catalog could be really
loaded and not if it is considered not to be needed because the message
ID language (which is typically "en-US") happens to be present in the
preferred UI languages list (which seems to always include "en-US" in at
least Western European MSW).
This allows to distinguish, albeit in a rather awkward (but
backwards-compatible) way between having a translation for the given
language and not needed such translation.
It is still not clear if it is really correct to return "en-US" from the
list of preferred languages even if the user has never intentionally
configured the OS to indicate that English is acceptable, but at least
now we can work around this issue and use AddAvailableCatalog() in
AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo
if the versioned wxstd-x.y.mo file is really found instead of never
doing it, as was the case until now (see #23886).
Also add GetBestAvailableTranslation() helper which seems more useful
than the existing GetBestTranslation() one and is similarly related to
it.
See #18227.
This allows to suppress some or all GTK diagnostics even for the
programs not calling GTKSuppressDiagnostics() nor even
GTKAllowDiagnosticsControl() themselves.
There is no corresponding wxTranslations::AddCatalog() overload any
longer, so don't mention it and don't document it neither, but do say
that the charset parameter is simply unused.
Store two possible action codes in std::pair instead of packing them
into one int value with bitmasks. This reduces level of indirection
in accessing keyboard actions and make the code more maintainable.
Document previously undocumented macOS methods
enabling/disabling automatic character substitutions.
This should have been part of 90e1769 (Add API to control
OS X wxTextCtrl’s smart behavior, 2016-10-16).
Closes#23889.
This has the advantage of returning libraries in their load order, which
is more useful than the unspecified order that was used before.
It also means that this function now has a chance of working under other
systems such as FreeBSD, which also provides dl_iterate_phdr().
Add support for specifying multiple animations to allow automatically
showing a higher resolution version when using high DPI, just as it was
already possible with the bitmaps.
See #23817.
Allow specifying multiple animation versions, for different resolutions,
when setting the animation to use via wxAnimationBundle class which is a
much simpler version of wxBitmapBundle used elsewhere.
This is not implemented for the native GTK version yet.
Update the sample, even though the difference in it is not really
noticeable as the "high DPI" throbber is just a scaled up version of the
existing standard DPI animation produced using gifsicle.
