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.
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
