Improve Sense vs drag-and-drop

[emilk]

When dragging a widget (e.g. a slider), and letting the cursor move outside the slider, egui should not highlight that other widget:

egui implements this by never setting response.hovered for a widget if another widget is being dragged.

There is a weird exception to this though: if the other widget is not interactive (doesn't sense any clicks or drags), then it will still have response.hovered(). This usually doesn't matter, because a widget that that is not interactive has no hover-effect anyway.

This has implications for drag-and-drop: if the drop-target area has Sense::hover() then it will sense hovers while the user is dragging something else, so the user can do if drag_target_response.hovered() { … to highlight the drop-area. But if the drop-area itself is sensitive to clicks and drags, .hovered() will always be false while something is being dragged. This means it is really tricky to implement drag-and-drop reordering of a list, because usually you'd want to implement that by having each list item sense drags and be a drop-target, to sense how to reorder the items.

A work-around it to use ui.rect_contains_pointer instead of response.hovered(), but this feels hacky.

So: we should figure out:

• Should response.hovered() be true when something else is being dragged or not?
• Should we have a special drop-target Sense?

[rustbasic]

1. If the button is down somewhere else, shouldn't hovered be false?
2. There may be a way to create a function that stores and returns two separate hovered states.
   ex) hovered() and uncondition_hovered()

[abey79]

I have a list of custom widgets that I want to be able to reorder (for context, these widgets handle spacing themselves, so they are drawn with no margin/spacing between them). Here is the proto-code I need to use to have the ability to drag and drop. I think it's a good illustration of where the drag-and-drop API could be improved.

fn some_ui(ui: &mut egui::Ui) {
    let mut source_item_pos = None;
    let mut target_item_pos = None;

    for (i, widget) in list_items_to_display
    {
        let response = widget.show(ui);

        // TODO(emilk/egui#3841): very tempting to use `response.dragged()` here, but it
        // doesn't work. By the time `i.pointer.any_released()` is true, `response.dragged()`
        // is false. So both condition never happen at the same time.
        if ui.memory(|mem| mem.is_being_dragged(response.id)) {
            source_item_pos = Some(i);
        }

        // TODO(emilk/egui#3841): very tempting to use `response.hovered()` here, but widgets
        // that sense more than hover never get `response.hovered() == true` while another
        // widget is being dragged.
        if ui.memory(|mem| mem.is_anything_being_dragged())
            && ui.rect_contains_pointer(response.rect)
        {
            ui.painter().hline(
                ui.cursor().x_range(),
                ui.cursor().top(),
                (2.0, egui::Color32::WHITE),
            );

            // TODO(emilk/egui#3841): it would be nice to have a drag specific API for that,
            // for discoverability
            if ui.input(|i| i.pointer.any_released()) {
                target_item_pos = Some(i);
            }
        }
    }


    if let (Some(source), Some(target)) =
        (source_item_pos, target_item_pos)
    {
        /* swap `source` and `target` in `list_items_to_display` */
    }
}

[emilk]

I think rustbasic is on the right track.

We'll keep hovered to be false if dragging something else, and add a contains_pointer method that ignores what the mouse is doing, and just focus on where it is.

Btw, this also affects the drag-to-select text work in #3816