Struct FolderChanges 

pub struct FolderChanges { /* private fields */ }

The waiting side of a FolderWatch; see FolderChanges::next.

Cheap to clone and free to move to another thread, so each Command::perform can take its own.

Implementations

impl FolderChanges

pub fn next(&self) -> Vec<FolderChange>

Blocks until something changes in a watched folder, then returns everything that changed within the next tenth of a second, oldest first and each change once. A burst of thousands of changes therefore arrives as a few batches, not as thousands of answers.

While nothing changes the thread sleeps in the kernel and costs no processor time. When the FolderWatch is dropped, a waiting next wakes and returns an empty list, and so does every later call: an empty answer means “stop waiting”. Call it inside Command::perform, never in update or view.

A rename inside one folder is one FolderChangeKind::Renamed. An entry moved from one watched folder to another is FolderChangeKind::Removed in the first and FolderChangeKind::Created in the second, as it is when only one side is watched.

pub fn next_within(&self, bound: Duration) -> Option<Vec<FolderChange>>

Waits like next, but at most bound for the first change; None when nothing changed in that time. The watch goes on: ask again.

Made for screen tests: a Harness runs the work of a Command::perform on the spot, so a wait with no end would hold the test for good. A running application has a thread for its watch and keeps using next. Once a change has come, the tenth of a second that gathers its batch is waited in full, so a batch is never cut short by the bound.

Trait Implementations

impl Clone for FolderChanges

fn clone(&self) -> Self

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for FolderChanges

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

Formats the value using the given formatter.