Skip to content

Application

Source: src/app/application

The Application layer decides what should happen when the user asks Blurzy to do something: run detection, track objects, save a project, export a video. The UI owns windows and dialogs; infrastructure owns models, video files, and threads; Application sits between them and turns requests into checked, ordered steps.

UI handlers call the Application facade, which delegates to services; services use managers and infrastructure workers and write session layers UI handlers call the Application facade, which delegates to services; services use managers and infrastructure workers and write session layers

Solid arrows are calls; dashed arrows are indirect or signal-based. Handlers call the facade, the facade delegates, and services use managers and infrastructure to do the work.

Part Role in one sentence Page
Facade (Application) One thin object the UI calls; it creates the services and forwards requests Services map
Services Validate a use case, sequence its steps, and write results into layers A-D Services
Managers Own long-lived per-session objects: engines, tracking worker, decode worker, session registry Managers
Adapters / interfaces Application-owned contracts plus factories that build concrete workers covered inside the pages above

Ownership boundaries

Application code never touches Qt widgets. Handlers own user-facing dialogs and connect most worker signals; services own validation, layer writes, and logging at the failure boundary. Workers do the slow work on background threads.

Not a strict dependency-inversion boundary

Services and managers import some concrete infrastructure classes (for example ProjectStore, and lazily the detection and tracking workers). Video rendering itself lives in the Application export service. The layout is a convention to follow, not an enforced Clean Architecture.

Who runs on which thread

GUI-thread handlers and services start background detection, tracking, and export workers, which report back by Qt signals GUI-thread handlers and services start background detection, tracking, and export workers, which report back by Qt signals

Solid arrows start work; dashed arrows are signals coming back. Detection batches return to DetectionService, while tracking completion and export progress are handled by UI handlers.

Thread-affinity limitation

DetectionService is a plain Python object (not a QObject), yet its batch slot's docstring says it runs on the main thread. Qt cannot use object thread affinity for such a receiver, so this guarantee is not established by the service code itself; treat it as unverified.

Layers A-D in the services

Detection writes A (detector output) and B (reviewed copy). Tracking reads A or B and writes C (machine tracks) and D (editable tracks). Export reads D, falling back to C. Services keep machine output and manual edits apart; see Detection and Tracking.

Pages

See also the architecture overview and the generated API reference.

API reference

Browse generated app.application API.