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

First draft of generic UI for space view properties #6237

Open
abey79 opened this issue May 6, 2024 · 0 comments
Open

First draft of generic UI for space view properties #6237

abey79 opened this issue May 6, 2024 · 0 comments
Assignees
Labels
ui concerns graphical user interface

Comments

@abey79
Copy link
Contributor

abey79 commented May 6, 2024

The goal is to introduce a new section in the space view/data result selection panel with a list-item-based UI for all properties. The idea is to prototype/lay the ground work for a fully generic poperty-to-list-time infrastructure to replace the current bespoke UI code.

This first take will likely be highly experimental, so behind a debug-only feature flag.

Mid-term Vision

  • For "simple" property (e.g. that map to a single value, e.g. a bool), the corresponding non, hierarchical top-level list item should be generically implemented
  • For "composite" properties made of multiple "simple" component, a hierarchy of a top-level item with sub-items for each components should be generically implemented
  • For very complex properties (e.g. maybe Visible Time Range), a child UI would be manually implemented. This could be done either with sub-list-items, or with a complete bespoke UI code. Both would appear below a top-level list item with summary, in a way that would be consistent with all properties.

Initial take

Build semi-generic (if at all) code for (at least part of) existing properties, in a dedicated section behind a feature flag. The existing UI would remain as is for as long as needed.

@abey79 abey79 added the ui concerns graphical user interface label May 6, 2024
@abey79 abey79 self-assigned this May 6, 2024
Wumpf added a commit that referenced this issue May 22, 2024
…gend` (#6400)

### What

* Part of #6237 

What's happening:
* edit uis for:
   * corner2d
   * visible
* introduce generic method for drawing ui for a view property

Next steps in this area:
* improve edit ui overall
    * make it easier to implement (with less boilerplate)
* make default providing easier & more powerful (as described in passing
there)
* do this for more/all properties

### 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/6400?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/6400?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/6400)
- [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 22, 2024
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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui concerns graphical user interface
Projects
None yet
Development

No branches or pull requests

2 participants