f6393199be
Kinetic scrolling is only done on touch devices, since it is sort of meaningless on pointer devices, besides it implies a different input event handling on child widgets that is unnecessary there. If the scrolling doesn't start after a long press, the scrolling is cancelled and events are handled by child widgets normally. When clicked again close to the previous button press location (assuming it had ~0 movement), the scrolled window will allow the child to handle the events immediately. This is so the user doesn't have to wait to the press-and-hold timeout in order to operate on the scrolledwindow child. The innermost scrolled window always gets to capture the events, all scrolled windows above it just let the event go through. Ideally reaching a limit on the innermost scrolled window would propagate the dragging up the hierarchy in order to keep following the touch coords, although that'd involve rather evil hacks just to cater for broken UIs. |
||
|---|---|---|
| .. | ||
| images | ||
| building.sgml | ||
| compiling.sgml | ||
| drawing-model.xml | ||
| getting_started.xml | ||
| glossary.xml | ||
| gtk3-sections.txt | ||
| gtk3.types | ||
| gtk-docs.sgml | ||
| gtk-query-immodules-3.0.xml | ||
| gtk-update-icon-cache.xml | ||
| Makefile.am | ||
| migrating-2to3.xml | ||
| migrating-checklist.sgml | ||
| migrating-GtkGrid.xml | ||
| migrating-GtkStyleContext.xml | ||
| migrating-smclient-GtkApplication.xml | ||
| migrating-unique-GtkApplication.xml | ||
| objects_grouped.sgml | ||
| osx.sgml | ||
| other_software.sgml | ||
| overview.xml | ||
| question_index.sgml | ||
| resources.sgml | ||
| running.sgml | ||
| text_widget.sgml | ||
| tree_widget.sgml | ||
| version.xml.in | ||
| visual_index.xml | ||
| windows.sgml | ||
| x11.sgml | ||