On Mon, 12 Aug 2024 12:14:26 GMT, Lukasz Kostyra <lkost...@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
