-
Notifications
You must be signed in to change notification settings - Fork 373
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
[pure refactor] move data ui to new re_data_ui
crate
#2048
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.
I'm not too happy about select_hovered_on_click
dissappearing and being spread around the code base. It's not the code duplication, it is the repeated logic that will make it more difficult to change what happens on cmd-click, shift-click, etc.
On another note: have you tried running cargo machete
to find unused dependencies?
// TODO(andreas): Move to its own crate? | ||
pub mod gpu_bridge; |
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.
the thought has occurred to me too - a re_renderer <-> re_log_types bridge crate.
did now and found a lil bit :) |
Introduces a new crate
re_data_ui
which depends onre_viewer_context
and is in turn used byre_viewer
.This didn't go nowhere nearly as smoothly as expected. I had to move more things into
re_viewer_context
for the time being than I wanted, but nothing too outrageous. It does makere_viewer_context
quite a lot bigger though than I wanted. The main issue was around supporting tensor ui inre_data_ui
- due to the way data ui is setup up, the orphan rule right now forces us to put all data ui intore_data_ui
.On the bright side, the things moved make the main viewer crate once more leaner, making it easier to move more.
Part of:
re_viewer
#1873What
Checklist
PR Build Summary: https://build.rerun.io/pr/2048