Add CMake-based build system.
Merge the original branch without any changes except for resolving the
conflict due to moving the contents of .travis.yml to a separate file by
propagating the changes done in this file since then to the new script
and rerunning ./build/update-setup-h and ./build/cmake/update_files.py
to update the file lists changed in the meanwhile.
Closes https://github.com/wxWidgets/wxWidgets/pull/330
This extends the changes done 01cd702ee3
to another test case and so makes as much sense as the other commit.
It's still not clear what's really going on here as, somehow, this test
passed under AppVeyor before, which shouldn't have been happening if the
explanation in that commit message was correct. And it also doesn't
explain why did it suddenly fail after a completely unrelated change,
see https://ci.appveyor.com/project/wxWidgets/wxwidgets/build/2502/job/l24gc2j0j7h7huxl
It seems that MinGW-w32 started distributing GDI+ headers since this
version and MinGW-w64 might have supported them for even longer, but
it's difficult to test for the MinGW distribution used in this header,
as it is included before wx/msw/gccpriv.h which defines
__MINGW32_TOOLCHAIN__ and __MINGW64_TOOLCHAIN__ symbols and changing
this is tricky due to relative order of defining UNICODE and
wxUSE_UNICODE and including MinGW headers, which can only be included
once UNICODE is set properly.
But while the fully correct solution is difficult, just checking for the
compiler version should solve the problem in 99.99% of the cases in
practice as there should be vanishingly few people using MinGW-w64 with
gcc < 4.8 currently, so this simple solution is good enough.
Closes#17973.
Fix a copy-and-pasto in the header and also mention that wxURLDataObject
derives from wxDataObjectComposite, and not wxTextDataObject, in wxGTK
too.
Also add a note about the exact base class being an implementation
detail.
Closes https://github.com/wxWidgets/wxWidgets/pull/624
This will allow projects to use static wxWidgets libraries and zlib
(either directly or indirectly, as can heppen e.g. via Boost.IOStreams)
at the same time without link conflicts.
See #15314.
A recent change fixing monolithic build broke the normal build when
using built-in libraries under Unix as -lwxzlib now came before -lwxpng
and so zlib symbols used by libpng were not found (in fact, they could
still be found in the system library which is usually available under
Unix, so the problem wasn't seen immediately, but it was still there).
See https://github.com/wxWidgets/wxWidgets/pull/621
We do use wxStaticBox colour for painting its background (as can be seen
with test code from #18018, for example) under MSW, so don't say that we
don't.
Also, the reasons for not doing it mentioned in the comment are either
obsolete (wxGTK3 does do it too, unlike wxGTK2) or lost (the link to the
mailing list message doesn't work any longer and can't be recovered).
Closes#17913.
Returning true/false from wxCairoFontData::Apply() to indicate whether
Pango should or not be used was not very clear, so prefer to test for
the font explicitly in the code calling Apply() and make Apply() itself
void, consistently with the method with the same name in the other
classes.
Also avoid calling it at all from GetTextExtent() when using Pango, this
is completely unnecessary as the text colour doesn't have any bearing on
its extents.
Also use static_cast and const_cast as appropriate instead of C-style
casts.
This corrects f75387850b and just uses the
newly added assign() overload taking the buffer directly: as the buffer
already knows its length, this makes it unnecessary to pass it
separately.
Closes#16490.
This is more convenient and less error prone than using the existing
ctor taking char pointer and length as the buffer contains both.
Also add the corresponding assign() overload for consistency.
See #16490.
Show non-printable characters when comparing strings more clearly if the
comparison fails, this is notably useful for strings containing NULs as
they were previously completely lost.
wx-config didn't report -lwxscintilla for `wx-config --libs stc` in static
monolithic build.
Since stc is a part of monolithic lib, -lwxscintilla will be reported
for `wx-config --libs` now as well.
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.
