Omniform is a Tauri v2 desktop application. The Rust backend handles all process management, file I/O, archive extraction, and network downloads; the React frontend renders the UI and communicates with the backend exclusively through Tauri’s IPC bridge — there is no HTTP server, no WebSocket, and no shared memory between the two layers. Every action the user takes in the UI (adding a URL, picking a folder, cancelling a download) is translated into either a Tauri command call or a state update driven by an incoming Tauri event.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/damianiglesias/omniform/llms.txt
Use this file to discover all available pages before exploring further.
High-level overview
Rust backend
Located in
src-tauri/src/. Three modules:lib.rs— app entry point. Registers all five Tauri commands, initialises the four plugins (shell, dialog, fs, clipboard-manager), creates theDownloadRegistryshared state, and ensures the binary directory exists on startup.dependencies.rs— manages the automatic download and installation of yt-dlp and ffmpeg. Checks whether the binaries are present, fetches them from their respective sources if not, extracts archives in-memory, sets executable permissions on Unix, and emitsdeps://statusevents throughout.downloads.rs— spawns yt-dlp as a child process for each download. Streams stdout line by line to parse progress output, emitsdownload://progressevents in real time, emitsdownload://infoafter a pre-flight--dump-jsoncall, and emitsdownload://doneordownload://erroron completion.
React frontend
Located in
src/. Three layers:App.tsx— root shell. Manages the output directory state, callsget_default_output_diron mount, triggersensure_dependenciesif either tool is missing, and renders the three main UI sections.useDownloadQueuehook — the central state manager. Invokes all Tauri commands and subscribes to all Tauri events. Owns theitemsarray (the queue) and thedepsstatus object. All other components receive state and callbacks from this hook.- Components —
UrlFormcollects the URL, format, and quality from the user;QueueItemrenders a single download row with its progress bar, title, and action buttons;DependencyBannershows yt-dlp/ffmpeg setup status and a Retry button if setup failed.
IPC flow
The following trace shows the complete lifecycle of a single download, from the user clicking the Add button to the file appearing on disk:Tauri commands
All five commands are registered inlib.rs via tauri::generate_handler! and are callable from the frontend with invoke().
check_dependencies
Returns a
DependencyStatus object ({ ytDlpReady, ffmpegReady, downloading, message }) reflecting whether the yt-dlp and ffmpeg binaries currently exist on disk. This is a synchronous check — no network call is made. Called once on mount by useDownloadQueue.ensure_dependencies
Downloads any missing binaries. Emits
deps://status events during the process so the frontend can show progress. If both binaries are already present, it emits a single status event and returns immediately. This is the async command triggered by DependencyBanner and by App.tsx on startup.get_default_output_dir
Returns the system Downloads folder path (falling back to the home directory) as a string. Used by
App.tsx to pre-populate the output directory on first launch.start_download
Accepts
{ id, url, format, quality, outputDir }. Runs a pre-flight yt-dlp --dump-json call, then spawns the full download process. Registers the child process in the DownloadRegistry so it can be cancelled. Emits the full sequence of download:// events until the process exits.cancel_download
Accepts
{ id }. Looks up the child process in the DownloadRegistry by ID, calls kill() on it, and removes it from the registry. Once the command resolves, the frontend sets the item’s status to "cancelled".Event system
The Rust backend emits Tauri events that the frontend listens to vialisten(). All event payloads include the download id so the frontend can match events to the correct queue item. Full payload type definitions are covered in the Events reference.
| Event | Emitted by | Payload summary |
|---|---|---|
download://info | downloads.rs | { id, title, thumbnail } — video title and thumbnail URL, fetched before the download starts |
download://progress | downloads.rs | { id, progress, speed, eta, status } — numeric percent, speed string, ETA string, and a DownloadStatus string |
download://done | downloads.rs | { id, outputPath } — the output directory path when the download and any conversion are complete |
download://error | downloads.rs | { id, message } — the stderr output from yt-dlp when the process exits with a non-zero status |
deps://status | dependencies.rs | { ytDlpReady, ffmpegReady, downloading, message } — emitted at each stage of the yt-dlp/ffmpeg setup flow |
Tauri plugin permissions
Permissions are declared insrc-tauri/capabilities/default.json and apply to the main window. The app requests the minimum set of capabilities needed for its features:
| Permission | Why it is needed |
|---|---|
core:default | Base Tauri core permissions required by all apps |
dialog:allow-open | Powers the “Output folder” picker button — opens the native OS directory chooser |
fs:allow-read-file | Allows the frontend to read files via the fs plugin if needed |
fs:allow-write-file | Allows the frontend to write files via the fs plugin if needed |
fs:scope-download-recursive | Grants the fs plugin access to the system Downloads directory tree |
fs:scope-home-recursive | Grants the fs plugin access to the user’s home directory tree |
shell:allow-open | Allows QueueItem to open the output folder in the native file manager when a download finishes |
clipboard-manager:allow-read-text | Allows the app to read the clipboard so it can auto-populate the URL field when the user copies a link |
Download ID system
Each download is identified by a unique string ID generated entirely in the frontend before thestart_download command is called:
start_download and is echoed back verbatim in the payload of every download:// event. This allows the useDownloadQueue hook to map incoming events to the correct item in the items array without any additional coordination — the Rust backend treats the ID as an opaque string and never generates or modifies it.
The DownloadRegistry in downloads.rs uses this same ID as the key in its HashMap<String, Arc<Mutex<Child>>>, which is how cancel_download finds the right child process to kill.