Conversation
TODO - figure out weird selection behaviour - `ui.interact()` kills ListItem over -> migrate to `ListItem` - clean logic code
TODO - `ui.interact()` kills ListItem over -> migrate to `ListItem` - clean logic code
emilk
left a comment
There was a problem hiding this comment.
We can now rebase on main with new egui behavior and features, including response.contains_pointer
| insert_y: f32, | ||
| /// Range of X coordinates for the cursor | ||
| range_x: egui::Rangef, |
There was a problem hiding this comment.
So this effectively forms a horizontal line - why not use a Rect here?
There was a problem hiding this comment.
Because a rect is one more parameter than I need, and is thus ambiguous?
Size changes
|
Well funnily I finally don't need it in this case. I'm never testing for an "entire" response rect, but rather up to 4 sub-rects. |
# Conflicts: # Cargo.lock
This PR adds the following APIs, which I found to be missing while working on rerun-io/rerun#4879: - `Response::decidedly_dragged()`: tests if the corresponding widget is being decidedly dragged - `Memory::dragged_id()`: returns the ID of the dragged widget, if any
emilk
left a comment
There was a problem hiding this comment.
Heroic work this! ⭐
For extra style points, I suggest storing the DropTarget and interpolating it when it changes, just like drop-targets in egui_tiles. This makes for a much smoother experience for the user. But it can wait for a later PR :)
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
and
I omitted those two things on purpose for two reasons:
If at all, I'm considering dragging a small "GH-label-like" blue bubble with the text "N items", as some added indication of what's being dragged, but that's for another PR (at least not until I do multi-selection dragging). |
I've moved the demo to the top of the right panel and separated it more clearly from the rest. |


What
This PR implements a couple of single-selection drag-and-drop demo with
ListItems inre_ui_example. One is flat, the other is hierarchical. Most of it happens inre_ui_example, with some minimal support for draggability inListItem. The goal is to identify proper patterns (and egui TODOs) for drag-and-drop support in the blueprint tree UI.TODO:
Response::contains_pointeremilk/egui#3859response.hoveredto false when dragging another widget emilk/egui#3860drag_and_drop_3.mp4
Contributes towards:
Checklist
mainbuild: app.rerun.ionightlybuild: app.rerun.io