summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* GdkTouchCluster Clarify doc languagemultitouchMatthias Clasen2012-02-181-1/+1
| | | | 'Transient' is what was meant here, not 'transitive'.
* GdkCrossingMode: Remove duplicated doc entryMatthias Clasen2012-02-181-2/+0
|
* gtk: Release captured events down the hierarchyCarlos Garnacho2012-02-183-14/+50
| | | | | Instead of releasing directly onto the target widget, release down the hierarchy as if uncaptured.
* touchcluster: use an array to store touch IDsCarlos Garnacho2012-02-184-40/+73
| | | | | | | | | A GList doesn't make much sense for storing guints, so now a GArray is used internally. gdk_touch_cluster_get_touches() has changed to return an allocated guint*, and gdk_touch_cluster_get_n_touches() has been added too.
* scrolledwindow: store whether the last button press was valid independentlyCarlos Garnacho2012-02-181-16/+11
| | | | | | | Use a separate boolean instead of coding it up in the last button press coordinates. This incidentally fixes 0-threshold on kinetic scrolling, allowing the child widget to get button releases before it prematurely gets ::grab-broken.
* scrolledwindow: Do not handle dnd-threshold=0Carlos Garnacho2012-02-181-14/+1
| | | | | There's no need for it as the GtkSettings property has a lower limit of 1.
* docs: Add section about multitouch and other interaction patternsCarlos Garnacho2012-02-183-2/+583
| | | | | | This is a ripoff of http://live.gnome.org/GTK%2B/DeviceInteractionPatterns, with better phrasing in general, some more factual points, and multitouch explained.
* improve docs for multitouch featuresCarlos Garnacho2012-02-189-27/+184
|
* gtk,gestures: Only match 0-length strokes with homologous stock onesCarlos Garnacho2012-02-181-1/+18
| | | | Avoids spurious stroke matching with fleeting touches.
* gtk,gestures: Handle multitouch gesturesCarlos Garnacho2012-02-182-33/+309
| | | | | | | | | | | | | Gestures are only compared with stock gestures with the same number of strokes. If a gesture consists of several strokes, the first stroke is compared (and any possible angle skew is gotten from it), and then the other strokes are correlated and also compared. If there's no feasible correlation of strokes, or the gestures yield an accumulated confidence that's below the threshold, the gesture is not considered to match. testgestures has been also added a simple 2-finger gesture for testing.
* textview: Set background on the widget's windowCarlos Garnacho2012-02-181-9/+6
| | | | | | The widget window is usually covered by the bin_window, this is just necessary so the parent scrolled window picks the right color for drawing the overshoot area.
* iconview: Set background on the widget's windowCarlos Garnacho2012-02-181-0/+1
| | | | | | The widget window is usually covered by the bin_window, this is just necessary so the parent scrolled window picks the right color for drawing the overshoot area.
* treeview: Set background on the widget's windowCarlos Garnacho2012-02-181-0/+1
| | | | | | The widget window is usually covered by the bin_window, this is just necessary so the parent scrolled window picks the right color for drawing the overshoot area.
* scrolledwindow: Use the child widget's window bg color for the overshoot areaCarlos Garnacho2012-02-181-3/+21
| | | | This makes the overshoot area seamless, if the child plays along.
* tests: only handle gestures on testgestures after the last stroke is liftedCarlos Garnacho2012-02-181-3/+10
|
* gtkwidget: only emit ::gesture when the last stroke is liftedCarlos Garnacho2012-02-181-0/+3
|
* gtk,gestures: Add gtk_gestures_interpreter_get_n_active_strokesCarlos Garnacho2012-02-183-0/+44
| | | | | | This call gets the number of currently active strokes, finished strokes (i.e. those that already had a GDK_BUTTON/TOUCH_RELEASE processed) don't count.
* entry: Only allow press-and-hold on the text_area windowCarlos Garnacho2012-02-181-0/+25
| | | | | This avoids oddities in spinbuttons, press-and-hold shouldn't be triggered on the buttons.
* gtk,pah: Don't cancel a ::press-and-hold that's scheduled to be activatedCarlos Garnacho2012-02-181-2/+10
| | | | | There was a slight window where the operation could be cancelled, causing an assert as the p-a-h data is NULL.
* gdkwindow: Add device parameter to gdk_window_create_touch_cluster()Carlos Garnacho2012-02-183-10/+18
| | | | | | | gdk_touch_cluster_set_device() had to be called right after anyway, so set the device directly within this call, and favor the most common scenario where there's just 1 single multitouch device behind 1 master device.
* demos: Demonstrate further features in the multitouch demoCarlos Garnacho2012-02-181-42/+225
| | | | | | | | | | | Now that GtkButton and GtkScale are multitouch approved, it's sufficient to enable GDK_TOUCH_MASK on them to have them deal with multitouch devices. The scales set rgba of the currently selected rectangle, and the button adds more rectangles, those can be manipulated simultaneously together with the rectangles, the only limit is the number of touches the touchscreen hw is able to detect.
* gdk: Listen to touch events by default on the native windowCarlos Garnacho2012-02-181-9/+49
| | | | | | | | | | | | | 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.
* gdk,devicemanager: Mark touch events emulating the pointer as suchCarlos Garnacho2012-02-181-2/+2
|
* gdk: Only trigger motion hints machinery on motion eventsCarlos Garnacho2012-02-181-0/+1
| | | | | | Touch events have no need for it, plus the concept behind gdk_event_request_motions() doesn't wrap around multiple touches within a device.
* gdk: Have touch grabs behave like the implicit grab wrt crossing eventsCarlos Garnacho2012-02-181-2/+16
| | | | | | 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.
* gtk,button: Handle touch eventsCarlos Garnacho2012-02-181-2/+38
| | | | | | Touch events don't generate crossing events themselves, so do not rely on these to determine whether the button release happened within the event window.
* gtk,range: Don't perform a GTK+ grabCarlos Garnacho2012-02-181-9/+5
| | | | | | The implicit grab on priv->event_window already warrants that this widget is the only one getting events while the button is pressed, so don't spare the GTK+ grab here.
* gtk: rewrite touch events wrt the window group tooCarlos Garnacho2012-02-181-0/+6
| | | | | | Likewise to pointer events, have touch events during a device grab with owner_events=TRUE be delivered normally as long as the widget pertains to the same window group.
* gdk,csw: handle implicit touch grabsCarlos Garnacho2012-02-183-40/+157
| | | | | | | | | | | | 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, and all touches would be automatically removed from every touch cluster.
* gdk,display: Add internal API to deal with touch implicit grabsCarlos Garnacho2012-02-182-0/+108
| | | | | | The necessary information about a touch implicit grab is stored in GdkTouchGrabInfo structs, these are meant to be transient to the touch sequence
* gdk,csw: Don't change window_under_pointer for pure touch eventsCarlos Garnacho2012-02-181-1/+3
| | | | Only touch events that emulate the pointer do change it.
* gdk,xi2: set pointer emulated flags on events with XIPointerEmulatedCarlos Garnacho2012-02-181-0/+7
|
* gdk: Add internal API to set "pointer emulated" flag on eventsCarlos Garnacho2012-02-182-2/+36
| | | | | This flag will be used for non-pointer events that are emulated from eg. touch events, or pointer events being emulated.
* gdk,xi2: Set GDK_BUTTON1_MASK on touch eventsCarlos Garnacho2012-02-181-0/+6
| | | | | | GTK+ handles both touch and pointer events through the same event handlers, so enable this modifier on touch events to avoid much special casing.
* gdk,xi2: Only enable multitouch if the server reports XI2.2Carlos Garnacho2012-02-183-8/+28
| | | | This enables multitouch-enabled GTK+ to run on older X servers.
* gdk,xi2: Update to latest XInput2.2 specCarlos Garnacho2012-02-185-37/+25
|
* gtk,pah: Handle press-and-hold on touch devicesCarlos Garnacho2012-02-181-5/+7
|
* gdk: Add gdk_event_get_touch_area()Carlos Garnacho2012-02-182-0/+90
| | | | | | If given an event coming from a touch devices, this functions will read the MT major/minor/orientation axes and return a cairo_region_t with the touch shape.
* gestures: Add some unit testsCarlos Garnacho2012-02-182-0/+257
|
* gtk: Document helper GtkWidget gestures APICarlos Garnacho2012-02-183-3/+30
|
* gestures: Add API documentationCarlos Garnacho2012-02-185-0/+336
|
* gtk: Add helper API to handle gesturesCarlos Garnacho2012-02-184-1/+137
| | | | | | | | | | | Although GtkGesturesInterpreter can be used standalone, GtkWidget deserves helper API to enable support for gestures. gestures can be enabled/disabled, and the ::gesture signal can be used to get the gesture ID. The internal GtkWidget gestures interpreter is only handled by touch events, if gestures are needed for other devices, a standalone gestures interpreter must be used.
* tests: Add testgesturesCarlos Garnacho2012-02-182-0/+360
| | | | | This testcase handles all gestures offered by GtkGestureType, and also creates and registers a custom M-shaped GtkGesture.
* gestures: Implement gestures interpretationCarlos Garnacho2012-02-181-1/+309
| | | | | | | The algorithm works on 2 GtkGestures, it finds out the similarity of these by bending the user provided gesture so it equals a stock one, the differences in areas are used to determine the level of confidence on both gestures being similar.
* Add a gestures interpreter base implementationCarlos Garnacho2012-02-186-0/+741
| | | | | | | This object is currently shallow, the API is defined but no gesture interpretation is performed. Additional API is declared to create and define gestures, which may consist of several strokes with an offset.
* xi2: Use GDK_SOURCE_TOUCH for multitouch devicesCarlos Garnacho2012-02-181-2/+25
| | | | | Any device with XITouchValuatorClassInfo classes qualify as multitouch now.
* gdk: Update touch events to latest specCarlos Garnacho2012-02-182-16/+7
|
* gtk-demo: Add multitouch demoCarlos Garnacho2012-02-182-0/+515
| | | | | | Pretty much ignores pointer events currently, so you're out of luck to see anything happening at all if you don't have a multitouch device...
* Add multitouch-event signal and vfunc to GtkWidgetCarlos Garnacho2012-02-183-1/+22
|
* Add machinery to emit GdkEventMultiTouch eventsCarlos Garnacho2012-02-182-14/+358
| | | | | | | | These events are created from GDK_TOUCH_MOTION/PRESS/RELEASE events, if the touch ID generating the event is within a touch cluster, that event is stored and not pushed to the queue, so a touch ID can only emit GDK_TOUCH_* or GDK_MULTITOUCH_* events at the same time.
View Lorry Controller Status