-
Notifications
You must be signed in to change notification settings - Fork 368
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Entities can be dragged from the blueprint tree and streams tree to a…
…n existing view in the viewport (#8431) ### Related * Closes #8266 * Related to #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: ```rust //! ## 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 - [x] release checklist to check the above semantics https://github.com/user-attachments/assets/047c0d41-fead-424a-b673-b6cb1479d1fa
- Loading branch information
Showing
19 changed files
with
788 additions
and
299 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.