Allow drag-and-dropping multiple containers and views in the blueprint tree

[abey79]

Related

• Closes When dragging, display a pill with a summary of what's being dragged next to the cursor #8276
• Closes Support drag-and-drop for sensible multi-selections #8275
• Part of Support dragging entities to existing view to add them to their filter #8266
• Part of Support dragging entities to the viewport to create new views #8267
• Related to Trackig issue: drag-and-drop improvement #7108

What

This PR makes it possible to drag multi-selection of views and containers within the blueprint tree. It lays the foundation of a system that will be extended to other drag payload and UI sections.

Specifically:

• ctx.handle_select_hover_drag_interactions() (formerly ctx.select_hovered_on_click()) is now able to initiate drag interactions. This is opt-in for now, as dragging from most place isn't supported yet (to implemented in follow-up PRs).
• Introduce a new DragAndDropPayload type to interoperate between various part of the UI. This type also enforce the grouping of items that can meaningfully be dragged together (e.g. it's ok to drag a view and a container together, because there exist somewhere they can be dropped to, but it's not ok to drag a view and an entity together).
• When a drag is successfully initiated, a "pill" is displayed along the cursor which indicates the content of what's being dragged.
• Introduces a very hack mechanism for a black list of undraggable items (aka the root container).
• Update blueprint tree to support multiple selection and the new drag and drop payload type.
• Updates egui to latest master.

[github-actions]

Web viewer built successfully. If applicable, you should also test it:

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	245210a	https://rerun.io/viewer/pr/8334	+nightly +main

^{Note: This comment is updated whenever you push a commit.}

[nikolausWest]

I haven't been able to actually drop any dragged entities yet. Is that intended to work here or is it just dragging?

[abey79]

I haven't been able to actually drop any dragged entities yet. Is that intended to work here or is it just dragging?

Yeah this PR is just about views/container but lays the groundwork. Support for dragging entities will come next.

[nikolausWest]

Ignore for now if this is just super premature design feedback but I don't like the experience of showing an error all the time. If we want to show an error on the drag-pill it feels like that should be reserved for situations where I clearly want to drop it somewhere but that doesn't work.

drag-and-drop.mp4

[nikolausWest]

I expected the result of both these kinds of drags to have an effect:

no-ordering-effect.mp4

no-effect-2.mp4

[abey79]

I expected the result of both these kinds of drags to have an effect:

Yeah it broke it apparently. I'll fix it before this gets undrafted.

[emilk]

Code mostly LGTM, but I don't know when to pass true or false to handle_select_hover_drag_interactions. I would like to either have clear instructions, or better yet: have it be automatic (e.g. based on the items passed to it)

[emilk]

Instead of adding false and true as argument, did you consider having two different functions, for increased readability? In particular, it is very hard for me reviewing this code to know what false means.

I.e. you could have kept the old select_hovered_on_click with the previous meaning, and added handle_select_hover_drag_interactions (without a bool) for draggable things. But maybe its better to force each users to consider wether or not an item is draggable in this context?

[abey79]

Yes, I want people to think of draggability and make a call when using this function.

It's also a toggle that allows me to progressively implement draggability one UI area at a time (e.g. next PR will switch some items to true in the streams tree).

There is an ideal version of the future where this is true everywhere (and thus the arg can be removed), but I'm not sure this is realistic. There are cases where stuff should hover/select highlight, but not be draggable. For example, entity buttons should probably not be draggable—or at least not always (e.g. from the add/remove entity modal).

In generally, we should make something draggable only if it makes sense, e.g if there is an obvious drop destination.

I'll improve the docstring to expand on the above. Let me know if you have any further suggestion on this.

[emilk]

Code mostly LGTM, but I don't know when to pass true or false to handle_select_hover_drag_interactions. I would like to either have clear instructions, or better yet: have it be automatic (e.g. based on the items passed to it)

[emilk]

Sometimes when you drag things you get a pill, sometimes you don't

[abey79]

Sometimes when you drag things you get a pill, sometimes you don't

That's a design decision we made because the red pill was worse. The lack of pill is feedback that the current selection is not draggable.

As for this specific view: the next PR will enable dragging entities, so with it, every item in the blueprint tree will be individually draggable (or in homogenous multiple selection). This is not generally true however. For example, in the streams tree the entities will be draggable, but not the components.

[emilk]

Thanks for addressing the feedback!

[emilk]

You can at least document it here exactly what it is was introduced for, and maybe with a TODO for "this is ugly; if you have a better idea please rewrite this" :]