Define g_signal_handlers_disconnect_by_data() if it's not available,
i.e. when using glib older than 2.32 where it was added, to fix the
build under old systems such as CentOS 6 broken by the changes of
8278f7b618 (see #18084).
Also use it elsewhere instead of g_signal_handlers_disconnect_matched()
as it's more readable.
Closes https://github.com/wxWidgets/wxWidgets/pull/760
GTKHandleDeferredFocusOut() is only ever called when gs_deferredFocusOut
is non-null, so there is no need to check for it inside this function
again.
No real changes.
It is often useful to know where is the focus coming from, for example
to determine if was in another window of the same composite control.
Remember the last focus in yet another global variable in wxGTK code to
allow setting wxFocusEvent::m_window correctly when generating
wxEVT_SET_FOCUS events.
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.
Don't delete the window wxWindowGesturesData when calling
EnableTouchEvents(wxTOUCH_NONE) but just free it, to make it safe to
call EnableTouchEvents() even from a touch event handler, which later
returns to wxGTK code that could still use the gestures data object.
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
Implement support for enabling just some gesture events instead of
having to choose between getting none or all of them.
Also make wxTOUCH_NONE really disable the gestures events generation
instead of just doing nothing as before.
Don't request touch event generation for all windows by default, this
has an inherent overhead and is not needed for 99% of the application
windows, so require calling EnableTouchEvents() explicitly to do it
instead.
Note that this requires properly initializing gesture recognizers in
wxOSX now that they're not always allocated, otherwise releasing them
when destroying the window would crash.
No real changes, just be consistent with wxWindowGesturesData forward
declaration as "class", clang (and MSVC) warn about mismatching keywords
being used for declaration and definition.
This is a first step towards enabling gesture events only for the
windows that are interested in them as it will make it possible to avoid
wasting space on unused data in the windows that don't need it.
No real changes so far.
Use wxGTK_HAS_GESTURES_SUPPORT to guard gesture-related code instead of
checking for the 3.14 GTK+ version explicitly in several places.
No real changes.
So wxNO_BORDER works with other controls, such as wxBitmapButton.
Also use GTK prefix on ApplyCssStyle(), and add an overload that
creates the GtkCssProvider.
webkitgtk apparently manipulates our scrollbar GtkAdjustment directly, setting
all members to zero to disable it. Since we never do that, those values were
unexpected. This is a better fix for the problem papered over by 45d66f592
Avoid the problems 3b4ee5a0 attempted to address in a much simpler way:
when a "size-allocate" is in progress, call gtk_widget_size_allocate()
directly, rather than deferring a call to gtk_widget_queue_resize().
See #17585
A change in size-allocate handling with GTK+ 3.20 exposed a flaw in our method for
deferring queue-resize requests. Using an idle callback to process the requests
did not work well with the GdkFrameClock-based system used since GTK+ 3.8. Using
the "check-resize" signal works better. Also with GTK+ >= 3.20, it seems necessary
to manually work the queue-resize up to the TLW, as otherwise the resized widgets
don't get updated without an external size-allocate event.
See #17585
This assert was redundant as a similar check is done in the base class dtor.
And while usually this assert is just annoying, instead of being helpful, when
running the unit test suite which installs a custom assert handler throwing an
exception, it is actively harmful as generating 2 asserts during the
destruction of a window with mouse capture results in immediate termination
(even in C++98 mode, unfortunately the whole idea of throwing from dtor is
probably unsalvageable anyhow when using C++11).
Since the changes of 8034e35391 (see #16870)
accelerators, including the standard ones such as Ctrl-F4 under MSW, didn't
work any longer inside the MDI children.
Fix this by extending IsTopNavigationDomain() to allow for checking whether
the given window should stop propagation of all keyboard events, as wxTLW
does, or only TAB navigation ones as wxMDIChildFrame and wxAuiFloatingFrame
do.
