Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an experimental text-box component and logtype #2011

Merged
merged 16 commits into from May 10, 2023
Merged

Conversation

jleibs
Copy link
Member

@jleibs jleibs commented May 1, 2023

I wanted to just include some updating text as part of the view layout and realized that our "log-style" text entries weren't exactly what I wanted. Some of the naming here is probably worth discussing. In particular, how this should (or shouldn't) line up with the TextEntry logging APIs which serve a very different purpose with a very different view.

Seems like there could be some fun extensions on top of this to do HTML, Markdown, etc. for dynamically showing content along with the data. Seems particularly relevant with all the LLM / Prompt stuff going on these days.

Example of the motivating use-case:

typing-rerun.mp4

This feature is gated behind a new experimental module:

import rerun.experimental as rr_exp

rr_exp.log_text_box("my_text_box", "Hello world")

Checklist

PR Build Summary: https://build.rerun.io/pr/2011

@jleibs jleibs added 🐍 Python API Python logging API ui concerns graphical user interface labels May 1, 2023
@jleibs jleibs marked this pull request as ready for review May 1, 2023 00:54

#[derive(Debug, Clone)]
pub struct TextboxEntry {
pub body: String,
Copy link
Member

@emilk emilk May 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1887

Suggested change
pub body: String,
pub body: String, // TODO(#1887): avoid allocations

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, nice. That ticket also suggests:

We should also take the time to split TextEntry into two components: text and level.

Maybe we should just do that all now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like the new view this PR introduces should just be a different view of the same component. The TextLog view shows text over time, while the new TextBox view shows the latest text(s) at the given time. That would make the difference a difference in blueprint, not in data or component type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(If only we had a way to choose the view in the blueprint 😅)

Having a marker-component to hint at the right View and different APIs for logging still seems important for user discoverability and ergonomics. These are very different use-cases. Forcing blueprint-interactions to differentiate them doesn’t feel like a great experience.

@emilk
Copy link
Member

emilk commented May 2, 2023

Seems like there could be some fun extensions on top of this to do HTML, Markdown, etc.

A fun use-case for this feature: all our examples could log their own source-code so that when you view one of our examples, you have easy access to the source that created it. If we have a MIME component (or similar) then we could add syntax highlighting to the shown code.

@teh-cmc
Copy link
Member

teh-cmc commented May 4, 2023

Should we draft this as "blocked by #1887" then?

@emilk
Copy link
Member

emilk commented May 8, 2023

Let's put this behind some sort of experimental namespace and merge this

@jleibs jleibs changed the title Add a textbox component and logtype Add a text-box component and logtype May 9, 2023
#[serde(default)]
pub struct ViewTextBoxState {
monospace: bool,
word_wrap: bool,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it make more sense for word wrapping to be on by default?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a fair point. I guess I'm so used to text-editor contexts where I self-wrap that I forgot how bad an experience it is to have non-wrapped lines not end up wrapping.

@jleibs jleibs merged commit b850e8f into main May 10, 2023
15 checks passed
@jleibs jleibs deleted the jleibs/textbox branch May 10, 2023 18:24
jprochazk pushed a commit that referenced this pull request May 11, 2023
* New UI for displaying a textbox
* Add new TextBox component to simplify view-category creation
* Make module experimental
* Move to experimental designation
* Add experimental APIs to docs
* Python import cleanup
* Default word_wrap to true and set autoshrink to false for the scroll area
@emilk emilk changed the title Add a text-box component and logtype Add an experimental text-box component and logtype May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐍 Python API Python logging API ui concerns graphical user interface
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants