Incorrect Zoom Level Applied When Dragging

[ShahzaibIbrahim]

When dragging and dropping a file from the Package Explorer or a field/method from the Outline view, the dragged item appears at an incorrect zoom level. Thats because the zoom for DragSource was not updated on zoom change and we use that zoom in DragListener to update the size of the imageList.

Reproduction
Steps to reproduce the behavior:

Scenario 1

1. Start the runtime workspace with 175% zoom on primary monitor.
2. Now change the display zoom from windows setting to 250%
3. Try to drag the class or method from package explorer as showed below
4. The dragged item looks bigger than the original one

20250519-0925-57.1484593.mp4

Scenario 2

1. Start the runtime workspace with 175% zoom on primary monitor.
2. Now move the window to secondary monitor with 150% Zoom
3. Try to drag the class or method from package explorer as showed below
4. The dragged item looks bigger than the original one

20250519-0927-30.9439028.mp4

Expected Behavior
The dragged item should be of the same size as it shows in the package explorer.

Necessary configuration:
Use these arguments before starting the runtime workspace:

-Dswt.autoScale=quarter
-Dswt.autoScale.updateOnRuntime=true

[github-actions]

Test Results

   545 files  + 6     545 suites  +6   34m 17s ⏱️ + 4m 6s
 4 398 tests +37   4 380 ✅ +35   18 💤 +3  0 ❌  - 1 
16 719 runs  +37  16 578 ✅ +35  141 💤 +3  0 ❌  - 1 

Results for commit e6db926. ± Comparison against base commit 925a294.

♻️ This comment has been updated with latest results.

[fedejeanne]

I'd put the code inside the controlListener, just like the other 2 handlers (SWT.Dispose and SWT.DragDetect) and I would also check for if (!DragSource.this.isDisposed()) seems it seems to be a possible source of problems.

Unrelated question: Is this also necessary for Linux / Mac? I ask because I see strong similarities in the 3 versions of the class DragSource. If you don't get to it first, I can check this when I'm home with my private laptops

[ShahzaibIbrahim]

I'd put the code inside the controlListener, just like the other 2 handlers (SWT.Dispose and SWT.DragDetect) and I would also check for if (!DragSource.this.isDisposed()) seems it seems to be a possible source of problems.

I agree with your suggestions and have made the required changes.

Unrelated question: Is this also necessary for Linux / Mac? I ask because I see strong similarities in the 3 versions of the class DragSource. If you don't get to it first, I can check this when I'm home with my private laptops

I am not sure about that and don't have mac/linux to test it.

[fedejeanne]

I'd put the code inside the controlListener, just like the other 2 handlers (SWT.Dispose and SWT.DragDetect) and I would also check for if (!DragSource.this.isDisposed()) seems it seems to be a possible source of problems.

I agree with your suggestions and have made the required changes.

👍
PR approved ✔️

I am not sure about that and don't have mac/linux to test it.

No problem. Can you please add a follow-up issue in our board so we can look into it later? I assume this is not an issue since Linux/Mac have had HiDPI support for a longer time and no one reported it. If no one gets to it before me, I can look into it when I come back from my vacation (M1 / M2).

[ShahzaibIbrahim]

No problem. Can you please add a follow-up issue in our board so we can look into it later? I assume this is not an issue since Linux/Mac have had HiDPI support for a longer time and no one reported it. If no one gets to it before me, I can look into it when I come back from my vacation (M1 / M2).

Sure, Here's the ticket: vi-eclipse/Eclipse-Platform#318