Entities can be dragged from the blueprint tree and streams tree to an existing view in the viewport

[abey79]

Related

• Closes Support dragging entities to existing view to add them to their filter #8266
• Related to Support dragging entities to the viewport to create new views #8267

What

This PR makes it possible to drag one or more entities from the blueprint and streams tree to existing views in the viewport. This involves introducing and/or adjusting a whole bunch of semantics around selection and dragging.

DragAndDropFeedback

This PR introduced the notion of drag-and-drop feedback from the hovered ui element.

Feedback may be either of:

• Ignore (default): hovered element is uninterested in the type of drag payload, or in any payload at all, or is outright oblivious to all that drag-and-drop stuff.
• Reject: hovered element is compatible with the type of drag payload, but not its actual content. For example, a view might already contains the dragged entities.
• Accept: hovered element is compatible with both the type and the content of the payload.

A drop should only ever happen in the latter case.

Payload visualisation

The payload pill display is now adjusted based on the feedback, both its opacity (ranging from 50 to 80%) and its colour (grey or blue). The mouse cursor is also adjusted based on the feedback.

Drop container visualisation

This PR slightly adjust the look of the drop container visualisation: the blue frame is now 2px wide.

Note that the drop container is not necessarily the thing that's hovered by the mouse, see e.g. containers in the blueprint.

Selection handling during drag-and-drop

This PR slightly alter the current behaviour. Now:

• dragging a selected item drags the entire selection
• dragging an unselected item with cmd held adds that item to the selection, and drags the entire selection
• dragging an unselected item drags that item, without changing the selection (new)

Entity-to-viewport-view drag semantics

This is the original goal of this PR.

• An existing view will accept a payload containing entities IFF any of these entities—or their children—is both visualisable and not already contained in that view.
• An existing view will reject a payload containing entities IFF all of these entities are either non-visualisable or already contained.
• An existing view will ignore a payload containing anything else.
• When a drop succeeds:
  • The view will add an inclusive ("…/**") rule for each of the dropped entities that are both visualisable and not already included.
  • The view becomes selected.

Emphasis on that last point. This subtle UX behaviour (courtesy of @gavrelina) makes the drop success and impact on the entity path filter more explicit.

Theory of operation for drag-and-drop

With this PR, a "framework" slowly starts to emerge. For now, it's mainly this bit of documentation:

//! ## Theory of operation
//!
//! ### Setup
//!
//! A [`DragAndDropManager`] should be created at the start of the frame and made available to the
//! entire UI code.
//!
//!
//! ### Initiating a drag
//!
//! Any UI representation of an [`crate::Item`] may initiate a drag.
//! [`crate::ViewerContext::handle_select_hover_drag_interactions`] will handle that automatically
//! when passed `true` for its `draggable` argument.
//!
//!
//! ### Reacting to a drag and accepting a drop
//!
//! This part of the process is more involved and typically includes the following steps:
//!
//! 1. When hovered, the receiving UI element should check for a compatible payload using
//!    [`egui::DragAndDrop::payload`] and matching one or more variants of the returned
//!    [`DragAndDropPayload`], if any.
//!
//! 2. If an acceptable payload type is being dragged, the UI element should provide appropriate
//!    visual feedback. This includes:
//!    - Calling [`DragAndDropManager::set_feedback`] with the appropriate feedback.
//!    - Drawing a frame around the target container with
//!      [`re_ui::DesignToken::drop_target_container_stroke`].
//!    - Optionally provide more feedback, e.g., where exactly the payload will be inserted within
//!      the container.
//!
//! 3. If the mouse is released (using [`egui::PointerState::any_released`]), the payload must be
//!    actually transferred to the container and [`egui::DragAndDrop::clear_payload`] must be
//!    called.

TODO

• release checklist to check the above semantics

entity_drag.mp4

[github-actions]

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

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	925f682	https://rerun.io/viewer/pr/8431	+nightly +main

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

[Wumpf]

love it!

[Wumpf]

a comment why these aren't filter_map would be nice. Iirc right from the demo session that was a conscious choice but code wide it looks a like bug codewise
(and I reckon that's also the reason this isn't implemented as a TryInto)

[abey79]

I used to have a TryInto for part of that iirc, but I find TryInto to denote a degree of generality that doesn't really apply. In the context of drag-and-drop (and its specific semantics), an ItemCollection may or may not be converted to a, e.g., Vec<EntityPath>. The conversion might be otherwise in other contexts, e.g. DataResult and Instance might actually be differentiated.

Now this is not a filter_map because it uses the collect transpose trick that implies the all semantics: it returns Some<Vec<_>> only if all items are Some<_>. I'll add a comment to that effect.