pub struct SelectionToolbarRequest {
pub anchor: Rect,
pub actions: SelectionToolbarActions,
pub present_menu: bool,
}Expand description
One focused field’s published “here is my selection, these verbs apply to it, and this is whether a menu is wanted over it right now”.
Published per paint pass by every focused field, with or without a
selection; a pass without one means no field holds the focus. Two facts of
different shapes travel together here: anchor and
actions are a level — the state of the field as it
stands this frame, which a platform responder chain must be able to read at
any moment — while present_menu is the edge that
asks for a menu to go up.
Fields§
§anchor: RectThe selection’s bounding rect in absolute logical window space — the
same space an OverlayEntry::window_rect
uses, so a framework toolbar can be placed against it directly and a
native menu can be anchored to it after the shell’s own scale conversion.
Falls back to the caret rect while the selection is collapsed, which is the right anchor for a paste-only menu.
actions: SelectionToolbarActionsWhich verbs apply. A level: computed from the field’s own state, not from whether any bar is up, so a hardware Cmd+C arriving with nothing on screen still finds an answer here.
Whether the field wants a menu presented now — the one edge in an otherwise level-shaped request.
A field raises this when a gesture asks for the bar (a long press, a
secondary press) and drops it again when the bar is dismissed, while it
keeps republishing the same anchor and verbs either way. It is what
RenderRoot::selection_toolbar_generation
moves on, together with actions — an anchor that merely follows a
growing selection must not ask a platform to re-present its menu.