eclipse-platform
Store nativeDeviceZoom in widgets instead of zoom for win32
Issue: #62 and #127
This contribution is to provide the nativeDeviceZoom to all the widgets so that it can be used later on for e.g. font scaling and more. Currently, the nativeDeviceZoom is only available via the shell, which is not sufficient later when there is no shell available, e.g. GC.
In this following PR https://github.com/eclipse-platform/eclipse.platform.swt/pull/1214 , we had discussed that instead of storing zoom for widgets, we should store nativeDeviceZoom, to make it more accessible where shell is not present. Because in some cases, there was no nativeDeviceZoom present because of the previous implementation and we discussed if a fallback might be necessary. This implementation makes sure that in those scenarios, nativeDeviceZoom would always be available for further usage.
The consumers can now have deviceZoom wherever necessary by using the utility method to translate nativeDeviceZoom to deviceZoom, which is available in DPIUtil.
Test Results
418 files ±0 418 suites ±0 11m 6s :stopwatch: + 3m 2s 4 121 tests ±0 4 113 :white_check_mark: ±0 8 :zzz: ±0 0 :x: ±0 16 313 runs ±0 16 221 :white_check_mark: ±0 92 :zzz: ±0 0 :x: ±0
Results for commit c44e211b. ± Comparison against base commit 2a1030fd.
:recycle: This comment has been updated with latest results.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@amartya4256 I don't see my previous comment (https://github.com/eclipse-platform/eclipse.platform.swt/pull/1229#discussion_r1611590128) addressed yet. Could you please check before I re-review the PR?
Thank you for addressing my previous comment @amartya4256 , I just have one final change request to improve readability. After that, this PR is good to go from my side.
@fedejeanne can you approve the changes? :)
The changes are basically a refactoring, which we have reviewed at code level. Still, I have now also done a final manual validation. To this end, I have started an Eclipse SDK with different primary monitor scaling values (100%, 150%, 200%), opened different views, editors and dialogs, and compared the results of the state before this PR and after this PR side-by-side. As expected, they were exactly the same in all cases.