Add wxRendererNative::GetExpanderSize(), implement it using the
appropriate theme element and use it instead of hardcoding the expander
size to 3 character widths.
Closes https://github.com/wxWidgets/wxWidgets/pull/1431Closes#18449.
In wxGTK using negative coordinates with HitTest() happens to work and
it's useful to test that it does, as this test will run when the control
is scrolled even under Travis CI, unlike the test with positive
coordinates which doesn't work under Xvfb there and was disabled in the
previous commit.
Also document that passing negative coordinates to this function only
works in wxGTK.
For some reason, wxTextCtrl scrolls much too far when running under
Xvfb, so the test assumption that it still has some visible characters
after calling SetInsertionPointEnd() fails and must be disabled in this
environment.
For some reason, the height of a text line is 15px there and not 18px as
locally, so 400px high image still fit on the second page in the last
test. Make it higher to ensure that it doesn't.
The Debug configuration is the default, but it is not filled in in cmake-gui.
Do this, and set Debug and Release as available options.
See https://trac.wxwidgets.org/ticket/18438
Fix warning: Command line warning D9025 : overriding '/W3' with '/W4'
Remove /W3, either via a regex or via new policy CMP0092 (CMake 3.15).
The policy has to be set before calling project(), otherwise the
CMAKE_<LANG>_FLAGS are already initialized.
See https://trac.wxwidgets.org/ticket/18438
Adobe have announced the official EOL for flash is 2020 so we're
now at the point where support for flash just isn't interesting
any more.
It doesn't make sense to support it for the upcoming 3.2.x release
series, and the sample .swf files are lacking source code.
Closes https://github.com/wxWidgets/wxWidgets/pull/1427Closes#15886.
Set the "printer" PPI explicitly for wxMemoryDC used in the test to
ensure that it's the same in all ports: currently wxGTK3 stands out
because it uses 72 DPI unlike wxMSW and wxGTK2, which use 96.
There seems to be something wrong with the vertical offset returned by
gtk_entry_get_layout_offsets() in GTK 3, so just don't use it at all, as
we don't need it anyhow.
For some reason, the control does lose focus there, even if it doesn't
happen when using a normal X11 server.
Just disable the test in this environment.
This will allow disabling some tests which fail when running only under
Xvfb.
The new function doesn't work automatically because there doesn't seem
to be any way to distinguish it from the usual server, so it just checks
whether wxUSE_XVFB=1 is set in the environment, as is done by Travis CI
build script.
Older versions of the server default to 8bpp, which breaks some of our
tests (admittedly, this shouldn't be the case, but it's probably better
to test in the same configuration as is used by 99.99% of the users
rather than adjusting or disabling tests in the remaining 0.01%).
The tests are known to fail for the other tested ports, so don't enable
them for now.
Also, using a special environment variable allows to detect when the
test is being run under Xvfb, which behaves differently from the normal
X server in some cases.
The fix for visual artefacts when resizing columns with comctl32.dll v6
introduced them when using v5 of the DLL, so apply it only conditionally
now.
See #18032, #18441.
LVS_EX_DOUBLEBUFFER doesn't seem to work correctly with comctl32.dll v5,
and results in artefacts when the control is resized, so don't enable it
for it.
Closes#18441.
This parameter is not modified by wxColourDialog (this might have been
the case, or at least the plan, some long time ago) and so has no reason
not to be "const".
Just add the qualifier to ctor and Create() in all ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/1421Closes#12511.
We need to wait until wxDataViewCtrl is realized for its columns widths
to be actually set, as calling gtk_tree_view_column_set_fixed_width()
just queues a resize that will take effect later, as documented in the
previous commit.
It may be surprising that calling GetWidth() after SetWidth(100) still
returns 0, so at least document this behaviour (fixing it doesn't seem
to be easily possible).
Reading native font info strings in v0 format, used by the previous
wxWidgets versions, resulted in creation of fonts with 0 point size,
which resulted in suboptimal user experience when such a font was used
to display text.
Fix this by initializing point size to the value corresponding to the
font height in pixels using the default DPI, just as we already do when
creating wxNativeFontInfo from a LOGFONT.
No real changes, just refactor the code previously present in both
wxNativeFontInfo ctor and SetPixelSize() in a single function and reuse
it in both places.
This not only cuts down on its size, but will make it simpler to skip
this test in the environments where web access is unavailable in the
upcoming commit.
