Fixed Shell::setBounds scaling

[amartya4256]

The previous scaling with the monitor context in Shell:setBounds would already scale the height and width of the Shell with respect to the monitor on which it is going to be placed. In case there is a monitor change, the monitor will be scaled with respect to the target monitor twice, i.e. in Shell::setBounds and then on the dpi changed message, leading to the effects, such as, shrinking or expanding shells on drag and drop to a different monitor with different zoom.

This PR contributes fixes that by scaling the x,y (top left coordinate) with the context of the whole rectangle but still using the zoom of the Shell for scaling the width and height. In case there's a monitor change the width and height will be scaled with respect to the target monitor on DPI_CHANGED event. Otherwise, the current zoom of the shell obtained from Shell::getZoom is enough for scaling the height and the width.

contributes to #62 and #127

[github-actions]

Test Results

   494 files  ±0     494 suites  ±0   9m 10s ⏱️ +24s
 4 325 tests ±0   4 307 ✅ ±0   18 💤 ±0  0 ❌ ±0 
16 532 runs  ±0  16 384 ✅ ±0  148 💤 ±0  0 ❌ ±0 

Results for commit 2dc97c5. ± Comparison against base commit 6e219e1.

♻️ This comment has been updated with latest results.

[HeikoKlare]

I have to admit that I do not fully understand the reasons for double-scaling. Can you post a call sequence that produces the problem?

It also seems weird to me that translateToDisplayCoordinates obviously produces a wrong result w.r.t to width and height. So it seems as if translateToDisplayCoordinates is behaving wrong. Doesn't that method take width and height into account to identify the correct monitor? Then if these values are wrong, that identification might not work properly. If these values are wrong anyway, why not call translateToDisplayCoordinates with only a point only containing x and y and just scale width/height independently? Then there wouldn't be a useless scaling of width/height and the risk of treating them in a wrong way.

[amartya4256]

@HeikoKlare I have updated the PR to scale only the top left point, which kind of goes in harmony with the implementation of setLocation. However, I have a few arguments to show why in case of Shell::setBounds and setLocation, it is crucial to scale the point with context to the whole rectangle. And i would like to open a separate issue for that to reevaluate. It is only needed for an edge case but using a rectangle for translating the topLeft point of the shell would make it less error prone. we can continue this discussion on a separate issue since this issue is irrelevant to the edge case it could be effective in.

[HeikoKlare]

I am still lacking an understanding of the underlying issue, as I don't know why it makes a difference that setBounds is called two times. Can you please describe a flow or, in the best case, an exact example flow with according values to understand what happens?
It currently looks to me as if the rectangle passed to getBounds does not have proper point coordinates in all cases or that translateToDisplayCoordinates does not behave correctly for rectangles. Just scaling the topleft point of the rectangle with that method obviously solves that, but still seems to only hide that the method is actually incorrect. This is also indicated by your statement:

However, I have a few arguments to show why in case of Shell::setBounds and setLocation, it is crucial to scale the point with context to the whole rectangle.

So I would appreciate if we can first get a better understanding of the issue before we can assess whether a solution is good/acceptable or not.

[HeikoKlare]

Closing as supceded by:

• Use monitor-aware coordinates in multi-zoom coordinate system #1711

If I am mistaken, please reopen or let me know @amartya4256

[amartya4256]

Closing as supceded by:

• Use monitor-aware coordinates in multi-zoom coordinate system #1711

If I am mistaken, please reopen or let me know @amartya4256

The behaviour still exists. The underlying problem of DPI_CHANGED event rescaling the shell size again is not fixed yet in #1711
I am working up a clearer solution which doesn't let the event override the shell size set by setBounds.