All UI containers should ideally define full span ranges themselves

[abey79]

Context

#6211 introduced a mechanism to save "full span ranges" on a scoped stack. These range define the total width of the container, excluding any margin, that should be used by "full span" widget, ie widget which draw highlighting and other decoration all the way to the container margin, potentially outside of ui.max_rect().

For some containers, such as side panels, it's easy to define the full_span_scope(). For others, it's tricker, e.g. popup menu (emilk/egui#4452). Work around exists but can be annoying. And then there is the case of hover tooltip.

Hover tooltips

Hover tooltips are created using egui::Response::on_hover_ui and related, which is all over the place in the code base. When delegating to e.g. DataUi, we're facing two solution, neither of which is agreeable:

• Every single call to on_hover_ui which may indirectly call into "full span" code (eg through DataUi) should wrap its content with full_span_scope. Error prone and verbose/repetitive.
• DataUi implementation, or indeed any ui code that may end up in a tooltip, should ensure they create a full_span_scope. In the case of DataUi, this means testing for verbosity == UiVerbosity::Reduced (which is problematic in itself, see Change UiVerbosity to UiLayout and tighten up related implementations #6245). In other case, it might be very tricky to even know if we're in a tooltip context.

This is further aggravated by the fact that it's actually hard to devise what the actual full span is (emilk/egui#4452), leading to bad UI such as this:

Solution

• Don't use full span widgets in popup/tooltip/etc..
  • Impossible, by definition of nice looking popup.
  • Even when theoretically possible, it would be very annoying to do so, eg. Use list_item2 for the component list in InstancePath::data_ui #6309 would need to introduce a different UI for UiLayout::Tooltip vs UiLayout::SelectionPanel*.
• Fallback to ui.clip_rect(). This is currently done in release mode (+ warning). In debug build, we debug_assert that a full-span scope is there when needed. We could remove these checks and warning and make the clip-rect fallback official.
  • This would require egui to always set the clip rectangle for its container, e.g. hover ui.
  • By "chance", this would fix the case of interactive(false) list items in hover ui. The clip rect is not set, but the use of it by list item (background -> not drawn when not interactive; interaction -> impossible by virtue of the hover tooltip being, by construction, impossible to interact with). Still not a great situation by any measure.
• Build the full-span mechanism right into egui (Sizing-pass flag emilk/egui#4535).

EDIT: we're going for the egui way:

• Sizing-pass flag emilk/egui#4535

Related

• Better tooltip size management emilk/egui#4471
• ListItem 2.0 (part 6): split full-span range management to a dedicated module #6211
• Remove ListItem clip-rect hack #5740
• Remove clip rect hack from every widget #6156
• Change UiVerbosity to UiLayout and tighten up related implementations #6245
• ComboBox menu doesn't report its actual size to its closure emilk/egui#4452

[emilk]

I created an egui issue to improve the sizing of tooltips:

• Better tooltip size management emilk/egui#4471

With that, I think this should be solvable in user space.