Ping.

There are a lot of Bugzilla tickets complaining about the modal dialog; it's not just that one dude on Reddit. It bothers me too. It's a weird, nonstandard UI; I have a hard time imagining there are lots of people who actually like it. IMHO a persistent setting to control wrap makes much more sense than asking every single time; either you're the kind of person who likes wrap, or you're not. You're not likely to change your mind about wrap preference every single time it could be invoked. And this also fixes the legit bug of left and right arrow keys not invoking wrap/potentially wrap behavior.

I could get behind making it always wrap and removing the option, as long as we're okay with getting user complaints from the minority who hate wrap. But anything it better than the weird nagging dialog we have right now that seems to satisfy nobody.

First things first: → and ↓ not behaving like Space when reaching the end in Slideshow mode (!) is a bug, no question about that. Could you split this out in a second patch?

Next, a general remark: Let's only look at the fullscreen Slideshow mode for the moment, as there all navigation relies on the keyboard and we have no UI to give any context or we only have a minimal top bar.

About the HUD: Yes, it has issues, e.g. keyboard navigation, multi-overlay-darkening, available options, and those should be fixed (complete removal is throwing the baby out with the bathwater, though). Nevertheless, the HUD also:

• Shows when you reached the end. This is an important navigation feature, because without it you either think your computer crashed (→ stopped working with no-wrap mode), or you'll completely lose orientation (an endless list of images with wrap mode).
• Gives a hint how to leave fullscreen mode again (Go back to the document list → Exit Fullscreen). Remember, some users will never get that they can move the mouse to the top or use the context menu (even with many hints and explanations, trust me on that…), they rely on the button appearing at some point.

Then, I read through all material and made some observations, which for me are not as clear and single-sided as this patch tries to put them. In addition, there are probably a lot of non-vocal and happy users, we should not stab them in the back:

• Some users want to go to the first and last picture. This is easily achieved by Home and End, which itself is directly discoverable via the Go menu.
• Some users want settings for a looping slideshow. We already have those, adding wrapping options next to that needs to be done carefully to not cause confusion.
• Some users complain about the "unergonomic" and "annoying" HUD and don't have a strong opinion on wrapping at all.
• Some users want wrapping, but they are not able to give any compelling use case for this. They state "would be nice" (why?) and "I am of the personal opinion" (why?). And indeed, why should navigation loop around (apart from the automatic slideshow). Please provide use cases why this must absolutely be achieved by the normal method for forward navigation. I'm seriously interested, so I can weigh them against the disadvantages.
• Some users do not want wrapping, as arguments they state "rarely want it to happen" (because they are done), "I would like to stop" (not interested in going to the start by accident, passive notification not enough), "want to get notified" (that they reached the last image) and cite use cases like "similar looking scientific charts". I find this logical.
• The duplicate bugs are mainly about the HUD itself, not about wrapping. Wrapping is only mentioned in the final bug's comments. Reducing the duplicates only to wrap vs. no wrap misses the point.
• Some users are not in Gwenview's target user group and just have not found their Qt-based image viewer yet, i.e. behaving like their favourite Gtk example they cite. Gwenview is not the only Qt-based image viewer, there are many more less known and using them is fine.
• Aurélien has done a lot for KDE's usability in general and Gwenview in particular, which is obvious when you compare Gwenview to other Linux image viewers. Did you know he is the author of KMessageWidget, replacing a lot of those pesky modal dialogs? Please trust him a bit when he concludes that wrapping around per default is not a good fit (for Gwenview at least). Of course not everything is perfect and some things should be fixed, but KDE's apps will never reach any quality if we keep reverting the same thing back and forth over the years depending on who is around. Let's respect decisions and build on top instead of changing direction over and over again without getting anywhere.

After this, I looked at other image viewers:

• Testing 14 different viewers on Linux, some wrap and some do not wrap. I never noticed a config option. No HUDs, but image counters.
• Short sampling on Android: no wrap. No HUDs, but glowing effect once reached the end.
• Windows (Photos) and macOS (Preview): no wrap.

Here is my suggestion. I am aware this is asking for more work, but sometimes this is necessary to cause a positive change instead of only a neutral change (i.e. fixing some things while breaking others, which would counter any of our quality efforts):

• Improve the HUD or replace it with something similar. Requirements: no layer bugs, proper keyboard navigation, sensible options (e.g. Leave Fullscreen Mode, Go Back to the Document List, Cancel), no countdown timer (only puts pressure on the user, making him feel uneasy).
• Having the HUD means not wrapping by default.
• Optional (I don't like it, but won't block it either): config option for wrapping (implying no HUD for Slideshow mode)

This way, we make everybody happy and stand out from the rest (config option), while still having superior usability by default (HUD). Note this can be done in multiple patches, and the last point is similar to the current patch (sans killing the HUD).

Now for the windowed Browse and View modes: Here the HUD is not really needed, because

• You see you've reached the end (disabled Next button, Thumbnail bar state) and other windows are not frozen. We could add an image counter to the status bar (Bug 203042), though.
• No need to exit Fullscreen, the toolbar is visible, too.
• Matches other apps like LibreOffice Impress, e.g. the infamous white "Click to exit presentation" on a black background is shown in fullscreen mode, but not when navigating in windowed mode.

Still, to respect Fitts's law, which is often brought as an argument in favour of the global menu on Macs, no-wrap is preferable (you could think of the start and end as the "screen edges" of the keyboard forward/backward navigation). Again, like in every other app (Firefox showing your tab's content again underneath itself when scrolling to the end would be pretty weird). Therefore my suggestion:

• HUD only for Slideshow mode, aka the fullscreen View mode.
• No wrapping by default in View mode and both Browse modes.
• Optional: config option for wrapping (the one from above, actually)

Thoughts?

Sorry for the late reply. The essay was a bit intimidating. :)

I wasn't intending to fix the arrow keys not triggering the HUD/maybe-wrap behavior when I set out to make this patch, but it happened by accident as of the consequence of the way I changed the code. If we take a different approach here that doesn't automatically fix that issue, I can look into splitting that out into a different patch.

I do see your point that the Slideshow is potentially a different use case from the Browse and View modes. I could live with using the HUD for the slideshow and adding an option to control the behavior via an option, but I must say that I still don't see the utility of the HUD even in Slideshow mode. As you mention, no other app has this UI. It's a really weird, nonstandard UI convention whose uniqueness seems to make it jarring and annoying rather than useful.

Like you I generally frown on adding more options, but in this case I think it's warranted for two reasons:

• It's a polarizing feature; I don't think we can satisfy everybody with a single behavior here
• Gwenview's General page is actually IMHO lacking enough options; the lack of options on that page in particular create a visual issue given the space available. Far from overloading the page, adding another option or two would actually visually balance it better.

In D9039#176862, @ngraham wrote:

Sorry for the late reply. The essay was a bit intimidating. :)

Yeah, sorry this came out so long, but sometimes doing UX design work involves careful consideration of a lot of things. At least now you know my thought process :D

I wasn't intending to fix the arrow keys not triggering the HUD/maybe-wrap behavior when I set out to make this patch, but it happened by accident as of the consequence of the way I changed the code. If we take a different approach here that doesn't automatically fix that issue, I can look into splitting that out into a different patch.

So 387380 is not a bug, but a feature of your code? Just kidding… Let's see how this pans out, I agree on how you imagine it should work.

I do see your point that the Slideshow is potentially a different use case from the Browse and View modes. I could live with using the HUD for the slideshow and adding an option to control the behavior via an option, but I must say that I still don't see the utility of the HUD even in Slideshow mode. As you mention, no other app has this UI. It's a really weird, nonstandard UI convention whose uniqueness seems to make it jarring and annoying rather than useful.

I have not particular feelings about the HUD itself, but about the role it serves in the overall UX (that's why I wrote so much…):

In D9039#174263, @rkflx wrote:

Nevertheless, the HUD also:

• Shows when you reached the end. This is an important navigation feature, because without it you either think your computer crashed (→ stopped working with no-wrap mode), or you'll completely lose orientation (an endless list of images with wrap mode).
• Gives a hint how to leave fullscreen mode again (Go back to the document list → Exit Fullscreen). Remember, some users will never get that they can move the mouse to the top or use the context menu (even with many hints and explanations, trust me on that…), they rely on the button appearing at some point.

Note the first point is achieved e.g. on Android by a glowing animation. Interestingly, I recently noticed the same thing when scrolling to the end in a PDF in Evince, I guess this sort of pattern is quite common in GNOME now.

Improve the HUD or replace it with something similar.

If we can find another way to preserve these functions, the HUD could go. What about showing the top fullscreen toolbar when reaching either beginning or end? Currently it is only shown when moving the mouse to the top.

In D9039#176862, @ngraham wrote:

Like you I generally frown on adding more options, but in this case I think it's warranted for two reasons:

• It's a polarizing feature; I don't think we can satisfy everybody with a single behavior here
• Gwenview's General page is actually IMHO lacking enough options; the lack of options on that page in particular create a visual issue given the space available. Far from overloading the page, adding another option or two would actually visually balance it better.

Adding features because the existing config options are feeling lonely is not really a valid reason, you know that ;) Please note that adding features and options is not only a "spaceship cockpit UI" issue, but even more importantly concerns the ever-increasing maintenance burden (more things to test, more code complexity, inevitably more bugs).

I already said I would accept having the option, so just go for it already. If it breaks in some years, you'd have to fix it, though. However, given my analysis from above it should be pretty obvious that wrapping cannot become the default option.

Does this sound like a plan?