-
Notifications
You must be signed in to change notification settings - Fork 412
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
Use markdown for the view help widget #6878
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but let's be very explicit when a string contains markdown
/// Newtype over [`egui::PointerButton`] which provides a [`Display`] implementation suitable for | ||
/// markdown. | ||
pub struct MouseButtonMarkdown(pub egui::PointerButton); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Display
for markdown seems a bad path to go down.
There are many risk for subtle bugs when we put markdown in plain strings. We should either consider using a newtype (struct Markdown(pub String)
) or we need to be principled and be very explicit whenever we return markdown from a function.
In either case, I'd prefer calling .to_markdown()
to get markdown, rather than .to_string()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a concrete proposal for that?
In principle I agree, but in practice I'm unsure what exact steps to take here. One of my goal is to make help_markdown()
as easy to implement/maintain, such as it no longer rots like it has so far. Implementing Display
is part of that, it reduces the boilerplate in the format!
(which is already greater than I'd wish). Also, we are already pretty explicit, with the types implementing Display
having Markdown
in full in their name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't really notice how this was used, and now I agree it is pretty good (with the explicit naming). Nevermind me :)
crates/viewer/re_viewer_context/src/space_view/space_view_class_placeholder.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
### What - Part of #4466 - Soft-blocked by #6878 This adds support for visible time range to the dataframe. For now (likely to be iterated on soon), this mode is enabled when _any_ of the view entities have visible time range enabled (see note below). In that mode, rows are indexed by (entity, time, row_id) and can be sorted with either of the first two (asc or desc) using two new view properties. The dataframe feature is—and remains—behind an opt-in feature flag. #### Note on the current latest at vs. range switch Currently A single view entity with visible time range force the entire view into this mode. In particular, it force-opt-in *all* view entities to visible time range, setting it to `Rel(0)-Rel(0)` when not explicitly set. (It's as if the view's default visible time range switched to `Rel(0)-Rel(0)` although that's not how it's implemented.) This implicit behaviour is not ideal, and we probably should design a better way to go about it, see #4466. <img width="2004" alt="image" src="https://github.com/user-attachments/assets/025694b7-9029-4ab8-bdf4-6d9954a6792c"> ### Checklist * [x] update view help text * [x] split in multiple files * [x] clean Chunk stuff * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested the web demo (if applicable): * Using examples from latest `main` build: [rerun.io/viewer](https://rerun.io/viewer/pr/6869?manifest_url=https://app.rerun.io/version/main/examples_manifest.json) * Using full set of examples from `nightly` build: [rerun.io/viewer](https://rerun.io/viewer/pr/6869?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG * [x] If applicable, add a new check to the [release checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)! * [x] If have noted any breaking changes to the log API in `CHANGELOG.md` and the migration guide - [PR Build Summary](https://build.rerun.io/pr/6869) - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) To run all checks from `main`, comment on the PR with `@rerun-bot full-check`. --------- Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>
What
SpaceViewClass::help_text()
used to return aegui::WidgetText
, which are atrociously painful to create for rich-styled text. This PR changes it tohelp_markdown
and now return a markdown-formattedString
, which is way more convenient.I had to jump through some hoops to properly format egui buttons and modifiers. The resulting situation is not entirely extraordinary, but better than before IMO.
The legacy
LayoutJobBuider
is no longer used now and removed.before
after
Checklist
main
build: rerun.io/viewernightly
build: rerun.io/viewerCHANGELOG.md
and the migration guideTo run all checks from
main
, comment on the PR with@rerun-bot full-check
.