Instead of getting the bitmap of the default size and then possibly
rescaling it, get the icon of the correct size directly from the bitmap
bundle, which could yield better results (and at worst would do the same
thing as before, but with less code).
See #22138.
This allows to retrieve the native CPU architecture name regardless of
the current process CPU architecture.
Common examples for CPU architecture differences are the following:
- Win32 process in x64 Windows (WoW)
- Win32 or x64 process on ARM64 Windows (WoW64)
- x86_64 process on ARM64 macOS (Rosetta 2)
Closes#22036.
Define __STDC_WANT_LIB_EXT1__ as early as possible to ensure that it's
defined before string.h is included by some other header without it.
Closes#19334.
Such thread names can be shown by some debuggers, and depending on
the OS and compiler versions used, they can be visible in process
lists and crash dumps.
Co-authored-by: PB <PBforDev@gmail.com>
This static function parses a subset of the language tags described in
BCP 47 (see https://www.rfc-editor.org/rfc/bcp/bcp47.txt).
Use the tag, as specified by this function, rather than the locale
identifiers components under MSW, where this should allow us to use even
locales that can't be described using just language-script-region.
We don't use empty wxLocaleIdent as default user locale and it doesn't
make much sense to do it, as the default locale is already accessible
via wxUILocale::GetDefault().
No real changes, just move this class declaration as it seems more
logical to have it in the same header with wxUILocale which is the only
place where it's used.
This commit is best viewed with --color-moved git option.
Unlike MSW and macOS, creating wxUILocale for e.g. "en" doesn't
necessarily succeed under Linux even if "en_US" is available, so try to
find a working language+region combination if just language doesn't
work.
This requires access to the languages database, so add a private
wxGetLanguageInfos() to avoid having to depend on wxLocale just for
this.
This finally seems better than always creating some kind of impl object,
even if the locale isn't supported at all and makes all ports behave
consistently, as previously CreateForLocale() only returned NULL in
wxOSX implementation if the locale was unrecognized, but now all ports
do this (at least when locale_t and related functions are available
under Unix).
Also stop returning bool from Use(), as this resulted in initializing
wxLocale with any non-default language to fail under Mac: just ignore
the error here, as we always did it until now, because there is nothing
we can do about it anyhow.
This required changing CompareStrings() to be a method of wxUILocale
object, rather than just as a static function, as we must only allocate
the locale_t object once, and not during each to this function, as this
could make it unusably slow when using it as a comparison function when
sorting a large list of strings.
This is also more efficient under Mac, where we can similarly allocate
NSLocale only once and even marginally more efficient under MSW, where
we don't have to construct the locale string during each call. And,
under all platforms, it also simplifies code by separating this function
implementation from the initialization of wxUILocaleImpl.
Also document that case-insensitive comparison is not available under
Unix and adjust the tests accordingly.
Creating such objects (without using them for the UI) is supported under
all platforms, so allow doing it.
Note that this is only supported under Unix systems when locale_t and
related functionality is available, but this should be the case just
about everywhere by now.
Add a test (or, rather, replace an existing test which was disabled by
default) checking that we can now get locale information about any
locale, not necessarily the currently used one.
Add Use() virtual function which can be used if the newly created
wxUILocaleImpl object should be used as the default UI locale.
Currently Use() is always called after creating a new wxUILocaleImpl, so
adding a separate function just seems to complicate matters needlessly,
but this won't be the case any more soon, when wxUILocaleImpl could be
created for using them for other purposes than making them the default.
No real changes yet.
This function can be used for all GetInfo() items, so using it is
simpler than the code in the Unix version of wxLocale::GetInfo() which
uses either it or localeconv(), and there should be no real drawbacks to
using it nowadays as it should be available everywhere.
No real changes yet.
This is tidier than using #ifdefs in the same common file and also
ensures that initializing wxLocale affects wxUILocale too, which will be
important for compatibility when the code elsewhere is modified to use
wxUILocale::GetInfo() instead of wxLocale::GetInfo() in the upcoming
commits.
This commit is best viewed with --color-moved git option.
Using c_str() for arguments to wxString::Printf(), Format() and
wxLogXXX() is useless since wx 2.9 days, so simply remove them.
No real changes, this is just a (long due) cleanup.
the Move handler apparently misses some resize events, so move the
gst_player_video_overlay_video_renderer_set_render_rectangle call
to expose_event_callback.
This is kept as a separate commit because it would be more efficient
to keep it in Move once we can catch that initial size change, so
this commit can get reverted then.
gstreamer is known to crash on xvimagesink if the main window is
wayland-native and DISPLAY is set: try to make it not load.
Also do the same for ximagesink just in case.
gstreamer creates a new connection to the wayland display by default, and
gst_video_overlay_set_window_handle() only works if both the parent surface
(part of the gtk window) and the gstreamer surface are on the same display,
so we need to tell gstreamer about our wl_display when it asks
This breaks existing unit tests using wxUIActionSimulator that do things
similar to
wxUIActionSimulator sim;
sim.Char('o', wxMOD_CMD);
wxTEST_DIALOG(wxYield(), ... expected "Open" dialog ...);
because the expected dialog would be shown from inside Char(), unlike
with the wxMSW implementation and GTK until the changes of 59ad9f46e6
(Make wxUIActionSimulator works more reliably on GTK/X11, 2020-05-07).
To still make sure there is a delay after the event, sleep, if
necessary, before simulating the next event: this is still enough for wx
test suite to pass, but allows the code like above to work with both
wxMSW and wxGTK.
In fact, doing it like this makes the code simpler and removes the need
to distinguish between press and release events or maintaining the
number of currently simulated-as-depressed buttons or keys, so it also
simplifies things as a side effect.
Also add some comments and rename Default_Delay constant to a more
accurately named MIN_DELAY_BETWEEN_EVENTS.
Closes https://github.com/wxWidgets/wxWidgets/pull/2318
Don't return unconditionally before another return. Somehow gcc doesn't
warn about it, but other compilers (and static analyzer tools)
definitely do.
No real changes.
wxGetKeyStateGTK() is intended to be used only with non-X11 GTK backends.
wxGetKeyStateX11() should still be used on GTK3 w/ X11 as the GTK
variant does not provide all key states.
