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.
Unlike the traditional C functions, std::from_chars() doesn't skip
leading whitespace and doesn't accept the leading "+" sign, so we need
to skip them explicitly to preserve the behaviour of ToLong() in the
previous wxWidgets versions.
Do use std::from_chars<unsigned long>() in it as otherwise values
greater than LONG_MAX failed to parse.
Handle negative numbers explicitly to still parse them in this function
as well, as needs to be done for compatibility.
Add a test case for the previously failing numbers.
Closes#23957.
When using non-integer scale factor, we need to round the result of the
multiplication by it instead of truncating it for consistency with the
behaviour of wxBitmap::CreateWithDIPSize() and the other places where we
do this, including wxOSX version of this function.
Add a simple unit test checking that this works correctly (it would fail
with wxGTK before).
No real changes, just don't put the test not using raw bitmap access
inside the section guarded by "#if wxHAS_RAW_BITMAP".
This commit is best viewed with Git --color-moved option.
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.
Not sure if it really helps, but try to wait for the events in these
tests as well if only for consistency with what was done in 3d07de66b1
(Add a wait to wxGrid UI unit tests too, 2023-10-03).
Qt uses QString::localeAwareCompare() for comparison and this is what their
documentation says: "On other Unix-like systems without ICU, the comparison
falls back to the system library's strcoll()". Under MSW, Qt uses CompareStringEx()
IOW, Qt always compares strings by locale-specific sorting criteria and BTW
this is what wxGTK was like before this commit 625ed74 (Make sorting of wxListBox,
wxChoice and wxComboBox identical to the MSW sorting)
The wxListCtrl would assert with this message: '../src/qt/listctrl.cpp(452):
assert "col < columnCount()" failed in SetItem(): Invalid col'
Because under wxQt: no columns means no items, and no items means
no selection can be made at all.
Wait for a bit before checking for the expected event as a single
wxYield() call might apparently not be enough under load, as this test
sporadically fails in AppVeyor CI builds even though it passes locally.
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 test sporadically fails under AppVeyor, perhaps due to a hard-coded
sleep in it which may somehow misbehave there -- try changing it not to
rely on this sleep.
This has a nice side effect of making the test run faster, too.
Use older and so hopefully compatible with all MinGW versions
PathMatchSpec() instead as we don't use any of the newer function flags
and it seems to behave identically with the default flag.
Recent commit corrected handling of "*.*", which previously didn't match
the files without extensions, but still left handling of patterns such
as "x*.*" broken, because they are also supposed to match all files
starting with "x" under Windows, whether they have an extension or not.
Fix this by using PathMatchSpecEx() shell function which should handle
this correctly and update the unit test to check for this case as well.
Using "*.*" as a wildcard is supposed to match everything under MSW, but
ever since the changes of 4daceaacbd (Check that files returned from
wxDir::FindXXX() match the filter., 2013-04-08, see #3432) it only
matched the files with extension because we double-checked the match
returned by the native MSW function (which does handle "*.*" correctly)
using our own wxString::Matches() which doesn't handle it specially.
Fix this by skipping the call to Matches() when "*.*" is used: we know
that this wildcard matches everything, so rechecking the match would be
useless at best, even if it were not actively harmful. And also skip
this call for "*" because calling Matches("*") always succeeds anyhow.
This also fixes the same bug in wxFind{First,Next}File() and any other
code using them such as wx{File,Dir}Ctrl.
Closes#23905.
Make the wxString(std::string_view) constructor explicit.
Otherwise, when comparing a std::string_view with a const char *, the
cast to wxString will be considered as a candidate for the comparison,
ultimately causing an "ambiguous overload for 'operator=='" error.
For example, this sample only builds if the constructor is explicit:
#include <wx/string.h>
#include <string_view>
int main() {
std::string_view view = "abc";
const char *str = "abc";
return view == str;
}
However, making the constructor explicit will break assignment:
std::string_view view = "abc";
wxString s;
s = view; // Error: no match for "operator="
That we can fix by implementing operator=(std::string_view)
That, however, introduces another ambiguity:
std::string str = "abc";
wxString s;
s = str; // Ambiguous between s = wxString(str)
and s = std::string_view(str)
That we can fix by implementing operator=(std::string)
Finally, note that some rather obscure ambiguities remain, such as:
wxString s;
s = {"abc", 2}; // Ambiguous between s = wxString("abc", 2)
and s = std::string_view("abc", 2)
Avoiding them is not simple (https://cplusplus.github.io/LWG/issue2946)
and doesn't add much value.
Closes#23834.
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.
