DragAndDropContainer: Document support for dragging between windows - #1692
Open
owenpkent wants to merge 1 commit into
Open
DragAndDropContainer: Document support for dragging between windows#1692owenpkent wants to merge 1 commit into
owenpkent wants to merge 1 commit into
Conversation
owenpkent
force-pushed
the
docs/dragdrop-cross-window
branch
from
August 2, 2026 18:57
8bed101 to
63f280b
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a paragraph to the
DragAndDropContainerclass documentation noting that a drag can be dropped onto targets in the application's other windows, and pointing at theallowDraggingToOtherJuceWindowsparameter ofstartDragging().Documentation only. No functional change.
Why
The class comment currently describes a drag as being delivered to "any child components derived from DragAndDropTarget which the mouse moves over", which reads as though a drop is confined to the container's own window. Cross-window support does exist, but it is reachable only through the fourth positional parameter of
startDragging(), it defaults tofalse, and it is documented solely in that parameter's own@paramentry.Someone reading the class documentation to find out whether JUCE can do this comes away believing it cannot.
As evidence that this is a real failure mode rather than a hypothetical one: I hand-rolled cross-window dragging across roughly 180 lines and five files in Keys, a VST3 plugin that drags chords from a detached window onto a pad strip in the main editor. I had concluded from this class comment that the framework did not support it. Three separate comments in that codebase state it as settled fact:
All three are wrong. The hand-rolled version locates its target with
juce::Desktop::findComponentAt()followed by a walk up the parent chain, which is close to exactly whatfindDesktopComponentBelow()andfindTarget()already do. Had the class comment mentioned the capability, none of it would have been written.The implementation has supported this for a long time:
startDragging()puts the drag image on the desktop when the flag is set, which makesgetParentComponent()null infindTarget()and routes target lookup throughfindDesktopComponentBelow(), iterating every desktop component in z-order before walking up the parent chain for an interestedDragAndDropTarget.The added paragraph goes in the class comment so the capability is visible to someone deciding whether the class fits their problem, rather than only to someone who has already chosen it and is reading the parameter list.