RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the dragView image [v2]

Jose Pereda jpereda at openjdk.org
Mon Aug 12 12:42:38 UTC 2024


On Mon, 12 Aug 2024 12:14:26 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068:
>> 
>>> 1066: 
>>> 1067:                 dragPoint.x -= offset.x;
>>> 1068:                 dragPoint.y -= offset.y;
>> 
>> This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore:
>> 
>> - If you drag from {0,0} (top-left), it works from that position
>> - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected.
>> 
>> So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all).
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713684798


More information about the openjfx-dev mailing list