Skip to content

Add FileSystemWatcher wrapping wxFileSystemWatcher - #191

Open
trypsynth wants to merge 2 commits into
AllenDang:mainfrom
trypsynth:fswatcher-wrapper
Open

Add FileSystemWatcher wrapping wxFileSystemWatcher#191
trypsynth wants to merge 2 commits into
AllenDang:mainfrom
trypsynth:fswatcher-wrapper

Conversation

@trypsynth

Copy link
Copy Markdown
Contributor

Summary

  • Adds a wxd_FileSystemWatcher_t opaque type and C functions (Create, Destroy, Add, AddTree, Remove, RemoveTree, RemoveAll), wrapping wxFileSystemWatcher, which picks the native backend per platform (FSEvents on macOS, inotify on Linux, ReadDirectoryChangesW on Windows, kqueue elsewhere).
  • Adds a new WXD_EVENT_TYPE_FSWATCHER event type mapped to wxEVT_FSWATCHER, plus wxd_FileSystemWatcherEvent_* accessors for the change type, path, new path (for renames), and warning/error info carried by the event.
  • Adds a WXDFSWEventCEnum enum matching wxFSW_EVENT_* for the events bitmask parameter.
  • On the Rust side, adds a FileSystemWatcher type (owned, Drop-based, following the same shape as the existing Timer wrapper) plus a category event trait (FSWatcherEvents::on_fswatcher_change) generated with the existing implement_category_event_handlers macro, matching how ButtonEvents/TextEvents/TreeEvents already work.

Design notes

wxFileSystemWatcherBase defaults its own event handler as the owner unless SetOwner() is called, so FileSystemWatcher implements WxEvtHandler directly (casting the watcher's own pointer to wxd_EvtHandler_t) and events are bound straight on the watcher object, no separate owner argument needed (unlike Timer, which really does require one on the wx side). SetOwner() itself is not exposed since the default behavior covers the common case; happy to add it if there's a use case for redirecting events elsewhere.

Motivation

Watching a file or directory for external changes (an open document being edited by another program, a config file, a directory listing) is a common desktop app need with no cross-platform story otherwise. wxWidgets already provides this with native backends per platform, it just was not wrapped by wxDragon yet.

Test plan

  • cargo build -p wxdragon succeeds locally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant