Use ListItem in blueprint tree UI

[abey79]

What

This PR back-ports ListItem into the blueprint tree UI. This includes multiple fixes and additions to ListItem itself.

Note that this PR strictly replicates the current behaviour, which has several issues:

• containers look inactive although they are active
• hidden elements look inactive although they are active
• cannot unhide one children of a hidden group
• hiding a container doesn't dim its children
• more generally, it would be nice to improve the visual distinction between containers, space views, data group and data item (i.e. if you know what a space view vs. data group is, you'll find them, but the tree UI does very little to actually teach that distinction)

Fixes:

• Use ListItem in Blueprint tree UI #3044
• Blueprint tree items with long names have broken hover buttons #2946
• Expand clickable area in blueprints list #2855

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[emilk]

There is some rather annoying flickering going on:

[abey79]

There is some rather annoying flickering going on:

I can reproduce on all 3 major browsers but not on native 🤔

Edit: nvm I can reproduce on native as well with a "slow" example (e.g. opf)

Edit2: egui::Response::highlight() is partly responsible here, inducing a frame lag. I made changes to override hovered state "immediately" instead for the blueprint tree.

[emilk]

I wonder if we can come up with a more elegant solution to this. It's not obvious how though.

The best I can come up with is this: produce the Id of the list item first, then call egui::Context::highlight_widget (if needed) before calling ListItem::new(…).id(id).

let list_item_id = ui.id().with(space_view.id);
if is_item_hovered {
    ui.ctx().highlight_widget(list_item_id);
}

let response = ListItem::new(ctx.re_ui, space_view.display_name.clone())
    .id(list_item_id)
    …

(…though this also requires a fix to egui to make highlight_widget take effect the same frame).

---

Alternative fix: add something to egui along the lines of ui.highlight_next_item(), but I don't really like that sort of statefullness (and it might accidentally affect only part of the next widget, e.g. the triangle).

[abey79]

I don't like this much either, but I'm in favour of punting on that.

My rationale is that piggy-backing on the hover state to show relations between disjoints UI elements related to the same "thing" is just wrong in the first place. With the new ListItem, it's visually too intrusive for my taste (I have that noted in #3120):

In the long run, we will instead need a new kind of dedicated highlighting, which will require adapting the Selection Panel UI as well. This new state will be unknown to egui, so it's probably not the right place to hack now.

[emilk]

Makes sense - though we could also make highlight something separate in egui from hovered. But I agree on the punt part