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.
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.
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
