pub struct FileDropEvent {
pub phase: FileDropPhase,
pub position: Point,
pub paths: Vec<PathBuf>,
}Expand description
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: FileDropPhaseThe gesture phase.
position: PointWhere 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.