masonry: replace set_active and is_active with pointer capture

[tomcur]

Also improve documentation of pointer capture.

Continuation of 59ee615 (#488).

Makes has_pointer_capture available on all context types except LayoutCtx, like is_active used to be.

[PoignardAzur]

Good work.

[PoignardAzur]

I don't think there's any confusion, but maybe I missed a Zulip thread.

The semantics are this: if a widget has pointer capture, either that widget is hot/hovered, or no widget is. This matches web behavior.

[tomcur]

I duplicated the discussion point from here

xilem/masonry/src/contexts.rs

Lines 254 to 260 in 6c49516

	/// Discussion: there is currently some confusion about whether a
	/// widget can be considered hot when some other widget is active (for
	/// example, when clicking to one widget and dragging to the next).
	/// The documentation should clearly state the resolution.
	pub fn is_hot(&self) -> bool {
	self.widget_state.is_hot
	}

I probably should've referenced it instead of copying. If the question is resolved I can remove the comment from this PR, and create a new PR removing the old discussion point on is_hot and document that behavior.

Somewhat related to this discussion is this Zulip thread about pointer exclusivity: https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/Exclusive.20events.20when.20interacting

[PoignardAzur]

If the question is resolved I can remove the comment from this PR, and create a new PR removing the old discussion point on is_hot and document that behavior.

Sure.

Somewhat related to this discussion is this Zulip thread about pointer exclusivity: https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/Exclusive.20events.20when.20interacting

Oh, I forgot about that thread. I wonder if we have an active issue somewhere referencing it. We might want to add a comment with a link to either a github issue or the zulip thread.

[tomcur]

I've removed the discussion point. I can update the docs with the behavior of capture/hot on top of this PR. Easiest after it's merged.

[PoignardAzur]

LGTM.

I especially appreciate the added tests.

[DJMcNab]

A few small suggestions, but otherwise looks good. The same thing as in #563 applies

[DJMcNab]

In what context would it be valid for a pointer without the capture to release this capture?

[tomcur]

Currently, any widget can release the capture during any event. That's either a target of an event or one of its ancestors. The target can be the widget with the pointer capture for a pointer event, or the widget with keyboard focus for a text event, or can be the target widget of an accessibility event. Widgets are not currently notified when they lose the capture in this way.

There's no hard requirement at the moment that says, e.g., the pointer capture widget (if any) should be equal to the widget with keyboard focus (if any).

[DJMcNab]

Another question here: Is it valid for a disabled widget to have the pointer capture?

[tomcur]

It is at the moment. If we decide against that, the same should be invalid for keyboard focus. Capturing the pointer or requesting focus should then not be allowed when disabled, and in EventCtx::set_disabled we should traverse the tree up from the widgets with pointer capture and keyboard focus to check whether their subtree is now disabled.

[PoignardAzur]

@tomcur Anything you'd like to change before merging?

[tomcur]

Happy for this to be merged. I believe I should do the merge because of the author-merges policy, now Daniel added me to the org?

[PoignardAzur]

Yup.