Make wxDC and wxGraphicsContext DPI aware, i.e. add {From,To}DIP() to
them too and make the values returned from Get{DPI,PPI}() consistent
with wxWindow.
Also improve CMake build: add support for finding Cairo when not using
GTK, fix a warning when creating the inplace-config, and mark some
variables as advanced.
See #22346.
This is slightly more economical, both at run-time and, maybe more
importantly, at compile-time than using wxSharedPtr that we don't really
need here, simple intrusive ref counting smart pointer is enough.
This is not really necessary and breaks encapsulation of this private
method. It is enough to provide just a way to copy the data from another
object as this is all that the derived classes really need.
Add wxSharedClientDataContainer class storing ref-counted client data
and use it instead of plain wxClientDataContainer in wxGridCellAttr,
wxGridCellEditor and wxGridCellRenderer classes.
This allows to keep the same client data associated with many grid cells
without having to make many copies of it.
Don't hardcode inset sizes any longer.
This improves various issues under macOS 12, see #22134 and #22135 (but
doesn't fully fix the former problem yet).
Closes#22351.
It looks like wxGetTranslation() was not actually called for these strings
earlier, so do call it.
The context fulfills also the same purpose as TRANSLATORS: comments --
removing comments as redundant.
This reverts most of the changes from ee2b02614e (Add GetDPIScaleFactor to wxDC
and wxGraphicsContext, 2022-04-16).
This is not supposed to be used to scale pixels, FromDIP will be added instead.
Temporary use scale=1 in the drawing sample until FromDIP is added.
Previously it interpreted its argument as being in DIPs, which was
perhaps more convenient, but inconsistent with most of the other
functions and broke the general rule that FromDIP() should be used with
all hard-coded sizes.
Update the sample to use FromDIP() when calling it now, improve the
documentation and fix a bug in AdjustToolBitmapSize() which resulted in
not increasing the bitmap size when moving toolbar sample using "large"
toolbar size from a standard DPI display to a high DPI one: the old code
considered that the new size was the same as the old one and returned
before comparing it with m_requestedBitmapSize, which resulted in the
bitmaps not changing size at all instead of doubling their size as they
were expected to.
wxRibbonButtonBar::GetItemRect() and wxRibbonToolBar::GetActiveTool()
are helpful for positioning other windows (e.g. popup ones) that should
be aligned to tools and buttons in the ribbon bar.
Closes#22329.
Restore the old behaviour of wxLocale, which is supposed to use the
default locale and not the preferred language, which may not be the same
(see #22281).
Also apply the following fixes and improvements to wxUILocale:
- Add new GetSystemLocale() method.
- Change the MSW implementation to use the default locale instead of the
preferred UI language for Windows versions below Windows 10.
- Change the Unix implementation to respect LANGUAGE environment
variable and use it for determining the preferred UI languages.
- Use wxUILocale in wxTranslations to determine the preferred UI
languages.
- Use wxUILocale during initialization of internat sample.
Closes#22281.
Closes#22318.
MSWDefWindowProc(WM_PAINT, ...) in OnPaint causes performance issues on
large screens so only use it when an actual custom background colour is
set.
Closes#22308.
Closes#22320.
Make this function virtual in the base class so that it could be
overridden to do the right thing in wxAuiNotebook, instead of just
always returning NULL as before and add a unit test checking that it
works.
Explain that wxBookCtrlBase::m_pages may not be used in the derived
classes, but that in this case they must override all the methods using
it.
Finally, "soft-deprecate" wxAuiNotebook::GetPageIndex(), which is
identical to FindPage() now.
This fixes infinite recursion when handling wxEVT_HELP in wxAuiNotebook
in wxUniv too, see #22309.
Closes#15932.
It can be used to scale coordinates and sizes to make them DPI aware.
In the common headers, use wxDisplay::GetStdPPIValue() as default DPI value,
so the correct values are used on Windows (96) and macOS (72).
In wxMemoryDC use m_contentScaleFactor as the DPIScaleFactor, see e4c2298e5e
(Use window scale factor for all MSW wxDCs associated with windows, 2022-04-04).
Fix declaration of 'o' hides previous local declaration warnings.
Change two wxCONSTRUCTOR_5 definitions using wxBitmapBundle instead of
wxBitmap (this does not give build errors).
wxGenericCalendarCtrl is missing all XTI implementations, so just use
RTTI. And fix building the xti sample.
Note the shared build still fails due to WXDLLIMPEXP related issues.
Closes#22300.
Closes#22301.
Consider that all still supported/existing platforms provide these
declarations, if they provide these functions at all (and they probably
all do, so we almost certainly could remove all the test for them, but
keep them for now).
Note that we still test for broken declarations as this might still be
useful on HP-UX 11 systems, where this problem was reported "only" 8
years ago.
By not using AC_CHECK_FUNCS() we avoid the problem when using it with
snprintf() when cross-compiling with the latest MinGW API headers, see
https://sourceforge.net/p/mingw-w64/bugs/935/ for more details.
This commit is best viewed ignoring whitespace-only changes.
This ctor was previously present only in wxMSW, make it available in all
ports to allow the same code to compile everywhere.
In most of them wxDC argument is simply ignored, but in wxGTK and wxOSX
it is used to assign the appropriate scale factor for the new bitmap.
Enable previously wxMSW-only unit test checking for this.
Previously this ctor was only available in wxMSW and wxOSX, which was
especially strange as the equivalent Create() overload, taking wxDC, was
already available in all ports.
No real changes, just don't redeclare the classes already forward
declared in wx/bitmap.h in the files included (only) from it and don't
include redundant headers.
Also forward declare wxCursor and wxPixelDataBase in wx/bitmap.h itself
for consistency, as many (even though not all) headers use them.
Do not forward declare wxControl in wx/{msw,osx}/bitmap.h, however,
there is no reason to do it in this header.
Both implementations don't add any additional features to the base
functions and therefore are not needed. wxPropertyGrid and other wxPG
controls are children of wxPropertyGridManager and DoFreeze/DoThaw calls
are forwarded directly to them in wxWindowBase::Freeze()/Thaw().
Closes#22269.
