Application managers
Source: src/app/application/managers
A manager is the small object that actually changes a session's long-lived resources: it opens a video, wakes or sleeps a decode thread, swaps a detection model, or starts a tracking thread. Services decide whether a use case should run; managers know how the session's resources are replaced safely. Read the whole stack for how requests reach this layer.
Where this sits
Arrows show a request travelling down the stack. Results travel back up as return values or Qt signals; managers never touch widgets.
Who owns what
The Application facade also talks to SessionManager directly (open, close,
active id). Every other manager is reached through a service.
| Manager | Owns or coordinates | Details |
|---|---|---|
SessionManager |
The dictionary of open Session objects and the active session id |
Sessions |
SessionInitializer |
One-time assembly of reader, state and decode worker for a new session | Sessions |
VideoDecodeWorkerManager |
Which session's decode thread is buffering frames | Sessions |
DetectionEngineManager |
The per-session detection engine (reuse, replace, remove) | Workers and engines |
TrackingWorkerManager |
Tracking worker start, stop and result reads; clears layers C and D | Workers and engines |
The managers hold no Qt widgets and no business rules about when to run; progress reporting and user dialogs belong to handlers and services.
Worked example: opening a video
Solid arrows are calls on the GUI thread; the decode worker runs on its own thread and only starts buffering once the session becomes active. The Sessions page explains each step. A second example, running tracking end to end, is on Workers and engines.
Threading at a glance
| Thread | What runs there |
|---|---|
| GUI thread | All manager calls, Session dictionary changes, active-session switching |
| Decode worker (one per session) | Frame decoding into a ring buffer; guarded by a Qt mutex |
| Tracking worker (one per run) | Association and post-processing on a private copy of the data |
The managers themselves use no locks: they assume they are called from the GUI thread. Thread safety lives inside the workers (see each page).
Limitations in current behaviour
- Manager calls are not synchronised; calling them from a worker thread is unsupported.
- Some cleanup paths do not notify other components. The details are on the Sessions and Workers and engines pages.
See also session infrastructure, detection services, and tracking services. API contracts are in the generated reference.