Visible time ranges are now specified per timeline, not per timeline type

[Wumpf]

What

Previously, visible time ranges was internally saved for the two types of timelines, time timelines and sequence timelines. This was done as a minimum-viable product since time values from different timelines aren't transferable. Now that we build user facing data structures it became clear that this is both limiting and strange to use.

The python blueprint api is still not final, but happens to look a lot better now:

rrb.Blueprint(
    rrb.TimeSeriesView(
        name="Classification",
        origin="/classification",
        time_ranges=rrb.VisibleTimeRange(
            "frame_nr",
            rr.TimeRange(
                start=rr.TimeRangeBoundary(rr.TimeRangeBoundaryKind.RelativeToTimeCursor, -10),
                end=rr.TimeRangeBoundary(rr.TimeRangeBoundaryKind.RelativeToTimeCursor, 10),
            ),
        ),
    )
).connect("rerun_example_plot")

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[github-actions]

Deployed docs

Commit	Link
e21c508	https://landing-z6xqnwpjz-rerun.vercel.app/docs

[jleibs]

Tracking per timeline is a huge improvement.

The API itself still seems very verbose to me. I think something that ended up looking like:

time_range=rrb.VisibleTimeRange(
  "frame_nr",
  start=rr.TimeRangeBoundary.CursorRelative(-10),
  end=rr.TimeRangeBoundary.CursorRelative(10)
)

would be quite a bit more usable. I would recommend ditching the intermediate TimeRange datatype between VisibleTimeRange and TimeRangeBoundary.

[jleibs]

The type-nesting here doesn't seem to add much value/clarity to the user-facing API relative to inlining start/end directly. Just creates more typing and rightward drift.

[Wumpf]

I do use this intermediate type internally though where its quite useful. It's easy to eliminate from Python via custom constructors but will ofc haunt us in C++ and Rust then

[Wumpf]

also to be fair it makes it easy to use the same time range on several timelines because then you can just reuse that range value with several strings

[Wumpf]

decided to keep the TimeRange type - if it is constructable from tuples and arrays it's fine I think. The advantage of being able to pass it in for several timelines and the uses internally are too big to ignore imho

[emilk]

Could you please add a code-example to the PR description showing how you would specify time ranges for multiple timelines? 🙏

[Wumpf]

no point in it since I still want to significantly change what it looks like. I'm working on doing that and providing examples