Floating widgets and text-editing for touch-screens

[dhardy]

The existing API for popup/floating widgets is insufficient.

Motivation: EditField

To offer a good touch-friendly text-editing experience, the EditField widget should:

• Support tap to focus, drag to scroll, hold+drag to select
• Virtual keyboard activation: see How to popup virtual keyboard on mobile device? rust-windowing/winit#2260
• Add handles to allow adjustment of selection range
• Show pop-up tip when state is erroneous
• Show cut/copy/paste buttons as pop-up when text is selected via touch

Selection handles could be done with child widgets, but the event model doesn't allow mouse/touch input outside of the parent's rect (drawing outside this area could also have clipping issues).

Showing a pop-up just outside the field is exactly what the current pop-up code is designed to support, however the input handling is not quite what we want: click/touch events outside of the pop-up will automatically close it before any other widget can handle the event. For the purposes above, events outside the edit field should close the pop-up, but not necessarily events on the edit field (e.g. selection handles stay so long as there is a selection).

Additionally, existing pop-up code is designed to place menus next to the parent widget. For the above, we want more explicit control over position (in widget-local coordinates).

Proposed adaptations to pop-up code

• Revise position control: support specifying a rect in widget-local coordinates

This might require adding a translation: Offset field to EventMgr (the sum of Widget::translation over all ancestors), but given how EventMgr::send_recurse works this shouldn't be hard. Unclear how to handle alternative positions (e.g. pop-up menus that should be on the right of the parent may be on the left if there is insufficient space). Worth also noting: menus should appear next to the parent but outside the frame added by the theme; currently widgets do not know about this frame. Possibilities:

1. Currently this is automated (the parent only specifies that it wants a pop-up to the left/right/above/below self)
2. The parent could exhaustively specify all viable positions in order of preference
3. The parent could retrieve available window Rect relative to its own coordinates, then calculate a position (best option?)
4. Return an immediate error on position failure

• Allow repositioning of popups

If we look at DragHandle's use in Slider, the DragHandle sends the drag-offset to the Slider parent, which then calls DragHandle::set_offset to update the position. So perhaps we have two options here:

1. Copy behaviour of DragHandle in Slider: make the handle large enough to cover the entire area of movement, and use find_id to determine whether the click is on the "real" handle
2. Make the pop-up the size of the real handle, and add functionality letting the parent move it

• Revise event handling: do not automatically close a pop-up when a click lands on its parent. Can we always use this new behaviour (will it work with menus)?
• Rename popup to float?

Implement for EditField

Touch-specific functionality should normally be shown only when there is a selection originating from a touch event (could be configurable, but probably not useful enough, except for testing).