Add support for overriding GetPreferredUILanguages() return value by
setting the WXLANGUAGE environment variable to a colon-separated list
of desired languages (same as GNU's LANGUAGE variable).
Primarily used for unit tests, but may be more generally useful.
Knowing msgIdLanguage is necessary for correct evaluation of preferred
languages order; without it, it would be possible to load undesirable
translation file.
See 2af36e9560 for details.
This commit partially reverts 94b1a17aeb.
The above commit changed translation lookup logic to differentiate
between msgid and "available" translations (the latter being loaded from
a file or resource). It first attempted to use available translations
and only felt back to msgid language as the last resort.
Unfortunately, doing that broke lookup in cases when the user had msgid
language as not-last preference in their UI languages list, or even when
a similar translation was available. For example:
- msgid=en, user preference [cs,en,fr], only fr.po available: fr would
be used instead of en
- msgid=en_US or en, user preference [en], but en_GB.po available:
British English would be used even for US users
This commit fixes this by restoring the previous behavior where msgid
language was treated as a first-class citizen in lookup, while
preserving the API that allows distinguishing between the two cases.
It also reimplements AddStdCatalog() in a more straightforward way that
doesn't rely on AddAvailableCatalog().
GetBestTranslation() and GetBestAvailableTranslation() are documented to
return an empty string if they find no match, but actually didn't do
that due to the way GetPreferredUILanguage() was implemented to always
fall back to the locale and return it without additional checks.
This used to be possible in 3.0 but was disallowed back in 29bf859fae
(Check if new index is in range before selecting new value in
wxPGProperty::SetChoiceSelection., 2014-11-29). However there doesn't
seem to be any real harm in still allowing to do this, so handle -1 as a
special case here.
Closes#24279.
Closes#24281.
Calling Hostname() when constructing wxIPV4address from an already
resolved IP address is unnecessary and can be slow, so don't do it and
just use the string representation of the IP address as "m_origHostname"
instead.
Closes#23109.
Closes#24269.
The only real change in this commit is the use of wxRound() instead of
truncating cast to int when rescaling icons.
The rest consists of just some cleanup:
- Initialize (mostly) pointer member variables in their declaration.
- Remove wxT() from strings.
- Replace checks for __WXMAC__ with checks for __WXOSX__.
- Replace macros with lambda functions.
- Add "explicit"
- Replace wxString::IsEmpty() with empty().
- Use wxNOT_FOUND instead of -1.
- Use static_cast<> instead of C-style casts.
Closes#24261.
The encoder may chose not to emit a CLEAR code when the alphabet is full
according to the specification, but wxGIFDecoder assumed it always did,
preventing it from reading some valid GIF files (in practice, most often
animated ones).
This commit is best viewed ignoring whitespace-only changes.
Closes#22799.
Closes#24234.
Check that ms_pfnSetThreadDpiAwarenessContext function pointer was
initialized before using it.
This fixes a regression introduced in 9befda5c26 (Only use
AutoSystemDpiAware when displays have different DPI, 2023-12-10).
See #24121, #24196.
Closes#24288.
Just reuse the existing function in IncreaseToStdSizeAndCache() helper
instead of using a separate and, until the parent commit, different, way
of computing the default button size here.
This will hopefully avoid introducing any discrepancies between the size
returned by GetDefaultSize() and the size actually used for the buttons
by default in the future.
See #24283.
Using button size in dialog units doesn't work well in high DPI, as it
gives sizes wildly different from those actually used by Windows itself
for the buttons (e.g. for those in Explorer dialogs still using Win32
API), so switch to using DIPs, just as it was done for determining the
initial size of the buttons when actually creating them in c6d2f6d9fe
(Really fix the standard button size in high DPI under MSW, 2019-10-19)
See #18528.
Closes#24283.
It shouldn't, and now doesn't, use these libraries directly and
shouldn't depend on them to avoid introducing unnecessary requirements
for the applications which use it without XRC.
Use wxXmlResourceHandler functions such as GetNodeContent(),
GetNodeName() and GetNodeAttribute() instead, which are defined in the
core library and so don't create a dependency on wxxrc.
This allows to get the name of the node which is needed for XRC handlers
using specific elements instead of using the object elements with
specific name attribute.
Allow specifying recurse="1" to inherit the attribute, as this is much
nicer than having to specify it for all the children.
Also add support for this to wxPropertyGridPopulator, which is used by
the XRC handler.
It seems that WebKitGTK is now failing to navigate to about: URLs unless
they are about:blank or about:srcdoc, so use about:srcdoc as the
alternate URL to fix the WebView tests.
Ref: 3c3163e71f
This resulted in immediate program termination, at least with wxGTK, if
an event handler called when dispatching pending events during idle time
threw an exception (which, in particular, covers all the exceptions
inside lambdas passed to CallAfter()).
Just catch and handle them as usual, i.e. as we do with the event
handlers called immediately in response to a user action.
