Ensure that the tests are run instead of being skipped.
Also merge "Set environment variables" and "Before install" steps into a
single "Set up" step to avoid adding yet another separate step for
locale installation.
At least under Linux it's common not to have all the supported locales
installed, so check that a locale is available to avoid test failures if
it isn't.
We still rely on all the locales we use being available under MSW and
macOS, as this should be always the case.
This function can now be implemented relatively straightforwardly
(although it does require an extra check under Mac), so add it, as it
can be generally useful and we're also going to need it for our own
tests in the upcoming commit.
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.
Extract it from existing MSW-only code and make it available in all
ports so that we could use it as a fallback in wxUILocale if everything
else fails.
No real changes yet.
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.
Use the recommended name-based NLS API rather than legacy functions
taking LCID.
Preserve compatibility with Windows XP by keeping the old code for now,
but it will be removed after 3.2.0.
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 convenient, as it allows using a simple string such as "en" as
an argument to the functions taking wxLocaleIdent and rely on implicit
conversion, whereas previously explicitly writing either wxString("en")
or wxLocaleIdent("en") would be necessary.
Harmonize Mac and MSW versions by using case-sensitive comparison in
both of them by default, but allowing to use a flag to use
case-insensitive comparison instead.
Still run them on GitHub runners, but do it using the same steps as for
our own builds, as there should be no reason to have any difference
in the build steps independently of where exactly they run.
Also remove checks for matrix.skip_testing from the Unix CI workflow as
they are not needed there any more because the tests are always run.
This commit is best viewed with --color-moved git option.
Even "-qq" is insufficient to suppress the annoying, and useless for
non-interactive use, "Reading database ... NN%" output, so add the
option suppressing it to all apt commands.
Also use "-y" as a single "-q" is not enough to suppress the prompts.
Do it in the command executed by sudo, as sudo doesn't propagate the
environment variable values by default (--preserve-env option could be
used to do it, but it's simpler to avoid it).
For some reason 32 bit libgl1 is not pulled in as win32 dependency any
more, resulting in errors when running the test using Direct2D.
Fix this by installing the package explicitly.
This library doesn't really exist any more and is preserved only for
compatibility, there is no need to have dependencies on it, just depend
on "core" instead.
This fixes sporadic errors when building DLL configurations as the html
library build could have been still in progress when xrc library,
requiring it, was linked.
Reverting the commits broke indentation, which resulted in
-Wmisleading-indentation from (recent) gcc, so fix it by indenting the
restored "if" properly.
See #13130.
Use "new" (available since 10.5, for most part) values of the enum
instead of the deprecated ones, which are still defined, but might not
be in the future.
No real changes.
Call CTFontCreateUIFontForLanguage() only once for every
CTFontUIFontType value and cache the results, as it is expensive to do
it every time wxSystemSettings::GetFont() is called.
Closes#19191.
This commit is best viewed ignoring whitespace-only changes.
Revert both 53eff92ea7 (Call AdjustForBitmapMargins() only once in
wxAnyButton, 2021-04-24), which was completely wrong and was due to not
reading the code attentively enough, and the subsequent 5d508b6e6 (Fix
regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08) which
fixed the problem introduced by the first commit partly, but not
completely.
Closes#13130.
For some reason, we used "vc_x64_lib" as the output directory for the
libraries, but "vc_mswu_x64" as the output directory for the samples.
Place the arch suffix, i.e. "_x64" part, always after the compiler
prefix (possibly including version), for consistency with both the
library output directories and with MSBuild project files, as
build/msw/wx_setup.props uses $(wxCompilerPrefix)$(wxArchSuffix)_...
as wxIntRootDir value.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
Use the colour directly in implementation class method and ensure that
we pass it the correct colour from wxWindow::SetForegroundColour()
itself.
This simplifies the logic a bit and avoids clang warning about unused
"col" parameter in wxWidgetCocoaImpl::SetForegroundColour().
Closes https://github.com/wxWidgets/wxWidgets/pull/2491
Note that this support is still incomplete, notably we don't have
*_vc17.sln files yet and the official build scripts haven't been updated
to build MSVS 2022 binaries neither.
There is nothing that can be done about the warnings saying that using
transform matrix is not supported for the given DC kind and it's not
going to change any time soon (i.e. implementing support for transform
matrix for wxSVGFileDC is not planned), but in the meanwhile it results
in a lot of useless output in the CI logs when running the tests, making
it difficult to find real problems in the test.
This commit is best viewed ignoring whitespace-only changes.
Include all extra libraries we need (except for OpenGL ones, as there is
still a separate library for it, even in monolithic build) in wx-config
--libs output for static monolithic build as the application (may) need
all of them, as all the libraries are part of the single monolithic one
in this case.
It seems that we had an attempt to fix this as far back as in 5719eab2bf
(Fix missing 3rd party builtin libs for static monolithic builds.,
2006-09-17), but it was insufficient as it didn't take the dependencies
of the other GUI libraries (e.g. "media") into account.
Closes#19175.
Make the lines colour less bright to avoid having too high contrast
between the lines and the background, notably in dark mode under macOS.
See #19116.
