Use the string parameter as the name of the file containing the image to
resize and the numeric parameter as the scale factor in percents (so
that fractional factors could also be specified using this integer
parameter).
This is more practical than running it a given number of times, which
may result in very long running times for slow functions, such as
wxImage resizing tests using wxIMAGE_QUALITY_HIGH.
Also show the standard deviation in addition to the average and min/max
values.
With overlay scrollbars disabled, it was not possible to move the scrollbar
slider all the way to the end, and there would be some flickering when trying
to do so. Fixed by always setting the preferred size to the virtual size, and
returning the proper value for GtkScrollable policy. GtkScrolledWindow uses
the child's preferred size as the virtual size, so the preferred size must
be set for the scrollbars to be managed correctly. Additionally, there was
some confusion during the initial GTK3 port over the difference between
GtkScrolledWindow policy and GtkScrollable policy, resulting in using the
minimum size rather than the natural size.
See #22093
This reverts commit de10f054c4 and a bunch
of commits improving it done since then:
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
de10f054c4 (Improve calculating wxButton best size under wxMSW, 2021-04-08)
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
75d508b6e6 (Fix regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08)
051418ac00 (Fix recent wxMSW buttons with bitmaps appearance regression, 2021-08-26)
fbc6462375 (Fix a gcc warning introduced by the previous commit, 2021-08-26)
The reason for reverting is that using BCM_GETIDEALSIZE doesn't seem to
have any advantages compared to using our old code, as it doesn't take
the margins into account neither and we still have to add them ourselves
and so it's simpler to just always do it without using this message.
They are deprecated by libtiff in favour of C99 standard types, but
replace them with wxUintNN for now, as those are definitely available on
all platforms, while we support some platforms without C99 stdint.h
(notably ancient MSVC versions).
Do it for consistency with the existing GetBitmap() overload and also
because this can be useful when we need to test for the bitmap bundle
presence before using it.
Also document both the new overload and the original one, which was
mistakenly left undocumented when it was added.
This replaces 4 calls to GetBitmap() with a single one.
Note that we now use SetBitmapPressed() and SetBitmapCurrent(), which
take wxBitmapBundle, instead of deprecated SetBitmapSelected() and
SetBitmapFocus(), which do not.
We also search for the parameter node only once instead of doing it
twice in a row if it was found, so the new code is slightly more
efficient.
Update the remaining ports to take wxBitmapBundle rather than wxBitmap
as well to make their API consistent with the tier 1 ports -- even if
there is no actual support for choosing the resolution-appropriate
bitmap in them yet.
src/unix/mediactrl.cpp failed to compile due to a precision-losing cast
(from 'gpointer' {aka 'void*'} to 'window_id_type' {aka 'unsigned int'}).
Tell pkg-config to use 64-bit configs if building for 64-bit on SunOS.
PKG_CONFIG_PATH is set to /usr/lib/64/pkgconfig in that case.
Documented at:
https://docs.oracle.com/cd/E37838_01/html/E66175/gplhi.htmlCloses#22143.
This fixes compilation after the changes of 148f56085f (Define
NIIF_LARGE_ICON ourselves if it's not defined, 2022-02-19) for the
compilers using headers so old that they don't even define NIIF_USER
which exists since XP SP2 -- which includes MinGW 5.3 used for our
AppVeyor CI builds.
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.
It should actually always be defined when using any of the currently
supported compilers, but define it ourselves just in case it isn't.
At least get rid of #ifdef checking for it in the code.
See #22138.
The code added to this function in ae7fa19ae3 (Improve fallback logic in
wxArtProvider::GetBitmap{,Bundle}(), 2022-01-31) didn't do anything at
all because of forgotten "break" after creating the bundle.
Also tweak this code slightly because it was not optimal: consider a
situation with 3 providers, the first one not having neither the bitmap
nor the bundle with the given ID, the second one having the bundle and
the third one having only the bitmap. With the old logic here (if it
were fixed to actually work), we would return wxBitmapBundleImplArt,
i.e. use wxArtProvider::GetBitmap() that would end up getting the bitmap
from the provider 2 bundle, i.e. do the right thing, but in a rather
indirect way.
With the new version we just return the bundle of the provider 2
directly. And we also avoid calling GetBitmap() more than once, which is
unnecessary as its return value doesn't change anyhow.
The backing bitmap needs to be updated when the window scrolls.
This works well on MSW and GTK2, but GTK3 with X11 still has
artifacts, because GtkScrolledWindow draws onto the client area.
Add more wxNOEXCEPT to hash-related classes to avoid warnings like
.../c++/bits/hashtable_policy.h: In instantiation of ‘std::__detail::_Hashtable_ebo_helper<_Nm, _Tp, true>::_Hashtable_ebo_helper() [with int _Nm = 1; _Tp = wxStringHash]’:
include/wx/clntdata.h:33:22: recursively required from ‘std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::unordered_map() [with _Key = wxString; _Tp = int (*)(void*, void*); _Hash = wxStringHash; _Pred = wxStringEqual; _Alloc = std::allocator<std::pair<const wxString, int (*)(void*, void*)> >]’
include/wx/clntdata.h:33:22: required from here
.../c++/bits/hashtable_policy.h:1112:40: error: noexcept-expression evaluates to ‘false’ because of a call to ‘wxStringHash::wxStringHash()’ [-Werror=noexcept]
1112 | _Hashtable_ebo_helper() noexcept(noexcept(_Tp())) : _Tp() { }
| ^~~~~~~~~~~~~~~
In file included from include/wx/clntdata.h:16,
from include/wx/event.h:17,
from include/wx/evtloop.h:14,
from tests/testprec.h:5,
from tests/allheaders.cpp:410:
include/wx/hashmap.h:568:5: note: but ‘wxStringHash::wxStringHash()’ does not throw; perhaps it should be declared ‘noexcept’
568 | wxStringHash() {}
| ^~~~~~~~~~~~
that started to be given my MinGW x86-64 10.3.9 (although they were not
given by 10.2.1 version of the same compiler).
But adding wxNOEXCEPT here is more consistent with the changes of
7d74df9a03 (Add wxNOEXCEPT to the hash structs operator() declarations,
2020-08-30) and makes sense anyhow.
WM_NCCREATE is not received for dialogs, so use a different message.
There seem to be no other messages that are always and only send on
creation, so use WM_NCCALCSIZE which seems always generated but not too
often.
Use m_activeDPI to determine if the DPI variables have been initialized
or not, instead of adding another variable for this.
Closes#22133.
Don't always return success from this function, NanoSVG just skips
everything until the start of the XML prologue and doesn't return an
error even if it doesn't find it at all, so check that it could parse at
least something to avoid returning a "valid" bundle not containing
anything at all.
Add a unit test checking that we actually can't create an SVG from a
.bmp file (which is something that "worked" before).
High DPI support didn't work for wxMDIParentFrame (and everything
inside it) because it was only enabled when InheritAttributes() from
wxNonOwnedWindow was called and this was only done in wxTopLevelWindow
but not in this class.
Fix this by removing the need to call InheritAttributes() at all and
just initializing m_perMonitorDPIaware when the window is created
automatically, to ensure that it can't be forgotten.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Closes#22116.
The new name, recently introduced in 94716fd801 (Add
wxBitmap::CreateWithLogicalSize(), 2022-01-22), was perhaps more clear,
but also misleading and confusing because the postcondition
CreateWithLogicalSize(size, 2).GetLogicalSize() == size
was not satisfied under MSW, so rename it once again, and hopefully
finally, because the new name is consistent with GetDIPSize() returning
the same size.
Also try to improve the documentation a bit more.
Unlike under Mac (see previous commit), this never worked correctly in
wxMSW at all, only SetScaleFactor() could be used to change the scale
factor of the bitmaps there.
Fix this and make CreateWithLogicalSize(..., scale) result in
GetScaleFactor() returning the same scale for the resulting bitmap, as
expected, under MSW too.
Also add a unit test verifying that this holds.
