Change wxGetInstallPrefix() to return a string instead of const
wxChar*. The latter was incorrectly obtained from a temporary string if
WXPREFIX was set. While it's possible to fix in a backward compatible
manner without changing the function's signature, it's not worth the
effort for something pretty obscure and used mostly internally.
wxUSE_UNICODE_UTF8 is not default anywhere since a long time.
Also mention that wxUSE_UNICODE==0 build is already deprecated and will
be dropped in the future.
Also remove the part about updating version.bkl from the pre-release
section, as this is done after the release.
As this leaves only 2 items in the numbered list of the things to do,
remove the list entirely.
It has become unnecessary after the previous commit, as now the generic
GetContentScaleFactor() can be used instead of it on all platforms, so
revert the changes of f6cc8ff52c (Add GetOpenGLScaleFactor() to abstract
OpenGL coordinates scaling, 2020-07-10).
See https://github.com/wxWidgets/wxWidgets/pull/1944
See #17391.
Make Get[MultiLine]TextExtent() behave consistently for empty strings on
all platforms, in particular return (0, 0) size for them from
GetTextExtent() in wxGTK, which is an incompatible change but is needed
to make it behave in the same way as the others.
See https://github.com/wxWidgets/wxWidgets/pull/1970
This seems more logical and is compatible with wxDC in wxMSW and wxGTK2,
as well as other kinds of DC, e.g. wxPostScriptDC.
It also looks like the current behaviour was unintentional as it
happened only because wxGCDCImpl::DoGetTextExtent() always passed all
non-null parameters to wxGraphicsContext::GetTextExtent(), even if it
didn't need the values for all of them, and thus bypassed the special
case for the empty string which was already present in the latter
function.
Fix this, making DoGetTextExtent() more efficient as a side effect (we
now avoid unnecessary calls to pango_layout_iter_get_baseline() in the
most common case), and also add another test for empty string to
wxGraphicsContext itself, for non-GTK case.
Also document this behaviour and add a test checking for it.
The fix for OpenGL coordinates when using high DPI in b134589cbb (Fix
OpenGL samples when using HiDPI displays, 2019-08-06) did fix it for GTK
3 and macOS, but broke it for MSW and other platforms not using pixel
scaling, as window coordinates are the same as OpenGL ones there, while
GetContentScaleFactor() can still return values > 1 even on these
platforms.
Provide new GetOpenGLScaleFactor() function abstracting this platform
difference and use it in all OpenGL samples to make them work correctly
in high DPI under all platforms.
Closes https://github.com/wxWidgets/wxWidgets/pull/1944Closes#17391.
Since OS X 10.12 it has been named macOS so it makes sense
to reference it in documentation as such, even when it
sometimes refers to older versions which were called (Mac) OS X.
Now that desktop Macs using ARM exist, we should default to building the
normal, macOS-targeting, port on them and not wxiOS any more.
This is a backwards incompatible change, but it shouldn't affect many
people, so should hopefully be fine.
GetPaths/GetFilenames() must be used instead when more than one file
could be selected: document this and assert if the wrong functions are
called.
Closes https://github.com/wxWidgets/wxWidgets/pull/1883
Mention that RecalcSizes() shouldn't be called any more, after the
changes of 622deec262 (Replace wxSizer::RecalcSizes() with
RepositionChildren(), 2015-10-11), and that RepositionChildren()
replacing it shouldn't be directly called neither.
