-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single-selection drag-and-drop demos #4879
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this effectively forms a horizontal line - why not use a Rect here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
ListItem
s 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_pointer
emilk/egui#3859response.hovered
to false when dragging another widget emilk/egui#3860drag_and_drop_3.mp4
Contributes towards:
Checklist
main
build: app.rerun.ionightly
build: app.rerun.io