Text migration to archetypes

[teh-cmc]

Related:

• Don't deserialize utf8 data as native strings in Rust backend #2538

Overall:

(checked = merged or done in branch emilk/text-log)

• datatype Utf8
• component Text(Text)
• component TextLogLevel(Text)
• archetype TextDocument { body: Text }
• archetype TextLog { body: Text, level: TextLogLevel }
• Add TextLogLevel::INFO etc helpers for Rust, Python, C++
• Add back color support to TextLog ?
• Use component Text for rectangles, scalars, points etc
• Use archetype marker components in the viewer for understanding what is what
• Delete all the old component
• Replace "INFO" in Python with rr2.components.TextLogLevelType.INFO or whatever
• [z] Check that we have nice docs in all languages

• Python support
  • Extensions
  • Unit test (constructors, serialization)
  • Doc example
• Rust support
  • Extensions
  • Unit test (constructors, rust-to-rust roundtrip)
  • Doc example
• C++ support
  • Extensions
  • Unit test (constructors, serialization)
  • Doc example
• Cross-language roundtrip test
• Remove old components
  • Clean up re_components
  • Port viewer to use new types and queries

[emilk]

We use the strings in a few different parts of our API:

• Scrolling text logs: log_text_entry
• Text boxes: log_text_box (text in their own view, soon to support markdown)
• Labels: log_scalar, log_rect, log_points, …

What do these have in common, and how are they different?

Labels and text boxes might both want more sibling components like font size or mime type (markdown or not), but that does not make as much sense for the scrolling text logs.

The scrolling text log has a Level component (debug, info, warn, …) which currently is optional.

The question is how we should structure these into datatypes and components.

We want to reuse as much as possible, but still make it possible for the viewer to distinguish them from each other, so that we don't automatically create a scrolling text log for all labeled rectangles, for instance.

If we use the archetype marker components, we have no problems.

Proposal

EDIT: see PR description for an up-to-date TODO-list

• datatype String
• component Text(String)
• component LogLevel(String)
• archetype TextBox { Text }
• archetype TextLog { Text, LogLevel } with required level
• Use the Text component for rectangles, scalars, points etc
• Use archetype marker components in the viewer for understanding what is what

[nikolausWest]

So just to clarify, you're proposing to replace the Label component with the Text component?

[emilk]

Yes

[nikolausWest]

M 2 cents:

• This looks like a generally good approach to me
• I think we should find a better name than TextBox. The box part doesn't at all describe what it is. Perhaps something like TextPage, TextBlock, TextDocument?

[nikolausWest]

Related to Label -> Text, label does more clearly convey that it will be shown as a label on the data. Not a big deal to me though

[emilk]

We could use label: Text in the Points3D archetype, but we currently have an unwritten rule that the field names match the component names, and I think it is a pretty good rule to reduce confusion.

[teh-cmc]

We had these discussions during the API pain points session in Stockholm.
Here are the Notion notes for text-related stuff specifically:

TextEntry / TextBox

• Problems:
  • Semantic ambiguity with LogEntry given we have a “level” associated
  • Question: should the archetype be a batch archetype or not?
• Solutions:
  • 0.9: TextEntry should be batch
  • TextEntry → TextLog
    • body: [TextBody]
    • level: [TextLogLevel] ** Future: should all types have level?
  • TextDocument
    • body: TextBody
    • future: [TextFormat] (md, html, etc.)

---

I think we should find a better name than TextBox. The box part doesn't at all describe what it is. Perhaps something like TextPage, TextBlock, TextDocument?

We picked TextDocument during that session, which I like a lot (especially once we add a TextFormat { Markdown, Text, Pdf, .. } component to the archetype).

---

We could use label: Text in the Points3D archetype, but we currently have an unwritten rule that the field names match the component names, and I think it is a pretty good rule to reduce confusion.

IIRC we had this discussion too, and decided to keep Label separate. Text (or TextBody as we called it back then) should always be pairable with a TextFormat component, which doesn't make much sense in the context of a label.

---

component LogLevel(String)

We decided against calling it LogLevel and opted for TextLogLevel instead because of rr.log("xxx", rr.LogLevel()) -> this is extremely confusing, you're calling a log method with a LogLevel component and the two are in fact completely unrelated.

At some point we'd want to generalize the notion of log level to all archetypes, at which point a general LogLevel component would make sense.

[emilk]

RC we had this discussion too, and decided to keep Label separate. Text (or TextBody as we called it back then) should always be pairable with a TextFormat component, which doesn't make much sense in the context of a label.

Markdown for a label could make sense - why not support large labels at some point?

Markdown for text logs entries seems more exotic to me, but why not 🤷

[emilk]

I split out Scalar to its own issue:

• Scalar migration to archetypes #3174

[teh-cmc]

Markdown for a label could make sense - why not support large labels at some point?

Markdown for text logs entries seems more exotic to me, but why not 🤷

Eh. Yeah actually now that I think about it I guess they can both make sense!

[emilk]

I will go for a single Text component then.

Right now the datatype is also called Text. I find it kind of confusing to reuse the name like that (but I could see the argument for why it is less confusing then having two names).
I was considering calling it String, but that is quite confusing in Rust, where that name is already taken.
Calling the datatype Utf8 is another alternative.

[teh-cmc]

A Text component with a Utf8 datatype sounds good to me.