pub struct SelectionToolbarRequest {
pub anchor: Rect,
pub actions: SelectionToolbarActions,
pub present_menu: bool,
}Expand description
The selection-toolbar seam: the request a text field publishes when it
has a selection (SelectionToolbarRequest/SelectionToolbarActions),
and the knobs that decide who draws it.
set_selection_toolbar_policy chooses
SelectionToolbarPolicy::Framework (the default — a field floats its
own pod through the overlay portal) or SelectionToolbarPolicy::Native
(the platform’s own edit menu, e.g. iOS’s UIEditMenuInteraction) — see
that type’s own docs for the two-route split. This is not an
unconditional free choice, though: a platform shell whose system owns the
menu can LOCK it instead, with frust_core::lock_selection_toolbar_policy
— once locked, set_selection_toolbar_policy is refused rather than
obeyed, so an app cannot silently undo a platform requirement it doesn’t
know exists. iOS’s shell locks SelectionToolbarPolicy::Native at
start-up for exactly this reason: a framework-drawn toolbar’s own Paste
button would break the exemption that keeps iOS’s per-app paste-permission
prompt from firing on every paste.
set_selection_toolbar_builder installs the view a Framework-policy
pod floats, replacing whatever the framework’s own baseline (installed
at bootstrap, before the first frame) or an earlier design system already
installed. A design system’s own installer should reach for
frust_core::install_selection_toolbar_builder_if_unset instead — the
cooperative, set-if-unset half of the same pair — so two catalogs linked
into one binary never fight over the slot, and neither ever undoes an
app’s own explicit override.
use frust::{
SelectionToolbarPolicy, lock_selection_toolbar_policy, set_selection_toolbar_policy,
};
// A shell whose platform owns its own system edit menu locks the route,
// so that requirement wins no matter what app code does afterward.
let claimed = lock_selection_toolbar_policy(SelectionToolbarPolicy::Native);
assert!(claimed, "the first claim always takes the lock");
// An app's later override is refused rather than obeyed once locked.
set_selection_toolbar_policy(SelectionToolbarPolicy::Framework);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.
Trait Implementations§
Source§impl Clone for SelectionToolbarRequest
impl Clone for SelectionToolbarRequest
Source§fn clone(&self) -> SelectionToolbarRequest
fn clone(&self) -> SelectionToolbarRequest
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreimpl Copy for SelectionToolbarRequest
Source§impl Debug for SelectionToolbarRequest
impl Debug for SelectionToolbarRequest
Source§impl PartialEq for SelectionToolbarRequest
impl PartialEq for SelectionToolbarRequest
impl StructuralPartialEq for SelectionToolbarRequest
Auto Trait Implementations§
impl Freeze for SelectionToolbarRequest
impl RefUnwindSafe for SelectionToolbarRequest
impl Send for SelectionToolbarRequest
impl Sync for SelectionToolbarRequest
impl Unpin for SelectionToolbarRequest
impl UnsafeUnpin for SelectionToolbarRequest
impl UnwindSafe for SelectionToolbarRequest
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
impl<ST, DT> CastableFrom<ST, Initialized, Initialized> for DT
impl<ST, DT> CastableFrom<ST, Uninit, Uninit> for DT
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Downcast for Twhere
T: Any,
impl<T> Downcast for Twhere
T: Any,
Source§fn into_any(self: Box<T>) -> Box<dyn Any>
fn into_any(self: Box<T>) -> Box<dyn Any>
Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.Source§fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
Rc<Trait> (where Trait: Downcast) to Rc<Any>. Rc<Any> can then be
further downcast into Rc<ConcreteType> where ConcreteType implements Trait.Source§fn as_any(&self) -> &(dyn Any + 'static)
fn as_any(&self) -> &(dyn Any + 'static)
&Trait (where Trait: Downcast) to &Any. This is needed since Rust cannot
generate &Any’s vtable from &Trait’s.Source§fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
&mut Trait (where Trait: Downcast) to &Any. This is needed since Rust cannot
generate &mut Any’s vtable from &mut Trait’s.