-
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
Use egui_kittest
for the graph view
#8578
Conversation
Co-authored-by: Andreas Reich <[email protected]>
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
@@ -15,18 +15,12 @@ | |||
* `graph` has directed edges, while `graph2` has undirected edges. | |||
* `graph` and `graph2` are shown in two different viewers. | |||
* There is a third viewer, `Both`, that shows both `graph` and `graph2` in the same viewer. | |||
* The `coincident` viewer shows two nodes, `A` and `B`, at the same position |
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.
less manual testing 🥳
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.
Yeah! For some reason, I still have some minor non-determinism in fjadra
so I can't really get rid of the remaining checks, but I'm looking into that separately.
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/12647844918 |
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/12648750684 |
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.
Great stuff! Of course, I wish more of the boilerplate could be more cleanly factored. I spent a bunch of time thinking about that, left some thoughts, but ultimately couldn't come up with much actionable suggestions.
We need to keep writing such tests and have a dedicated workshop at next meet-up with @Wumpf to see how we can better factor stuff.
impl Default for Timeline { | ||
fn default() -> Self { | ||
Self { | ||
name: TimelineName::default(), | ||
typ: TimeType::Sequence, | ||
} | ||
} | ||
} | ||
|
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.
what's the rational there?
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.
we tripped over default timelines being empty string and figured that this is practically never a valid timeline name (for all we know it is practically still valid, but even then we don't want to encourage it as the "default")
@@ -0,0 +1,252 @@ | |||
#![expect(clippy::unwrap_used)] |
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.
Side thought: wonder is there is a global way to do that for all tests?
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 this is a leftover from development. We have allow-unwrap-in-tests = true
in clippy.toml
.
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 tried to remove it, but either clippy
is not working nicely with the tests/
directory or it's not recognizing .unwrap()
in functions that are only used in test cases.
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.
It looks like this only works for functions annotated with #[test]
.
// It's important to first register the view class before adding any entities, | ||
// otherwise the `VisualizerEntitySubscriber` for our visualizers doesn't exist yet, | ||
// and thus will not find anything applicable to the visualizer. | ||
test_context | ||
.view_class_registry | ||
.add_class::<GraphView>() | ||
.unwrap(); |
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.
Moar side thoughts...
In a dream world, we would have some kind of builder pattern on TestContext
to provide visibility on the optional bells and whistles we might want to have:
let mut test_context = TextContextBuilder::new().with_class::<GraphView>().with_component_ui().build()
(see get_test_context()
in test_all_components_ui.rs
why I'd like with_component_ui()
)
However, this is not possible because TestContext
must live low in the hierarchy and all of that stuff is from crates higher up.
I wonder if there is a way to deal with that? (I'm probably trying to over engineer here though)
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.
we could provide extension traits to the test context for this :)
// TODO(andreas): can we use the `ViewProperty` utilities for this? | ||
let view_contents_chunk = | ||
Chunk::builder(format!("{}/ViewContents", view_id.as_entity_path()).into()) | ||
.with_archetype( | ||
RowId::new(), | ||
timepoint, | ||
&re_types::blueprint::archetypes::ViewContents::new(std::iter::once( | ||
re_types::datatypes::Utf8::from("/**"), | ||
)), | ||
) | ||
.build() | ||
.unwrap(); |
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 think you could use ViewBlueprint
here. It would be cleaner because that's the "official" API (no need to hard-code stuff such as "{}/ViewContents"
etc., but you'll need to use TestContext::run()
and TestContext::handle_system_commands()
.
let view_blueprint = ViewBlueprint::try_from_db( | ||
view_id, | ||
&test_context.blueprint_store, | ||
&test_context.blueprint_query, | ||
) |
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.
actually, do you really need that ViewBlueprint
to be stored in the blueprint store? Can't you just create one here with ViewBlueprint::new()
?
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.
you might be right but I'm not sure if there's not other things that depend on things being in the store. Populating the store correctly seems cleaner to me though (well okay ideally we use this as writing interface and process the system commands)
@@ -30,6 +31,9 @@ pub struct TestContext { | |||
pub selection_state: ApplicationSelectionState, | |||
pub recording_config: RecordingConfig, | |||
|
|||
// TODO(andreas): Can we just always populate this in `run`? |
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 sure we can, at least so long as we use view_blueprint.contents.execute_query()
to populate that thing.
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.
confirmed, right now we can't. Jochen and I actually spend quite a while trying to do this in here, but that dragged in too many dependencies
I expect to touch quite a bit of that boilerplate as part of the many-entities perf effort, so things will hopefully improve way before the meetup :) |
let view_blueprint = ViewBlueprint::try_from_db( | ||
view_id, | ||
&test_context.blueprint_store, | ||
&test_context.blueprint_query, | ||
) |
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.
you might be right but I'm not sure if there's not other things that depend on things being in the store. Populating the store correctly seems cleaner to me though (well okay ideally we use this as writing interface and process the system commands)
@@ -30,6 +31,9 @@ pub struct TestContext { | |||
pub selection_state: ApplicationSelectionState, | |||
pub recording_config: RecordingConfig, | |||
|
|||
// TODO(andreas): Can we just always populate this in `run`? |
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.
confirmed, right now we can't. Jochen and I actually spend quite a while trying to do this in here, but that dragged in too many dependencies
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/12650173463 |
Related
What
Title.
This might be a good starting point for other views wanting to adopt
egui_kittest
.Big shout out to @Wumpf how did all the query-crafting voodoo 🔮.