-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
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
Fix drag notifications across windows. #71509
Conversation
6ad09ee
to
0d70640
Compare
This is an alternative approach to #67531. From what I can tell, this PR correctly solves a single problem (highlighting valid Drop locations of child Windows and SubViewports) of the many issues related to Drag and Drop with Windows and SubViewports, while the other PR intends to solve all of them. Since the other PR no longer makes use of Here is a MRP for stress-testing Drag and Drop with Windows and SubViewports BugDragNDrop.zip |
@Sauermann This fixes sub-viewports too |
0d70640
to
551d6b4
Compare
while (n) { | ||
Viewport *vp = Object::cast_to<Viewport>(n); | ||
if (vp) { | ||
base = this; |
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.
base = this; | |
base = vp; |
scene/main/viewport.cpp
Outdated
if (Object::cast_to<Viewport>(c)) { | ||
continue; | ||
Viewport *vp = Object::cast_to<Viewport>(c); | ||
if (vp != nullptr) { |
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.
Not an issue but do we try to be consistent with the checks style?:thinking: I mean I get there are different preferences but you're doing it both ways in this PR (if (vp)
and if (vp != nullptr)
) so that's kinda awkward. 😄
After investigating this topic more deeply, one problem area, that I was able to identify is, that the Viewport, that the mouse is over, is identified in the following code section: Lines 1830 to 1845 in 23e10d1
And this code section doesn't account for SubViewports and embedded Windows. My conclusion is, that in order to fix Drag and Drop for Viewports, it is necessary make this code-section aware of SubViewports and embedded Windows. This conclusion aligns with my tests of this PR with the previously linked MRP, which show that Drag and Drop with Viewports is not yet solved completely. |
551d6b4
to
d6a6876
Compare
Needs some consensus and conclusion. We can pick it for 4.0.x though, so bumping for now. |
Superseded by #67531. |
Fixes #44390.