I’ve been using the preview feature in the Files app a lot, but I’m missing the ability to zoom in on images with the pinch touch gesture like you can in the regular Image Viewer app. It would be really useful for tall images so you can zoom in and pan/scroll around (or click and drag), or for really low res images to make them bigger on the screen. For desktop when you don’t have a trackpad, maybe keyboard shortcuts could be used or the scroll wheel as an alternative?
Hi, I don’t see how zooming into images really is the business of a previewer app, at that point it’s just an image viewer.
It’s so you can have a more efficient workflow and avoid using two separate applications every time you preview an image that can’t be viewed clearly without zooming. Like images containing text as an example. You can already scale the preview window, so why not also allow scaling of the image too?
I don’t really get your last point. Yes, it does have the capability of viewing images, so it’s essentially an image viewer already. However, it also differs in the way it integrates into the file browser and with how it can follow the focused file across different windows and it supports more file types apart from just images.
My point was that it’s not an image viewer. It’s a previewer, which has a big overlap with an image viewer, but it’s not the same. It purposefully limits it’s features, because adding them is a slippery slope. Think “why can i zoom into images, but not pdf documents?” or “i want to rotate/crop an image”.
Maybe with it being presented in a separate window, it feels less like a preview and like it should be capable of more. If it would be differently integrated into Files, the previewing nature would be more obvious IMO.
Why should we restrict the potential of the previewer though? If a feature is useful and improves productivity, I think it’s worth considering. If it’s implemented well, a zoom feature wouldn’t interfere with existing workflows, and could even be completely unobtrusive to users who doesn’t want to use zoom.
And I don’t agree with your reasoning of a “slippery slope”. Someone still has to implement any new features before they get added, and it won’t just happen on its own without discussion first. While zooming into images or even PDFs makes sense, maybe also rotating, editing and cropping should not happen inside the same window. At that point it falls out of scope for just previewing, and opening a separate window makes more sense. However, my feature request only covered zooming into images. The addition of one feature can be done without opening the floodgates for every other feature useless feature that are outside the scope of the previewer.
I also don’t think the design of the previewer window itself is the problem. I feel like you’re drawing a hard line against any expanding of features to the previewer. Aside from “it’s a slippery slope” or your circular reasoning of “a previewer must be limited in features because it’s a previewer”, is there a specific reason you feel so strongly against having zooming inside previewer?
It’s not circular reasoning, it’s about scope definition. If previewer scope is restricted to glance-able identification of files, then zooming it out of scope.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.