Although it's the same color the control already had, overriding it
can have unexpected consequences, such as overriding the text selection
colors with GTK3. Fixes invisible wxSearchCtrl selection with GTK3.
It is possible for CGDisplayModeCopyPixelEncoding to return NULL, e.g.
during a switch between the built-in screen and an external monitor on a
Macbook. Check the return value to prevent a crash.
Closes#18015.
Define GDK_TOUCHPAD_GESTURE_MASK ourselves if GTK+ headers don't define
it and don't use it during run-time if GTK+ version is less than 3.18,
in which it was added.
Miscellaneous fixes for time zones and DST handling in wxDateTime.
This still leaves 2 big problems:
1. We have no support for using the correct time zone offset at the
given date and always use the current time zone offset, which may,
and often is, wrong.
2. Our code for converting to/from broken down representation doesn't
handle DST at all, so support for DST is non-existent for the dates
before 1970-01-01 or after 2038-01-01 (i.e. roughly outside of the
32 bit time_t range).
See #10445 and the other tickets linked from there.
wxDateTime is still broken with respect to DST outside of the standard
time_t range, but make a special exception for the dates near Unix epoch
when using BST as not accounting for DST for them broke the unit tests
when run in this time zone.
Note that constructing the dates outside of the standard range is broken
too, so if this problem is ever fully fixed in GetTm(), it would need to
be fixed in Set() too, where the DST is not taken into account neither.
The problems in unit tests were due to using the (correctly behaving)
standard mktime() for 1970-01-01 but then using our (broken) GetTm() for
accessing them and could, in principle, be also worked around by not
using mktime() for this date, but it seems better to keep correct
behaviour at least for it, even if it's still broken for many earlier
dates.
See #15370.
Converting to another time zone and dealing with DST is completely
useless here, ticks values are always in UTC, so we can just use UTC
values from the beginning.
This ensures that dates are printed out correctly if comparing them
fails.
It might be better to avoid always including this header, but this is
the simplest solution.
Current algorithm used to calculate the bounds of the boxes in the source
image to which the pixels in the target (rescaled) image are mapped to, has
flaws which cause a non-uniform distribution of the boxes in the source
image. And these miscalculations may result in the visible distortions
of the colours in the rescaled image.
New algorithm assures uniform distribution of the boxes in the source image
and thanks to the integer arithmetic is faster than currently used
and not prone to the problems with floating point representation.
Closes#18012.
Include 3rd party libs in wx-config output even when using the system,
and not the built-in, versions of them for static monolithic build.
See https://github.com/wxWidgets/wxWidgets/pull/621
Take into account that from 1968-10-27 and until 1971-10-31 UK used BST
time instead of GMT, i.e. that DST was permanently on.
This fixes unit test failures in BST time zone for the dates around the
Unix epoch of 1970-01-01.
See #15370.
Make "Exit" menu item really exit the sample again instead of just
closing the main window, but possibly leaving the gestures testing
window still open and thus not really exiting the program.
Also avoid creating more than one gesture window, use the existing one
if we had already opened it.
No real changes, as this doesn't affect this test, but use the new
IsLocal() method instead of comparing the time zone offset with the time
zone, which doesn't work correctly for BST.
wxDateTime timezone-related methods always use the current timezone
offset, while other methods, using CRT, use correct value for the given
date, which may be different.
This discrepancy accounted for test failures in Europe/Minsk time zone
as Belarus has switched from UTC+2 to UTC+3 since 1999 date used in the
test.
It is impossible to really fix the problem easily, so just skip the test
in this case and also mention this bug in the documentation.
See #15370.
Show the loop variable when doing checks inside a loop to make it more
obvious for which test case the failures occur.
Also use CHECK(), instead of REQUIRE(), to which CPPUNIT_ASSERT_EQUAL
expands, to continue with the other loop iterations after failure.
No real changes, just show the variable values if any checks fail and
also continue running the test for the other data points even if one of
them fails.
Don't rely on time zone offset to check whether it is local as this
doesn't, and can't, work for the local time zone in Great Britain which
uses the same offset as UTC, but does use DST, unlike the latter.
Add a unit test (albeit disabled by default) checking that the code that
previously didn't work correctly in BST does work now (run the tests
using "TZ=Europe/London ./test wxDateTime-BST-bugs" under Unix to test).
Closes#14317, #17220.
See #10445.
Replace exactly the same code occurring in both wxDateTime::GetTm() and
Format() with a single version in a new wxTryGetTm() function.
No real changes yet, except for removing of some useless asserts.
The class needs to use WXDLLIMPEXP_ADV in order for its (default,
compiler-generated) dtor to be generated inside the library, otherwise
this doesn't happen and linking code using this class inside a shared
library fails with errors due to the dtor being undefined.
This is a tiny optimization (or maybe not so tiny on platforms other
than Linux where time() might not as fast as just reading a memory
location), but mostly is done to work around faketime bug[*] which
prevented it from being used for testing programs using wxWidgets, such
as our own unit tests because time() was called from wxLogTrace() in
wxCSConv::DoCreate() called when creating global conversion objects
during the library initialization.
Arguably, it might be better to avoid calling wxLogTrace() during the
initialization, but this can't be done as simply and this change might
have a small performance benefit too.
[*] https://github.com/wolfcw/libfaketime/issues/132
Subtracting a huge negative offset from the current position could
overflow it, which was correctly detected as undefined behaviour by
UBSAN.
Credit to OSS-Fuzz: this solves its issue 4388.
Although the object being created _will_ be of type wxAppConsole, it
doesn't have this type yet, as wxAppConsole ctor hadn't yet run, and so
the static cast is invalid and detected as such by UBSAN in g++ 6.3.
Currently lzma and jbig libraries are checked only for builtin
libtiff. When the system libtiff is built with lzma and jbig
support and when the `--with-libtiff=sys` flag is specified
the configure script will fail, due to missing linking with
lzma and jbig.
Fixed this by moving lzma and jbig checks from libtiff-builin check
above all libtiff checks. Also added lzma and jbig libs to
EXTRALIBS_GUI.
See https://github.com/wxWidgets/wxWidgets/pull/619
