We need to use the bitmap size in logical pixels for NSImage and we
definitely must not multiply the physical size by the scale factor, only
dividing it makes sense -- so just do it, by using GetScaledXXX()
instead of GetXXX() when creating the NSImage to use for wxBitmap.
Surprisingly, this seems to have been broken ever since the addition of
this code in 95aa8e40fd (first part of OSX adaptations, 2021-09-28)
without anybody noticing it until now.
Closes#22019.
Contrary to what the documentation stated, it was possible for the item
to be invalid, so update it to explain this and give an example of a
case in which this happens.
See #19182.
This resulted in an assert when receiving wxEVT_TREE_SEL_CHANGED events
with invalid item when the tree was recreated from wxGenericDirCtrl own
OnSelFilter().
Closes#19182.
The year is now included in the copyright string used in the makefiles
and so they need to be regenerated every time the year changes (which
happens surprisingly frequently).
It would be better to define a single variable with the year number to
avoid having to do this in the future.
Correctly set the font size to the size one bigger or smaller than the
current one instead of just setting it to size 1 in both cases.
Apparently this was broken ever since this code was added back in
4f9297b0ee (wxHTML src code indentation now conforms (more) to wxWin
coding style, 2000-11-05) without anybody noticing.
Closes#22012.
This is simpler and a tad more accurate than dividing by
GetContentScaleFactor().
Also add FromPhys() to MSW-specific code: even if it's not really needed
there (as the conversion is always trivial), it's still better to have
it for consistency.
Provide these functions for consistency with the existing FromDIP() and
ToDIP().
We also can use ceil() (rather than round() used by wxSize operators) in
FromPhys() to ensure that we never truncate contents of a physical
bitmap, which allows to replace the existing wxStaticBitmap code with
just a call to this function.
The physical size returned by wxBitmapBundle::GetPreferredSizeFor() must
be converted to logical pixels when it's used as a wxDC coordinate.
This fixes a regression introduced in 391080e77d (Use wxBitmapBundle for
AUI tab pages bitmaps, 2021-11-13).
This fixes the problem with wrong standard bitmaps size when using high
DPI for the main monitor with wxMSW, as GetScaledSize() used here since
31f2892200 (Avoid bitmap scaling in wxArtProvider::GetBitmapBundle(),
2021-12-17) was not the right function to use there.
Closes#19331.
Now wxMSW also stores the scale factor, even if it doesn't use it in its
GetScaledXXX(), so it doesn't seem useful to have this symbol for
distinguishing the platforms with and without bitmap scale factor
support, when we can just use wxHAS_DPI_INDEPENDENT_PIXELS instead in
the only place where this was used.
And as this symbol was added quite recently, in 2c1f4c002d (Add
wxBitmap::SetScaleFactor(), 2021-10-23), we can hopefully just remove it
without breaking any existing code, if we do it right now.
wxBitmap::GetScaledXXX() functions are useful for obtaining the
coordinates in logical pixels, so they should only divide by the scaling
factor on the platforms where logical pixels are actually different from
the physical ones, i.e. those using DPI-independent pixels.
This ensures that their behaviour under MSW remains unchanged even after
a1e4dca067 (Store scale factor in wxMSW bitmaps too, 2021-12-16), which
is the correct way to avoid breaking wxAUI (and other) drawing.
Using wxHAS_ prefix is more consistent with all the other similar
symbols, using wxHAVE_ was a mistake, that we have to pay for by
preserving the old name now (as it is actually already used in some code
outside of the library).
The fact that it's used also shows that it's better to document this
symbol, even if just to explain that it normally shouldn't be used, as
we can't really hide it anyhow.
This sweeps under the carpet the regression which resulted in bitmaps
returned from wxArtProvider::GetBitmap() not looking the same since
starting to use wxBitmapBundle in AUI, but OTOH it just doesn't seem
possible to both preserve the compatibility and allow actually using
appropriate, not scaled, bitmaps in different resolutions.
The new code is as simple as the old version, follows the official
advice to use GetBitmapBundle() rather than GetBitmap(), and looks good
in high DPI, which should compensate for the behaviour change.
Instead of immediately constructing the bitmap with the requested size,
possibly by downscaling a higher-resolution bitmap, and then potentially
having to upscale it if we actually need a bitmap of a bigger size, just
retrieve the bitmap in the actually needed size from wxArtProvider when
needed.
This makes bitmaps obtained from wxArtProvider::GetBitmapBundle() look
good, rather than fuzzy and ugly, in high DPI if they're actually
available in the appropriate size.
wxAuiToolBar::SetToolBitmapSize() doesn't do anything and never did ever
since it was added back in 1154f91b6a (added wxAuiToolBar, 2008-08-24),
so don't bother calling it, this just makes the sample code confusing as
no effect from passing different sizes to SetToolBitmapSize() can be
seen during run-time.
With scaled bitmaps, the preferred bitmap version might be too big for
the pane.
Perhaps it's the title bar height which is too small, but it seems to
have been hardcoded to 17 pixels since the very first version in
50acee04cd (Initial commit of wxAUI, 2006-06-06), so don't change it.
8dcedf56d7 (Add wxWindow parameter to wxAuiTabArt::SetSizingInfo(),
2021-11-13) added "wnd" argument to SetSizingInfo(), so use it instead
of always using the DPI of the main monitor.
It is more convenient to be able to retrieve the request object (which
is needed at least for authentication) from the event than to have to
store it separately.
Closes https://github.com/wxWidgets/wxWidgets/pull/2644Closes#19360.
wxBLACK was used for some day numbers, and with a dark theme the numbers
are drawn on a nearly black background, making them barely visible.
Instead, use wxBLACK explicitly for week numbers, but get the proper
color for day numbers always (and not just sometimes) with
GetForegroundColour().
Closes https://github.com/wxWidgets/wxWidgets/pull/2643
Calculate the clipping region correctly when repainting a wxStaticBox
containing windows that are its siblings (rather than children) when RTL
layout is used: the old AdjustRectForRtl() implementation didn't mirror
the child coordinates correctly.
See #19086.
Send these events ourselves because MSW itself doesn't generate them for
frozen windows. This makes wxMSW more consistent with the other ports.
Add unit tests to verify that the behaviour is really as expected for
both normal and frozen windows, at least under MSW -- under GTK these
events are not sent at all for the notebook pages.
Closes#19216.
