For example, there might be a tooltip on the left and a tooltip on the right on hover.
In order to support this, the API should be adjusted to expect the Tooltip component on children instead of on the parent. As a side effect, this will make rich text / fully custom tooltip support more natural; and it will allow the "hide animation" of a previous tooltip and the "show animation" of the next tooltip to overlap in time when switching between hovered nodes.
The "primary tooltip" theming feature could be replaced with a bundle? Like Tooltip::cursor("Hello").bundle(). Not clear how the user could provide their own primary tooltip this way, though.
If tooltips are children, it'll be important to make sure they're set to PositionType::Absolute during placement, and consider overflow clipping from the parent. Also it'll be important to ensure that the despawn/spawn trick that Blobo Party! does for the deck display doesn't regress to a 1-frame delay.
For example, there might be a tooltip on the left and a tooltip on the right on hover.
In order to support this, the API should be adjusted to expect the
Tooltipcomponent on children instead of on the parent. As a side effect, this will make rich text / fully custom tooltip support more natural; and it will allow the "hide animation" of a previous tooltip and the "show animation" of the next tooltip to overlap in time when switching between hovered nodes.The "primary tooltip" theming feature could be replaced with a bundle? Like
Tooltip::cursor("Hello").bundle(). Not clear how the user could provide their own primary tooltip this way, though.If tooltips are children, it'll be important to make sure they're set to
PositionType::Absoluteduring placement, and consider overflow clipping from the parent. Also it'll be important to ensure that the despawn/spawn trick that Blobo Party! does for the deck display doesn't regress to a 1-frame delay.