Running it using Python 2 seems to result in a problem with not matching
an exclusion line with non-ASCII character, which works fine with Python
3 locally.
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.
This file is used with "-x misc/suppressions/codespell-lines" codespell
option and allows to ignore entire lines, instead of ignoring words that
only occur once or twice and shouldn't be ignored globally because they
could well be misspelt elsewhere.
The remaining words in codespell.ignore occur too many times (as
parameter names in various places) to be ignored in this way.
This is not really a script, so having it under misc/scripts was not
very logical.
Also rename it to explicitly indicate that this file contains the words
to ignore as the next commit will also add another file ignoring the
whole lines.
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.
In a native up-down control hexadecimal numbers are always unsigned (see
UDM_SETBASE message documentation) so we need to prevent:
- Setting a range including negative values if base == 16.
- Setting base != 10 if current range includes negative values.
See #18805.
GTK needs to be told the data on the clipboard can be stored
before the store is attempted.
Also, document that the clipboard behavior on GTK is very
dependent on the configuration of the user's machine.
Closes#10515
No real changes, just move m_textLines and m_heightLine from wxTipWindow
to wxTipWindowView as they were only used by the latter and so can just
as well be its members.
Also use this as an opportunity to replace wxArrayString with wxVector.
It doesn't seem to make sense to provide wxFrame-based implementation of
wxTipWindow, if anything we should use similar code to implement
wxPopupTransientWindow itself on the platforms not providing it.
So simplify wxTipWindow code by leaving only a single implementation,
using wxPopupTransientWindow. This should have arguably been done back
in 8962e1d938 (wxTipWindow is now a wxPopupTransientWindow instead of a
wxFrame., 2001-11-30) which introduced the use of wxPopupTransientWindow
in this code.
Allow wxPopupTransientWindow to work without wxPU_CONTAINS_CONTROLS too
in wxMSW and don't use wxPU_CONTAINS_CONTROLS by default, notably
allowing wxTipWindow to be shown without stealing focus.
See https://github.com/wxWidgets/wxWidgets/pull/1942Closes#18636.
The iterator passed to erase() was off by 1, but this worked correctly
in the default build using wxVector, and not std::vector, because its
base() implementation was off by 1 too.
Now that wxVector bug is fixed (see the parent) commit, fix the code
using it too, which makes it work both in the default and STL builds.
Closes#18765.
This is embarrassing, but the iterator returned by this method seems to
have always been wrong, ever since it was added back in 946954d3bf
(Added reverse iterator to wxVector<T>, 2008-09-16). Moreover, it was
also broken in its const_reverse_iterator counterpart where it was
copy-and-pasted in f7ef20685f (Add wxVector<>::const_reverse_iterator,
2013-05-08).
Finally fix this to return the correct value and add at least a simple
unit test check that this method behaves as expected.
This is consistent with wxToString(wxColour) and seems more useful than
either returning black string representation (as wxMSW used to do) or
asserting (as wxGTK did).
Document this behaviour and add a test checking for it.
Closes#18623.
Also define wxColour-specific matchers to allow comparing RGB(A)
channels to the expected values, replacing the old ASSERT_EQUAL_RGB(A)
macros.
No real changes.
Fix setting focus in GUI tests using wxUIActionSimulator with GTK 2.
Fixing the actual problem allows to re-enable activating the TLW in
SetFocus() (done in d06e97e8d9 (Make sure toplevel is active in
SetFocus(), 2020-07-08), see #18783) and remove the now unnecessary
workarounds in the tests too.
See https://github.com/wxWidgets/wxWidgets/pull/1945
We probably could drop support for some gcc 4.x versions too, but we
definitely don't need to support gcc 3.x any longer and not doing it
simplifies the code a bit, so just assume gcc >= 4.
Closes https://github.com/wxWidgets/wxWidgets/pull/1943
