This restores the previous behaviour inadvertently changed by bfeae1922d
(Minor optimizations in GetMultiLineTextExtent(), 2020-06-10) and makes
it official by documenting it and adding tests checking for it.
It wasn't completely obviously if this was intentional or accidental
before, but at least wxStaticText itself relied on the old behaviour,
and chances are that so did some code outside the library, so make this
part of the API now.
See #18825.
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.
Using "x" as separator between the components created confusion with
hexadecimal notation, resulting in confusing messages like "0x17==0x0"
that seemed to describe comparison of 2 numbers and not 2 wxSize
objects.
Using "*" is also more consistent with wxRect output format.
There is no need to pass by GetTextExtent() now that we already make
sure width/height are non-null in this function, so just construct the
MeasuringGuard slightly earlier and call CallGetTextExtent() directly.
No real changes.
Don't output "ok" for all files when running update-setup-h, this was
not very informative and possibly misleading. Only show "ok" for the
actually updated files and "unchanged" otherwise.
Those are more appropriate than the previously used CAPTIONTEXT and
INACTIVECAPTIONTEXT under Linux and don't change anything under Mac,
where they map to the same colours anyhow.
Extra style bits used while initializing wxPropertyGridManager are
not saved and therefore cannot be returned by GetExtraStyle(). We need
to save them in a standard way to make them accessible for this function.
See #18813.
Abort configure run with an error if a 3rd party library doesn't seem to
be present, when it's supposed to be used during the build, as this is
better than postponing the error until make runs into it much later and
also allows us to give a hopefully helpful message telling people that
they might be missing the relevant submodules.
Also add --disable-tests configure option to allow skipping building
tests entirely. In particular, this allows to avoid cloning any
submodules at all when using system libraries on a Unix system.
Closes https://github.com/wxWidgets/wxWidgets/pull/1954
Official build/packaging scripts fixes: specify TARGET_CPU explicitly
for 32 bit builds (and also document it); don't bother modifying
wxwidgets.props as it now works out of the box.
See https://github.com/wxWidgets/wxWidgets/pull/1960
This is more appropriate than wxSYS_COLOUR_INACTIVECAPTIONTEXT which
just happened to be the same as wxSYS_COLOUR_GRAYTEXT under Mac, but
this is not true elsewhere.
This fixes creating wrong bitmaps for system colours with alpha and
allows to use the correct wxSYS_COLOUR_INACTIVECAPTIONTEXT constant
in wxAuiGenericTabArt instead of a wrong but, due to the loss of alpha,
better looking wxSYS_COLOUR_INACTIVECAPTION which was used before.
Using wxSystemSettings::GetColour() in wxSysColourChangedEvent handler
in wxGTK could return the old colour value, before the change, because
the callback for notify::gtk-theme-name signal defined in wxTLW, which
generates wxSysColourChangedEvent, could be invoked before the callback
for the same signal in wxSystemSettings, which invalidated its cache.
Fix this by registering the former using g_signal_connect_after() and
thus ensuring that wxSystemSettings callback runs before it, and the
cache is cleared before wxSysColourChangedEvent handlers can use it.
Closes#18818.
Use system colours instead of hard-coding white.
This is still not ideal because ideally the same wxSYS_COLOUR_XXX
constants should be usable under all platforms, but better than just
using completely wrong colours when using dark mode under Mac.
Move code initializing colours and colour-dependent bitmaps from ctor to
UpdateColoursFromSystem(), which means that now this is done not only
once, when creating the object, but also later if the system colours
change (e.g. due to turning on or off the dark mode).
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.
GDK_SELECTION_CLIPBOARD is the prefered way of referencing
the GdkAtom for the clipboard, and using it provides a clearer
distinction between the primary clipboard and the normal clipboard.
using a pasteboard peeker tool lead to a crash when the drag pasteboard was accessed after our session has long finished. Make sure the writer is working correctly event after the data object is not valid anymore
For the sake of consistency with another ports only unsigned
hexadecimal numbers should be supported. To do so we need
to prevent:
- Setting a range including negative values if base == 16.
- Setting base != 10 if current range includes negative values.
Closes#18805.
Hexadecimal numbers are always unsigned in the native wxSpinCtrl
implementation under wxMSW so for the sake of consistency we need
to prevent:
- Setting a range including negative values if base == 16.
- Setting base != 10 if current range includes negative values.
See #18805.
