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.
Fix regression originally introduced in f5548e399e (Fix problem with
dragged icon remaining on screen under MSW 10, 2020-01-11) and changed,
but not fixed, in b6c593af45 (Fix regression in MSW DoDragDrop() return
code, 2020-05-03) by restoring the original code from before these
changes except for moving the cleanup logic in a local object dtor.
Closes#19274.
It didn't do anything since wxBitmapBundle-related changes, as could be
seen by toggling the bitmap size in the toolbar sample -- the bitmaps
size didn't actually change.
Make it work again by only using the best bitmap size if it's greater
than the currently set bitmap size, but not shrinking the bitmaps to it
if it's smaller. This doesn't seem especially useful, but this is how
the code behaved with single bitmaps before and there doesn't seem to be
any good reason to change this.
At least document that calling SetToolBitmapSize() is unnecessary and
normally shouldn't be done.
Fix wxGenericColourButton after recent bitmap changes and, more
generally, always skip wxDPIChangedEvent and document that this should
be done.
See https://github.com/wxWidgets/wxWidgets/pull/2637
Only the bitmap of the normal state was updated, not of the other (focused, hover, disabled, etc) states.
This became obvious after ee93f4cae8, but already happened before that for the disabled state.
Invalidate the bitmapButton using wxNullBitmap, so all states will be updated when setting the bitmap.
So base classes will process the event too.
This is need for (at least) wxGenericColourButton It has its own handler,
but also needs to handle the DPI event in wxButtonImageData.
To enable fullscreen support with WKWebView private API which was
available since macOS 10.11 was used. Beginning with macOS 12.1 this
resulted in unpredictable layout issues inside the webview.
This reimplementation using java script and message handlers does only
use public API. This also makes the fullscreen message more controlable
as the webview does no longer put the containing window in fullscreen
mode without application code intervention. That also unifies macOS with
the way Edge sends this event in MSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/2629
Using a const char* and a wxString in the two branches of the ternary
operator resulted in compile-time errors since the result type of the
conditional expression was ambiguous, so add explicit conversions to fix
it.
Closes https://github.com/wxWidgets/wxWidgets/pull/2634
See #19355.
In the case where native wxNotificationMessage is not available and
wxGenericNotificationMessage is used as wxNotificationMessage, m_impl was
being initialized twice. This happens already in the constructor for
wxGenericNotificationMessage. This was causing a leak of a
wxGenericNotificationMessageImpl and even more problematic, a leak of a
wxFrame, which caused some oddities. So, just remove the initialization from
wxNotificationMessage.
Closes https://github.com/wxWidgets/wxWidgets/pull/2631
Documentation of the other overloads was removed in 6a442d2 and there is
nothing special about the wxCoord variant in wxSVGFileDC, so remove it so
all the overloads are consistently documented in just wxDC.
Closes https://github.com/wxWidgets/wxWidgets/pull/2627
When a COM interface is held by wxCOMPtr, one should not call
Interface->Release(), as it decreases the interface's reference
count without wxCOMPtr owning the interface being aware of that.
When then wxCOMPtr calls Interface->Release() in its destructor
the reference count is erroneously decreased again, which is bound
to result in bad things happening.
If one needs to release an interface held by wxCOMPtr immediately,
wxCOMPtr::reset() should be used instead.
These Release() calls should have been removed in 938506b1f7 (Use
wxCOMPtr throughout the wxWebViewIE Find code., 2013-05-18), which
introduced the use of wxCOMPtr, but were forgotten there.
Closes https://github.com/wxWidgets/wxWidgets/pull/2626Closes#15207.
