Replace and deprecate Image creating methods accepting Strings as file-system paths #1767
Conversation
Use File instead of the more modern java.nio.file.Path to avoid confusion with the Path class that already exists in the 'o.e.swt.graphics' package.
Test Results 488 files - 6 488 suites - 6 9m 9s ⏱️ +14s For more details on these failures and errors, see this check. Results for commit 0d6c6b0. ± Comparison against base commit 6d374d9. This pull request removes 56 tests. |
Furthermore with this the existing But with all the ongoing effort on improving high-DPI support I wonder if this should be part of a greater API rework? Not that I'm aware of one, but I would like to make sure that there aren't concurrent, maybe even conflicting efforts. |
I think this is a bad choice, as So adding any new API should also use new/modern/better types and it would allow to use alternative sources beside local files. |
There was a problem hiding this comment.
Yes, we plan to rework the Image class because of the HiDPI improvements. And actually, the proposed change is conflicting to what we need to do for that.
The reason is that we currently have a bunch of constructors that create "static" images. That means, these images are created once for a specific zoom value and can then only be rescaled to other zoom values via scaling the raster graphics (leading to blurry results). We are working on replacing all these "static" image initializations with "dynamic" ones, i.e., those that are able to create/render an image for whatever zoom is required (like already possible with ImageFileNameProvider/ImageDataProvider). That is the reason why we, for example, created a new constructor taking an "image drawer" that is capable of rendering an on-demand image in whatever zoom value is required as a replacement for just creating an image with fixed width/height and drawing into it: #1734
This is necessary as with the enhanced HiDPI support on Windows it must be possible to always retrieve an image according to the zoom of the monitor the containing shell is currently placed on. If you are interested, you find an analysis of static/dynamic image construction in our backlog: vi-eclipse/Eclipse-Platform#171 (comment)
I can have a further look at this PR and the neccessity of it to find a solution that is conforming with the enhanced HiDPI support. I just have to leave now for the rest of the day, so I at least wanted to give you the above comment to make you aware of that "conflict".
Using Strings to represent file-system paths is usually a bad idea since using String as type lacks context (String is almost like a primitive) and requires that callers handle OS-specific file-separators properly.
This PR proposes to provide alternatives for existing Image creating methods that accept Strings to represent file-system paths and to deprecate the existing methods, but not for removal since they probably have a huge user-base.
The type
Fileis used instead of the more modernjava.nio.file.Pathto avoid confusion with the Path class that already exists in the 'o.e.swt.graphics' package.There are multiple callers left that have to be adapted but I want to reach consensus about the new API first.