Rework pointer handling

[PoignardAzur]

Masonry's pointer handling is inherited from Druid, and there are some gray areas that need to be better specified, documented and enforced.

Hot status

Hot status now roughly means "This widget is the one that will receive clicks from the mouse".

There are two things we need to specify:

• (1) What hot status means in a context with multiple pointers.
• (2) How hot status relates to layout changes.

(1) means we either get hot state for only the primary pointer, or the last active pointer; or we get multiple hot states, and is_hot() will take a pointer id as parameter, or we get hot state for every pointer without distinction of which pointer makes which widget hot.

(2) is especially annoying, because it breaks the unidirectionality of the "events -> layout -> paint" flow.

We may also want to rethink how hot status interacts with widgets overlapping one another; eg if we want a browser-like "mouseleave" event that doesn't trigger where the mouse goes from a container widget to one of its children.

See also: https://gist.github.com/PoignardAzur/c60cd72d790c083b7b55269bc91912db#file-hot_state-md

Active status

Currently, active is a flag which:

• Can be set by widget code, but never by framework code.
• Forces mouse events to be routed to the active widget, even when the cursor is out.
• Can be read by widget code to change how the widget is rendered (or laid out).

Aaaaand... that's it. Any other information it might represent (eg that it means "the user is in the middle of a mouse press on this widget") is purely down to widget implementation.

Ideally, I would like "active" to be better integrated in the framework:

• The framework should guarantee that there is only one active widget at a time (per pointer).
• The framework should force the widget to lose active state when some events occur; not just MouseLeave, but also Tab being pressed, the window losing focus, the widget being disabled, etc.
• There should be an equivalent to setPointerCapture in the browser; so that when a widget is active and the cursor leaves that widget, not only does the widget still get pointer events, other widgets do not (or at least in a way that lets them know the original widget still "owns" the pointer).
• Pointer capture should also be handled at the app level if possible, in case the pointer leaves the window.

We might even want to be more opinionated and have the framework guarantee that hot state and active state are correlated (eg when user clicks, active state is given to the hot widget).

See also: https://gist.github.com/PoignardAzur/c60cd72d790c083b7b55269bc91912db#file-active_status-md

[PoignardAzur]

See also: linebender/druid#828

[PoignardAzur]

This was addressed in the Pass Spec RFC. (Though multiple pointers still aren't handled.)