RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2]
Jose Pereda
jpereda at openjdk.org
Mon Aug 12 16:10:40 UTC 2024
On Mon, 12 Aug 2024 12:39:52 GMT, Jose Pereda <jpereda at openjdk.org> wrote:
>> Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned.
>>
>> I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)?
>
> Right, there is a built-in native animation from the offset point to the mouse cursor (in and out).
>
> When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds.
>
> And doing the same (clamping) for Windows would be a separate issue, indeed.
By the way, this is how you can disable the cancel animation:
diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
index 50a79cabf6..373537f24e 100644
--- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
+++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
@@ -40,6 +40,7 @@
- (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context
{
+ session.animatesToStartingPositionsOnCancelOrFail = NO;
// The Command key masks out every operation other than NSDragOperationGeneric. We want
// internal Move events to get through this filtering so we copy the Move bit into the
// Generic bit and treat Generic as a synonym for Move.
I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms).
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714046402
More information about the openjfx-dev
mailing list