Drag and Drop Region moves with a different scale as compared to the cursor between 2 monitors

[amartya4256]

Configuration for reproducing:

1. Right (Primary) - 150%
2. Left - 100%

Steps to reproduce:

• Keep your IDE on the primary monitor.
• Drag an editor across the monitors.
• The drag and drop rectangle moves away from the cursor.

Expected behaviour: The Drag and Drop region should always have its top left corner around the cursor.

TO-DO

• Propose solutions (requires a bit of extra analysis)

[amartya4256]

Background:

• We use MultiZoomCoordinateSystemMapper for multi zoom setup
• The drag and drop event retrieves the bounds of the control and sets the drag and drop region's bounds to the controls bounds
• Then it changes the x, y of the region's bounds to current cursor location which is obtained from Display::getCursorLocation which returns a ZoomAwarePoint value.

Findings:

• The obtained values are used to create a new rectangle where the zoom context is lost.
• The zoomless rectangle is used to set bounds
• It calls for a translate to pixels from point using MultiZoomCoordinateMapper::translateRectangleInPointsToPixels.
• since we don't have the monitor info here, it calls getValidMonitorIfApplicable.
• There we run in the fallback which finds a suitable monitor using the greedy algorithm which chooses the monitor with most proportion in the monitor if the bounds where scaled to that monitor's zoom.
• Now this works perfectly where there are gaps between monitors in point values, but in this specific case where the left monitor is 100% and right is 150%. 3/4th of the length of the monitors have no gap between them where the algorithm ends up choosing monitor with 150% zoom since because of no zoom, scaling the monitor by 150% would have the most proportion in it.
• while if the curosor is in the lower 1/4th proportion of the monitor, since in the points setup, 150% monitor is not present there, the algorithm can tell that it 100% monitor and there are no buggy behaviour there.

Based on these findings we have to decide what we want to do with it. As far as I have checked, there are two options:

• In our previous discussions we decided that the clients need to adapt to use the obtained points and rectangle and they should not directly create a new object using the values or make direct chnage to it but rather using methods. In this case, we can adapt DnDManager client so that it contains the zoom context of the cursor in the bounds when it calls Shell::setBounds

• Making the method getContainingMonitorForPoints better so that it can find the monitor where there is no gap available. This is rather harder because we don't know which monitor's context to take as we don't have the previous information about where the point is being moved from.

I'd keep this issue in blocked until we have made a decission about it.

[HeikoKlare]

Next step: make a proposal for how to proceed