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

Support per-space-view-class property defaults #4194

Closed
abey79 opened this issue Nov 10, 2023 · 2 comments
Closed

Support per-space-view-class property defaults #4194

abey79 opened this issue Nov 10, 2023 · 2 comments
Assignees
Labels
🟦 blueprint The data that defines our UI

Comments

@abey79
Copy link
Member

abey79 commented Nov 10, 2023

#4179 highlighted the need for specific default for, in this instance, visible history properties in timeseries space view. This might be a recurring pattern, so a proper mechanism for this should be devised for this (e.g. SpaceViewClass should have chance to set default values).

@Wumpf
Copy link
Member

Wumpf commented May 22, 2024

There could be the concept of a default provider that given component name tries to give you a default value or none.
This default provider would be implemented by either Visualizer or SpaceView. EditUi can take in a generic default provider then to determine defaults when needed.

Related to:

Wumpf added a commit that referenced this issue May 23, 2024
…se it in blueprint property ui (#6413)

### What

* Part of  #6237
* I think the "only" part left now is to use this for all blueprint
properties
       *  the tricky bit here is that this is dependent on  #4194

This creates an tight nit & generic coupling from our type definitions
to the ui! This is to be used in all blueprint properties, so far used
on `PlotLegend` only.
<img width="320" alt="image"
src="https://github.com/rerun-io/rerun/assets/1220815/405b6ecc-2db1-4ad5-9b3c-aad96c8ad074">

Drawbacks:
* lower snake case because that's what our fields look like - we could
change that easily but there's some value to that because that's what
all SDKs use as field names. Very much open for discussion!
* some parts of the doc strings might be weird outside of the context of
the ui, but I can live with that

Future stuff:
* we could very very easily now also add reference doc links in there
via some linking mechanism (viewer could choose depending on preference
or source sdk)

### Checklist
* [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/6413?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/6413?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)!

- [PR Build Summary](https://build.rerun.io/pr/6413)
- [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`.
@Wumpf Wumpf self-assigned this May 28, 2024
@Wumpf
Copy link
Member

Wumpf commented Jun 4, 2024

@Wumpf Wumpf closed this as completed Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🟦 blueprint The data that defines our UI
Projects
None yet
Development

No branches or pull requests

2 participants