If the Window Manager supports the _NET_WM_STATE_HIDDEN, we use it to use
the _NET_WM_STATE protocol when de-iconifying windows (iconification is
unchanged, via XIconifyWindow). Additionally, we no longer interpret all
UnmapNotify events for our window as the result of iconification.
(Based on patch by Tomas Frydrych <tf@linux.intel.com>)
NSEvent -scrollingDeltaX and -scrollingDeltaY aren't defined before
10.7, so objc assumes that they return a pointer. Trying to cast to a
float generates a compiler error.
XInput >= 2.1 allows for implementing smooth scrolling,
reporting the different scrolling axes as valuators.
Any change in those will be reported as GdkEventScroll
events with delta_x/y information.
the older kind of scroll events is still handled, and
emulated in devices able to provide smooth scrolling,
setting _gdk_event_set_pointer_emulated() in that case.
nsevent scrollingDeltaX/Y (available on OSX >= Lion) is used to
provide the smooth scrolling values. In any case, old fashioned
events are still sent, setting _gdk_event_set_pointer_emulated()
if the event contains both smooth and non-smooth values.
Events of type GDK_SCROLL will be received if the client side window
event mask has either GDK_SCROLL_MASK or GDK_SMOOTH_SCROLL_MASK.
GDK_BUTTON_PRESS_MASK has been removed from type_masks[GDK_SCROLL]
as that bit is often set for other-than-scrolling purposes, and
yet have the window receive scroll events. In GTK+, this forces
non-smooth events bubbling, even if the widgets above want smooth
events, and legitimately set GDK_[SMOOTH_]SCROLL_MASK.
If a device provides both smooth and non-smooth events, the latter will be
flagged with _gdk_event_set_pointer_emulated() so the client side window
receives one or the other. If a device is only able to deliver non-smooth
events, those will be sent, so both direction/deltas may need to be handled.
get_event_window() just checked on GDK_TOUCH_MASK, including for emulated
pointer events, so at the very least those should also match evmasks with
no touch events whatsoever
If an active grab kicks in on a different window, _gdk_display_has_device_grab()
would still find the former implicit grab for the window below the pointer, thus
sending events to an unrelated place.
If a grab with GDK_TOUCH_MASK kicks in due to a touch sequence emulating pointer
events, don't mutate the sequence into emitting touch events right away.
Create the backing GdkTouchGrabInfo for touches even if the pointer
emulating touch sequence is already holding an implicit grab on a
window that didn't select for touch events.
the backing GdkTouchGrabInfo will be needed if the overriding device
grab finishes before the touch does in order to send events back to
the implicit grab window. Instead, wait until the touch is physically
finished before removing the matching GdkTouchGrabInfo
GDK will only receive touch events when dealing with a multitouch
device, so these must be transformed to pointer events if the
client-side window receiving the event doesn't listen to touch
events, and the touch sequence the event is from does emulate
the pointer.
If a sequence emulates pointer events, it will result in a
button-press, N motions with GDK_BUTTON1_MASK set and a
button-release event, and it will deliver crossing events
as specified by the current device grab.
These are equivalent to an implicit grab (with !owner_events), so
if the touch leaves or enters the grab window, the other window
won't receive the corresponding counter-event.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
Anytime a touch device interacts, the crossing events generation
will change to a touch mode where only events with mode
GDK_CROSSING_TOUCH_BEGIN/END are handled, and those are sent
around touch begin/end. Those are virtual as the master
device may still stay on the window.
Whenever there is a switch of slave device (the user starts
using another non-touch device), a crossing event with mode
GDK_CROSSING_DEVICE_SWITCH may generated if needed, and the normal
crossing event handling is resumed.
Translate XI_TouchBegin/Update/End to GDK_TOUCH_BEGIN/UPDATE/END
events.
At the same time,
set pointer-emulated flags on button events with XIPointerEmulated
and on touch events emulating the pointer.
This commit introduces GDK_TOUCH_BEGIN/UPDATE/END/CANCEL
and a separate GdkEventTouch struct that they use. This
is closer to the touch event API of other platforms and
matches the xi2 events closely, too.
We introduce GDK_SOURCE_TOUCHSCREEN and GDK_SOURCE_TOUCHPAD
for direct and indirect touch devices, respecively. These
correspond to XIDirectTouch and XIDependentTouch in XI2.
My previous fix for this broke the progress bar in epiphany. This fix
makes it work again, and keeps the gimp bug fixed.
Basically, whenever we do a non-double-buffered rendering we have to
flush the entire window as it might be drawn outside the double
buffering machinery.
Once we've made them popup windows we must also implement the popup_done event
handler on the shell surface listener. The best we can currently do is to hide
the window. This will then signal up to GTK which could then deactivate the
appropriate menu (see https://bugzilla.gnome.org/show_bug.cgi?id=670881)
This allows us to get the device if we need to make the window a popup. This
relies on the side effect that GTK calls into GDK to take a grab before the
popup window is shown.
Since it's generated, we install the header by putting it into
gdkinclude_HEADERS, so it's wrong to put it again into
gdk_public_h_sources.
This fixes the build.
