Struct FileDropEvent 

pub struct FileDropEvent {
    pub phase: FileDropPhase,
    pub position: Point,
    pub paths: Vec<PathBuf>,
}

The file-drop vocabulary for handling file drops from the OS. [InputEvent::FileDrop] carries a FileDropEvent, which embeds a FileDropPhase (Hover, Drop, Cancel, or the broadcast-only Ended that follows every Drop/Cancel) and the dropped file paths (only on Drop). A widget handling drops is hit-tested and bubbles like InputEvent::Scroll. Lifted flat for the same reason EditCommand is: an app’s file-drop handler names these types in its public API without being a widget author. A desktop OS file drag/drop event — hit-tested and bubbling exactly like InputEvent::Scroll, by position, so a crate::widget::ChildPod container routes it with no change of its own (see InputEvent::translated/InputEvent::transformed).

Source

Only a desktop shell publishes this today: frust-shell-desktop maps winit’s HoveredFile/DroppedFile/HoveredFileCancelled window events onto the three FileDropPhases (see that crate’s app_handler module for the exact mapping, including why Drop’s paths is a coalesced batch rather than one event per file). Android, iOS and web publish nothing — none of those embeddings surfaces an OS file-drag signal to this framework, so a frust-widgets drop target never engages on those hosts (see docs/LIMITATIONS.md).

Broadcast follow-up

A shell resolves a Drop or Cancel at the last cursor position it knows, which can sit over a region no widget handles a file drop in — and on a platform that sends no cursor motion during an OS drag, that is the last in-window position before the drag began, not the release point. Even a Drop or Cancel some widget handles reaches only that one widget, while the drag may have opened state in others along the way (two independent drop-target groups, each hovered in turn). So after the hit-tested dispatch of every Drop or Cancel, handled or EventResult::Ignored, crate::app::RenderRoot::event immediately dispatches a second event in the same call: this struct with FileDropPhase::Ended, which InputEvent::is_broadcast reports as a broadcast, so every container forwards it to every child. A widget that already finished the drag on the hit-tested event finds nothing left to end in it, so answering Ended must be idempotent.

Fields

phase: FileDropPhase

The gesture phase.

position: Point

Where the drag is, in the receiving widget’s local logical space — translated like InputEvent::Scroll’s position by the container chain that routes it.

paths: Vec<PathBuf>

The dropped files — populated only for FileDropPhase::Drop. FileDropPhase::Hover/FileDropPhase::Cancel/ FileDropPhase::Ended always carry an empty list: the platform source delivers one file per hover notification with no “this is the complete set” signal, so the full list is only ever knowable once files are actually released.

Untrusted input. The paths arrive verbatim from the OS drag source — whatever application the user dragged from — and nothing between it and the receiving widget validates them: a path may be a symlink to somewhere else, a directory, a device node, a file of any size, or carry a name built to mislead when displayed. A consumer must treat them as untrusted: resolve symlinks (and re-check where they lead) before opening, check the type and size before reading, and sanitise a file name before showing it.

Trait Implementations

impl Clone for FileDropEvent

fn clone(&self) -> FileDropEvent

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for FileDropEvent

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl PartialEq for FileDropEvent

fn eq(&self, other: &FileDropEvent) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for FileDropEvent