Line 1: |
Line 1: |
| + | {{Dated}} |
| + | |
| ===Touchscreen Support=== | | ===Touchscreen Support=== |
| | | |
Line 53: |
Line 55: |
| |hide keyboard hints from touch only UI | | |hide keyboard hints from touch only UI |
| |- | | |- |
− | |Scrolling views | + | |Scrolling a zoomed paint/drawing view |
| |n/a | | |n/a |
| |two finger drag to pan/scroll canvas | | |two finger drag to pan/scroll canvas |
Line 68: |
Line 70: |
| |... | | |... |
| |} | | |} |
| + | |
| + | = Other = |
| + | [CSA: adding here some issues which aren't in the above table, not sure how they fit in] |
| + | ; Keyboard hints: show different keyboards for numeric, URL, or free-text input. (For example, TurtleArt wouldn't show the full keyboard when it just needs you to enter a number.) |
| + | ; Hover palettes: might need to be offset more from finger location to be useable on touchscreen (so that the finger doesn't cover up the palette when it pops up) |
| + | ; Drag to scroll: I prototyped this with "drag from top" / "drag from bottom" to scroll, it wasn't so bad. Simply mapping two-finger scroll to mouse scroll buttons gets you pretty far, although there are some focus issues to deal with -- it should first focus the element under the scroll start location, and *then* send it mouse scroll wheel events |
| + | ; Slide to switch zoom levels: just requires binding F12,F13 etc to "zoom out" and "zoom in", so olpc-kbdshim can emit the proper function key instead of trying to remember what zoom level it is in. |
| + | ; Uniform support for "mouseover" events: perhaps "swiping down" from a button will reveal its mouseover tool tips, for example. This is a bit of a hack, but it might make all the existing sugar activities which rely on mouseover more usable. |