Design a scalable approach to "viewer/blueprint commands"
Author: emilkCreated Jan 31, 2025Updated Sep 16, 2026
Labelsenhancement📺 re_viewer🔩 data modeldataplatform
EDIT: most of this issue has been subsumed by RR-5659
We have a desire to trigger certain actions from our SDK that affects the viewer directly:
- Activate blueprint $ID
- Open/close recording $ID
- Play/pause/move time cursor
- …
So far, only a few of these have been implemented, and in rather ad-hoc ways:
- https://github.com/rerun-io/rerun/pull/8809/files
- https://github.com/rerun-io/rerun/blob/026d84622c054de3159646667a9d35c90e361e9f/crates/store/re_protos/proto/rerun/v0/log_msg.proto#L16-L17
Where can we send these commands?
- From the logging SDKs (Python, Rust, C++)
- From Python notebooks (via logging SDK)
- From JS API ?
Blueprint changes
Some of these commands can be encoded as changes to the blueprint store. This include setting the time state, once this is part of the blueprint.
Changes to blueprint can be implemented as any other store changes, i.e. by pushing a chunk (recordbatch). Similarly, querying the blueprint state ("what is the time cursor at?") can be implemented as a data query.
Design
None yet, but it would be nice with something data driven, e.g. a protobuf definition of all commands as an oneof.
Related issues
Source: rerun-io/rerun