[FEAT] Usability enhancements

[bananakid]

Is your feature request related to a problem? Please describe.
There're quite a few small annoyances when QuickView is being hevily used. I decided to combine them into a single feature request.

Describe the solution you'd like

1. Please add Undo Delete action and hotkey (i.e. Shift+Del) for the last file deleted using QuickView (for instance, qView allows such action).

2. Please add an option to never show file delete confirmation dialog or a hotkey (i.e. Ctrl+Del) to delete without confirmation (or both options).

3. The feature request of configurable zoom levels explained in Zoom Settings #132 (comment) was accepted, but never saw a light of day. I'd like to add that there's also another good reasoning behind this request: zooming at integer values will help when comparing images (while 1% step provided in UI is handy, clicking many times to get to specific % may be tideous). Original feature request:

@justnullname, would you also kindly consider an option for using strictly incremental zoom levels that are specified by user? In example, user can set zoom levels to be only 25%, 50%, 100%, 200% and so on, and when zoom via scroll wheel of mouse happens, it switches only between the set zoom levels (and maybe freely if you hold Alt/Ctrl key). This is very handy for specific tasks and will benefit users of HiDPI screens. Award-winning nomacs allows this and it's about the only viewer that does.

4. Please consider adding a View → Fill Window option so there's a quick way to zoom image to fill window with image without changing window size and also without zooming to 100% or using mouse scroll to zoom in manually. Most of image viewers allow this, qView.

5. Please consider adding an option to make Loupe circle instead of square, and also adjust it's size.

6. Please consider adding a hotkey to invoke file info panel in collapsed state. At the moment "i" always opens a full file info panel which isn't always desirable.

7. Please consider adding a file position and total number of files in current folder reading (format 33/999) & zoom level to compact file info panel, and also consider adding file position and total number of files in current folder (format 33/999) reading to full file info panel.

8. If point number 7 is accepted, please also refactor compact info panel format to this: 75% · 64/192 · Image.png · 640×480 · 256 KB · [Wuffs PNG 8-bit Alpha] (preferable) or 64/192 · Image.png · 640×480@75% · 256 KB · [Wuffs PNG 8-bit Alpha]. Such small change will make panel easier to read as small bullit symbol provides just enough spearation and isn't "in your face". Specifically, this will improve a situation when the file name is long and has a lot of spaces.

9. If point number 8 is accepted, please also refactor compare compact info panel format to this (for the same reason as point number 8) for both compared images: Image.png · 640×480 · 256 MB · S:999 · E:6.66 · 5.55bpp · 2020-01-01 12:00:00

10. Please consider using × instead of x for image resolution in all panels, i.e. display 1024×768 instead of 1024x768. This is a small imperfection, but details like this make software look more professional.

11. Please make it possible so the file info panel (compact & full) stays open and moves down when gallery filmstrip view is toggled. This will allow to check file properties quickly when switching between files from pinned gallery filmstrip view.

12. Please make window controls widget avaliable when gallery filmstrip view is pinned, because currently you have to first unpin the gallery filmstrip view to access window controls. Preferably, window controls should appear below gallery filmstrip view in the top right corner of image viewport.

13. Please add delete file action to thumbnail context menu in folder thumbnail view and gallery filmstrip view.

14. Please consider adding an option to set thumbnail size in folder thumbnail view using settings (or make a slider widget in the bottom middle of folder thumbnail view, which will allow to set thumbnail size in pixels).

15. Move both entries (default editor and system integration) in Settings → Image → System to Settings → Advanced → System. Image section is long enough already and operating system-related settings should be in one place (in Advanced section) so they're easier to find.

Additional context
Thank you for your attention to this matter!

[justnullname]

Hello, thank you for your suggestions.
There are a few details we need to discuss:

4. Please consider adding a View → Fill Window option so there's a quick way to zoom image to fill window with image without changing window size and also without zooming to 100% or using mouse scroll to zoom in manually. Most of image viewers allow this, qView.
Could you elaborate on the "fill window" feature you mentioned? My understanding is that in "lock window" mode, the width or height adapts to the window size. Is that correct?

5. Please consider adding an option to make Loupe circle instead of square, and also adjust it's size.
Do you think a circular Loupe has any specific advantages? I feel that a circle might cause some issues or misunderstandings at the corners. Although we could find a workaround for that, are there any other considerations for this besides visual preference?

6. Please consider adding a hotkey to invoke file info panel in collapsed state. At the moment "i" always opens a full file info panel which isn't always desirable.
This feature already exists. You can press the Tab key to bring up the info panel lite.

14. Please consider adding an option to set thumbnail size in folder thumbnail view into settings (or make a slider widget in the bottom middle of folder thumbnail view, which will allow to set thumbnail size in pixels).
Currently in the Gallery, you can adjust the thumbnail size using Ctrl + Mouse Wheel, which is consistent with the Windows File Explorer experience.
Actually, what we lack the most is a way to let users know about these hidden operations. I am conceptualizing an interactive guide/tutorial interface (though future changes would make it troublesome to maintain, and supporting multiple languages might take up too much file size), or perhaps maintaining a GitHub Wiki page to serve as a help and getting-started guide.

[bananakid]

Could you elaborate on the "fill window" feature you mentioned? My understanding is that in "lock window" mode, the width or height adapts to the window size. Is that correct?

Lock window feature does indeed work as intended (however I've added point 15 to initial feature request regarding improving it further). What I mean in point 4 is better illustrate using screen capture of qView:

qView

Capture.mp4

Do you think a circular Loupe has any specific advantages? I feel that a circle might cause some issues or misunderstandings at the corners. Although we could find a workaround for that, are there any other considerations for this besides visual preference?

Not exactly a matter of preferense per se, as many professional image editing tools share this approach, when something loupe-related is done. In example, Affinity Suite programs (merged to Affinity by Canva recently) use circular loupe when you're sampling colors. IIRC, Mac OS X (macOS) has circular loupe in default Preview app and Apple's discontinued professional Aperture app since forver (Crapple has a reputation of "photographer's computers maker", so they did their research). All I know from my experience is that it's really much more convinient to navigate with such loupe because it's shape conradicts square and you suddenly "see more". It looks like this is a best practice, otherwise why everyone does it. I did comparison with current implementation.

Affinity Designer 2

Preview

2011, one circle loupe — http://www.macosxtips.co.uk/index_files/preview-lion-magnifier.png

2018—2026, now two circle loupes that can be used simultaneously — https://images.macrumors.com/t/QdJxhk-CAAX1tBOuZcMiJt0D9kM=/1600x0/article-new/2018/10/how-to-use-the-preview-loupe-tool-800x565.jpg

This feature already exists. You can press the Tab key to bring up the info panel lite.

Thank you for bringing this up to my attention, I only checked settings, but forgot to double-check hotkeys.

Currently in the Gallery, you can adjust the thumbnail size using Ctrl + Mouse Wheel, which is consistent with the Windows File Explorer experience.

I agree, but my point was there's no way to configure and "bind" the thumbnail size — it's always random size calculated from current window size. In example, I'ld like my thumbnails always be 96×96 px, when I hit T hotkey to bring up thumbnail folder view. But if my window size is large when I hit T, then the thumbnails are too large and I have to scroll to display more thumbnails (and also quality of large thumbnails is noticeably low, because it looks like thumbnails are calculated in single size). There's a thin line between a bug and feature request here and I decided to file a feature request so one can actually set preferred "default" thumbnail size in settings and then use scroll wheen when it's necessary (but scroll-zooming thumbnails size won't get carried over to a new QuickView session upon relaunch).

Actually, what we lack the most is a way to let users know about these hidden operations. I am conceptualizing an interactive guide/tutorial interface (though future changes would make it troublesome to maintain, and supporting multiple languages might take up too much file size), or perhaps maintaining a GitHub Wiki page to serve as a help and getting-started guide.

Please dont take me harsh, but I have to disagree that implementing a built-in system is reasonable at this point, because this will bloat the executable (it's already close to 10 MB) and will take tremendous amount of time to implement and maintain. And we need a state-of-the-art viewer yesterday, or you haven't started this project otherwise. Als, QuickView clearly aimed towards computer geeks, and messing with software is their second nature, they will find a way or open an issue here at GitHub as the last resort. It appears to me, that maintaining GitHub Wiki page will be sufficient, once all the glitches are ironed out, UI is polished and core feature set is complete. It's getting there, but QuickView still needs some love first.

P.S. I've added point #15 into the first message.