Commit Graph

759 Commits

Author SHA1 Message Date
Matthias Clasen
2ef4b930c7 Don't force BUTTON1_MASK on non-touch events
This problem was pointed out by Hans de Goede in
https://bugzilla.gnome.org/show_bug.cgi?id=673458
2012-04-06 20:25:21 -04:00
Alexander Larsson
c5a8f3cb61 gdk: Remove GdkDisplay->ignore_core_pointer
This is not used anywhere anymore
2012-04-03 11:37:42 +02:00
Benjamin Otte
bd55519f7e gdk: A TOUCHPAD device behaves like a mouse
and not like a TOUCHSCREEN. So treat it like that.

https://bugzilla.gnome.org/show_bug.cgi?id=672009
2012-03-20 02:07:29 +01:00
Matthias Clasen
0e07d6589e gdk: Don't drop the emulating_pointer flag
When manually copying touch events, we must not forget the
emulating_pointer flag.
2012-03-04 11:24:51 -05:00
Matthias Clasen
88ebe2285f gdk: Emulate motion events when requested
GtkRange was using GDK_POINTER_MOTION_MASK, and it was not
getting any emulated motion events, because we only translate
from GDK_BUTTON_MOTION_MASK to GDK_POINTER_MOTION_MASK, but not
the other way around, and emulated_mask only had
GDK_BUTTON_MOTION_MASK in it. Now we put GDK_POINTER_MOTION_MASK
in emulated_mask and successfully match for windows that
have GDK_POINTER_MOTION_MASK or any of the button motion masks
selected.

This fixes range sliders not following the finger and jumping
to the last position upon release.
2012-03-02 23:33:16 -05:00
Paolo Borelli
1a75eff9a9 Annotate gdk_window_get_frame_extents
"rect" is an output parameter
2012-03-02 18:58:03 +01:00
Carlos Garnacho
77cbc98044 gdk: update csw event mask filter to handle smooth scroll
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.
2012-03-01 16:28:57 -05:00
Carlos Garnacho
b177bd92aa gdk: Filter out either smooth or non-smooth event depending on the evmask
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.
2012-03-01 16:28:57 -05:00
Michael Natterer
c41b52b4f6 gdk: transfer event->scroll.delta_x/y through csw 2012-03-01 16:28:57 -05:00
Carlos Garnacho
28e7d3c148 gdk: Get the right event window for pointer emulated events
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
2012-03-01 16:25:28 -05:00
Carlos Garnacho
0bb2e6f264 gdk: Set correct GdkModifierType on pointer emulated events 2012-03-01 16:25:27 -05:00
Carlos Garnacho
fcbcac0ca3 gdk: translate correctly from touch events into emulated pointer events 2012-03-01 16:25:27 -05:00
Matthias Clasen
11fdf1667c gdk: Don't treat touch events as button events
One more place where we assumed that touch events have a button
field.
2012-03-01 16:25:27 -05:00
Matthias Clasen
3880b12196 gdk: Use the last alive grab in order to get the event window
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.
2012-03-01 16:25:27 -05:00
Carlos Garnacho
9c6f71bfc7 gdk: Don't mutate pointer events to touch events just because a grab says so
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.
2012-03-01 16:25:27 -05:00
Carlos Garnacho
5942fee240 gdk: Let implicit touch grabs coexist with an implicit pointer grab
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.
2012-03-01 16:25:26 -05:00
Carlos Garnacho
b897ba0cd8 gdk: Don't fully destroy the implicit touch grab on ::grab-broken
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
2012-03-01 16:25:26 -05:00
Carlos Garnacho
6efe116715 gdk: Listen to touch events by default on the native window
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.
2012-03-01 16:25:26 -05:00
Carlos Garnacho
0a80c26cdf gdk: Only trigger motion hints machinery on motion events
Touch events have no need for it, plus the concept behind
gdk_event_request_motions() doesn't wrap around multiple
touches within a device.
2012-03-01 16:25:26 -05:00
Carlos Garnacho
2f2774b7a9 gdk: Have touch grabs behave like the implicit grab wrt crossing events
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.
2012-03-01 16:25:25 -05:00
Carlos Garnacho
c72a77b04c gdk: handle implicit touch grabs
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.
2012-03-01 16:25:25 -05:00
Carlos Garnacho
b5de12debd gdk: Don't change window_under_pointer for pure touch events
Only touch events that emulate the pointer do change it.
2012-03-01 16:25:25 -05:00
Carlos Garnacho
8689921b90 gdk: Generate crossing events around touch devices' press/release
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.
2012-03-01 16:25:21 -05:00
Carlos Garnacho
7f35708cee gdk: Add touch event types and mask
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.
2012-03-01 16:25:20 -05:00
Alexander Larsson
fd0450b4e7 Fix up rendering of non-double-buffered overlays
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.
2012-03-01 14:14:33 +01:00
Javier Jardón
9d0febc9a6 Change FSF Address 2012-02-27 17:06:11 +00:00
Matthias Clasen
ec25699f05 Clean up whitespace in _gdk_window_got_event
At the same time, fix an uninitialized warning.
2012-02-23 22:20:07 -05:00
Carlos Garnacho
c15d23ab5b gdk: Ensure that GdkPointerWindowInfo is only generated for pointers 2012-02-23 22:11:17 -05:00
Matthias Clasen
5e67d61ff4 Fix an uninitialized variable warning 2012-02-23 20:01:06 -05:00
Carlos Garnacho
5b014bfdfb gdk: Keep track of the last slave device used
This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
that are not directly caused by a device event (ie due to
configure events or grabs).
2012-02-23 16:45:29 -05:00
Alexander Larsson
26ed41ece5 Remove unused functions 2012-02-19 15:10:48 +01:00
Alexander Larsson
fcb58f3c83 Don't unnecessarily clear background twice in no EXPOSE_MASK case
We already clear in begin_paint, no need to do it again. In fact, this
will get the wrong result if the background has alpha.
2012-02-19 11:55:22 +01:00
Alexander Larsson
e3da2f55ea Fix background clearing when exposing with non-double buffered widgets
We used to set a flushed boolean whenever we flushing double buffered
areas to the window due to a non-db draw. We then read back from the
window if this was set. This broke when we were doing multiple paints
of the same area after a flush as we were re-reading the window each
time, overdrawing what was previously draw.
2012-02-19 11:43:48 +01:00
Alexander Larsson
251cffb638 Fix transparency handling with non-double-buffered drawing
Sometimes we need to read back the window content into our double
buffer due to rendering a window with alpha when there is
no implicit paint or it has been flushed due to non-db drawing
before.

However, in this case we can't use gdk_cairo_set_source_window as
it might trigger an implicit paint flush as we detect what we
think is a direct non-double buffered window draw operation, which
will flush the implicit paint operation that we're just setting up.

To fix this we use the raw gdk_window_ref_impl_surface operation
to get the source surface.
2012-02-09 21:14:07 +01:00
Alexander Larsson
5d9736fe13 Fix non-double-buffered drawing
There was a sign issue in a coordinate transform that made us
flush the wrong region when flushing an implicit paint.
The non-double buffered drawing would then be drawn over the
right area, but then at the end of the implicit paint this
would be overdrawn with the area we didn't properly remove
from the implicit paint.

Also, the translation from window coords to impl window
coords is now done before removing any active double
buffered paints, as these are also in impl window coords.
2012-02-09 21:14:07 +01:00
Alexander Larsson
fed1cfb122 Make the default background for GdkWindows transparent
With the changes in default CSS to make the default background transparent
we ran into issues where intermediate GdkWindow (for instance the
view_window in GtkViewport) where we didn't set an explicit background
(because before they were always covered). So instead of showing throught
the transparent windows were showing the default backgroind of the intermediate
window (i.e. black).

With this change we also needed to fix GtkViewport, as it was previously
relying on the bin and view windows to cover widget->window so that the
border was not visible if shadow_type was NONE.
2012-02-09 16:39:23 +01:00
Alexander Larsson
7ec927a386 Fix visibility notification event reporting
We were checking the event mask for GDK_VISIBILITY_NOTIFY,
not GDK_VISIBILITY_NOTIFY_MASK, which was clearly a typo.
2012-01-20 11:01:49 +01:00
Javier Jardón
24360a8076 gdk/*: Use g_list_free_full convenience function 2012-01-05 04:22:42 +01:00
Javier Jardón
a3abc18858 Deprecate all the public API that is using GdkColor struct 2011-12-22 02:59:39 +00:00
Xan Lopez
2d70d8fa36 gdkwindow: plug memory leak
==23282== 64 bytes in 2 blocks are definitely lost in loss record 8,069 of 13,389
==23282==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==23282==    by 0x39A1C3E2EA: cairo_region_create (cairo-region.c:196)
==23282==    by 0x6D9AF3D: recompute_visible_regions_internal (gdkwindow.c:964)
==23282==    by 0x6D9B4B8: recompute_visible_regions (gdkwindow.c:1126)
==23282==    by 0x6DA3450: gdk_window_hide (gdkwindow.c:5689)
==23282==    by 0x6D9CED9: _gdk_window_destroy_hierarchy (gdkwindow.c:2042)
==23282==    by 0x6D9D040: gdk_window_destroy (gdkwindow.c:2109)
==23282==    by 0x655B5E4: gtk_entry_unrealize (gtkentry.c:3012)
==23282==    by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)
==23282==    by 0x706710B: g_type_class_meta_marshal (gclosure.c:885)
==23282==    by 0x7066DF9: g_closure_invoke (gclosure.c:774)
==23282==    by 0x7080585: signal_emit_unlocked_R (gsignal.c:3340)
==23282==    by 0x707F619: g_signal_emit_valist (gsignal.c:3033)
==23282==    by 0x707FB71: g_signal_emit (gsignal.c:3090)
==23282==    by 0x679E243: gtk_widget_unrealize (gtkwidget.c:4458)
==23282==    by 0x64E83C7: gtk_bin_forall (gtkbin.c:172)
==23282==    by 0x6548BBD: gtk_container_forall (gtkcontainer.c:2014)
==23282==    by 0x67A966D: gtk_widget_real_unrealize (gtkwidget.c:10253)
==23282==    by 0x672D002: gtk_tool_item_unrealize (gtktoolitem.c:474)
==23282==    by 0x7068BF3: g_cclosure_marshal_VOID__VOID (gmarshal.c:85)

https://bugzilla.gnome.org/show_bug.cgi?id=666552
2011-12-19 15:06:22 -05:00
Cosimo Cecchi
8f4f7faa11 window: copy back window surface data when the implicit paint is flushed
When an implicit paint is flushed during expose, e.g. because a
non-double buffered widget is painting, make sure to copy the existing
data from the window surface we rendered before flushing back to the
paint surface, instead of using an empty base.
Code was already handling that (and said so in the comment), but only
when no implicit paint was used at all, and not in the case when it's
flushed mid-expose.
2011-12-07 08:54:09 +01:00
Cosimo Cecchi
2fad8eb0c3 window: trivial cleanup 2011-12-06 18:27:59 -05:00
Cosimo Cecchi
e3744bbd70 window: remove unused arguments and variables
Trivial cleanup, no functional change.
2011-12-06 17:49:35 -05:00
Alexander Larsson
4597f1ea6a gdk: gdk_window_get_update_area don't remove alpha covered areas
gdk_window_get_update_area is supposed to get the area where things
need painting, and remove them from the update areas. However, if
some area is covered by other windows with an alpha background we
can't just expect whatever the app choses to render in the update
area as correct, so we don't actually remove these areas, meaning
they will get correctly rendered when we get to the expose handlers.
2011-12-05 12:18:22 +01:00
Alexander Larsson
65ef15812b gdk: gdk_window_move_region
gdk_window_move_region doesn't move children, so we can't copy
transparent child window regions with copyarea, so we remove these
from the copy region.
2011-12-05 12:16:55 +01:00
Alexander Larsson
76ea768316 gdk: Fix alpha window background paintings on non-implicit paints 2011-12-05 11:40:30 +01:00
Alexander Larsson
68843a3e93 gdk: Remove unused _gdk_window_calculate_full_clip_region 2011-12-05 10:59:07 +01:00
Alexander Larsson
f00cfe1fac Handle has_alpha_background for parent-relative backgrounds 2011-12-05 10:55:55 +01:00
Alexander Larsson
7a263c68a0 gdk: Fix repaint of layered region during move_region 2011-12-01 22:08:00 +01:00
Alexander Larsson
8e28f53a1d gdk: Fix repaint of layered region during scroll 2011-12-01 22:08:00 +01:00