[Refactor] Moving methods from Win32DPIUtil to DPIUtil for autoscaling

[ShahzaibIbrahim]

Workbench needs few methods from DPIUtil that were only present for Win32. Keeping the functionality for Win32DPIUtil as is, just making them available for DPIUtil.

Also removing the test that test some numeric autoscale value with monitor-specific scaling which is now not allowed.

[github-actions]

Test Results

  118 files  ±0    118 suites  ±0   18m 40s ⏱️ +6s
4 649 tests  - 3  4 631 ✅  - 4  18 💤 +1  0 ❌ ±0 
  335 runs   - 3    331 ✅  - 3   4 💤 ±0  0 ❌ ±0 

Results for commit fadc48c. ± Comparison against base commit bcd5988.

This pull request removes 3 tests.

org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[6]
org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[7]
org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[8]

This pull request skips 1 test.

org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_setUrl_remote_with_post

♻️ This comment has been updated with latest results.

[HeikoKlare]

I would be in favor of doing such a change more incrementally. Obviously, there is code in Platform UI depending on (internal) methods of DPIUtil. Moving them to another class means that Platform UI code becomes incompatible once we merge the SWT PR and if we merge the Platform UI PR at the same time (without knowing if it works as the CI will fail) will make Platform UI builds fail until the next I-Build.

Thus, in such a case a multi-step transition should be made by refactoring and maybe adding methods while still keeping the old ones (as delegates), then adapt the consumers (such as Platform UI) and once that is done remove the delegates that became obsolete.

It also seems like the AutoScaling class and DPIUtil would be highly mutually dependent. This could be an indicator that splitting them up is not a good idea. In any case, AutoScaling seems like it disposes much new public API that we will tie ourselves to. I know that I proposed to make some its functionality API, but seeing it I am not so sure anymore whether we should really do it or better keep it internal (like with DPIUtil) and access the internal API from Platform UI for now. At least, whatever we make public should be as lean as possible and in my opinion we should definitely not make something like an autoscale mode publicly accessible.

[ShahzaibIbrahim]

As suggested, I have kept the methods in DPIUtil class. This PR now only moves few of the method in DPIUtil as these will be required to me in the workbench for subsequent PR: eclipse-platform/eclipse.platform.ui#3475.

The idea is to limit monitor specific for both SWT and eclipse products with compatible autoscaling methods.

[HeikoKlare]

Why not remove this method as it's now part of DPIUtil anyway?

[HeikoKlare]

This makes the proposed change not a refactoring but will actually further restrict the supported auto-scale modes. To keep this a refactoring that behavioral change should be reverted. The same is indicated by the need to modify a test.

[HeikoKlare]

@akurtakov this PR is not yet ready to be merged, but at least your specific request for changes was resolved, wasn't it?

My concern has been adressed.