Drag & drop : Possibility to show all possible drop locations ? #9541

New issue

Open

opened 2026-09-10 14:18:35 +00:00 by olivier-gerard · 3 comments

olivier-gerard commented

2026-09-10 14:18:35 +00:00

(Migrated from github.com)

Version/Branch of Dear ImGui:

Version 1.92.9b, Branch: docking

Back-ends:

imgui_impl_GLFW.cpp + imgui_impl_Vulkan.cpp

Compiler, OS:

Windows 11 + MSVC 2022

Full config/build information:

No response

Details:

My Question:

How can I show all possible drop locations once a drag is started ?
I would like to display all the yellow rectangles (maybe dashed or with thiner borders) of widgets that would accept the current payload.

To give some context, in my application there are different drag sources, and each source has a few possible destinations.
In the drag tooltip I tell where the user can drop, but it would be much more intuitive if the destinations were visible

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

// Here's some code anyone can copy and paste to reproduce your issue
ImGui::Begin("Example Bug");
MoreCodeToExplainMyIssue();
ImGui::End();

### Version/Branch of Dear ImGui: Version 1.92.9b, Branch: docking ### Back-ends: imgui_impl_GLFW.cpp + imgui_impl_Vulkan.cpp ### Compiler, OS: Windows 11 + MSVC 2022 ### Full config/build information: _No response_ ### Details: **My Question:** How can I show all possible drop locations once a drag is started ? I would like to display all the yellow rectangles (maybe dashed or with thiner borders) of widgets that would accept the current payload. To give some context, in my application there are different drag sources, and each source has a few possible destinations. In the drag tooltip I tell where the user can drop, but it would be much more intuitive if the destinations were visible ### Screenshots/Video: _No response_ ### Minimal, Complete and Verifiable Example code: ```cpp // Here's some code anyone can copy and paste to reproduce your issue ImGui::Begin("Example Bug"); MoreCodeToExplainMyIssue(); ImGui::End(); ```

ocornut commented

2026-09-10 16:45:10 +00:00

(Migrated from github.com)

This would need a rework/redesign of BeginDragDropTarget() and AcceptDragDropPayload().

Would the DragDrop Source be responsible for requesting a preview rectangle on all targets, or you do envision this to be enabled for every drag and drop?
Do you envision it is ok to only display the review on visible items?

The "problem" is it means that all BeginDragDropTarget() -> AcceptDragDropPayload() blocks would run during the drag, so enabling per source / or source payload seems intuitively preferable. The new model would need careful design to be optimal, general approach being to always try order checks by ~((probability of early out) / (test cost))

Current implementation of BeginDragDropTarget() early out on 99% items with the hovered check.
With new model BeginDragDropTarget() would check that new state + item visibility, and therefore let most requests pass.
In that setup it seems like testing for payload type first and THEN hover/check geometry/store would be preferable, but a little more complex. We could defer some of that logic from BeginDragDropTarget() to the first passing AcceptDragDropPayload().

It would require a bit of work but is doable.

This would need a rework/redesign of `BeginDragDropTarget()` and `AcceptDragDropPayload()`. - Would the DragDrop Source be responsible for requesting a preview rectangle on all targets, or you do envision this to be enabled for every drag and drop? - Do you envision it is ok to only display the review on visible items? The "problem" is it means that all BeginDragDropTarget() -> AcceptDragDropPayload() blocks would run during the drag, so enabling per source / or source payload seems intuitively preferable. The new model would need careful design to be optimal, general approach being to always try order checks by ~((probability of early out) / (test cost)) - Current implementation of `BeginDragDropTarget()` early out on 99% items with the hovered check. - With new model `BeginDragDropTarget()` would check that new state + item visibility, and therefore let most requests pass. - In that setup it seems like testing for payload type first and THEN hover/check geometry/store would be preferable, but a little more complex. We could defer some of that logic from `BeginDragDropTarget()` to the first passing `AcceptDragDropPayload()`. It would require a bit of work but is doable.

ocornut commented

2026-09-10 16:45:10 +00:00

(Migrated from github.com)

This would need a rework/redesign of BeginDragDropTarget() and AcceptDragDropPayload().

Would the DragDrop Source be responsible for requesting a preview rectangle on all targets, or you do envision this to be enabled for every drag and drop?
Do you envision it is ok to only display the review on visible items?

Current implementation of BeginDragDropTarget() early out on 99% items with the hovered check.
With new model BeginDragDropTarget() would check that new state + item visibility, and therefore let most requests pass.
In that setup it seems like testing for payload type first and THEN hover/check geometry/store would be preferable, but a little more complex. We could defer some of that logic from BeginDragDropTarget() to the first passing AcceptDragDropPayload().

It would require a bit of work but is doable.

olivier-gerard commented

2026-09-11 07:10:36 +00:00

(Migrated from github.com)

Hi,
Thanks for your feedback

Yes I would add a flag like ImGuiDragDropFlags_SourceShowAllDropLocations to enable this, so the impact is opt-in.
I believe only visible items can be reached as drop source, so yes I would only highlight visible drop locations
Maybe payload comparison would be faster if payload was a number ?
I understand this is not trivial and with low priority, but I believe it is interesting for the user's experience
Btw today a disabled widget is a valid drop source, I'm not sure this is desirable ?

Hi, Thanks for your feedback - Yes I would add a flag like `ImGuiDragDropFlags_SourceShowAllDropLocations` to enable this, so the impact is opt-in. - I believe only visible items can be reached as drop source, so yes I would only highlight visible drop locations - Maybe payload comparison would be faster if payload was a number ? - I understand this is not trivial and with low priority, but I believe it is interesting for the user's experience - Btw today a disabled widget is a valid drop source, I'm not sure this is desirable ? <img width="318" height="321" alt="Image" src="https://github.com/user-attachments/assets/e6d9344e-15eb-4124-903e-ffebb193e2ba" />