Enlarge smaller images by default
AbandonedPublic

Authored by ngraham on Feb 27 2018, 5:19 PM.

Details

Reviewers
rkflx
Group Reviewers
Gwenview
Summary

This is a part of my "better defaults for KDE software" initiative.

Because Gwenview has the Enlarge Smaller Images setting off by default, two out of the three image zoom mode buttons appear to not do anything when you're looking at an image that's smaller than the viewing area. This causes user confusion and makes part of Gwenview seem broken, reducing confidence in the software.

It's true that turning on automatic image enlargement by default will make very small images like raster icons look bad in Fit and Fit Width mode when blown up to the full image viewing area size, but that's why there's a 100% button right next to them! I think we should trust the user here, rather than attempting to protect them from themselves and making two of the zoom modes appear randomly broken for certain images.

Besides, the type of people who typically look at a lot of tiny raster icons are usually software developers or other professionals who are generally more computer-literate than average.

Test Plan
  • rm ~/.config/gwenviewrc
  • Open Gwenview
  • Browse images both big and small
  • Click the Fit, Fit Width, and 100% buttons while looking at an image that's smaller than the image view area, and observe that they all actually do something

Diff Detail

Repository
R260 Gwenview
Branch
enlarge-smaller-images-by-default (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham requested review of this revision.Feb 27 2018, 5:19 PM
ngraham created this revision.
ngraham edited the summary of this revision. (Show Details)Feb 27 2018, 5:21 PM
rkflx added a comment.EditedFeb 27 2018, 5:25 PM

Haha, good for you, mentioning the raster icon case (otherwise I would've brought it up).

Let me think about it, so far at least I don't have strong feelings against it (and no pushing to the front of the review queue :D).

@muhlenpfordt The more opinions, the better.

I can't see any disadvantages for the normal photo browsing user so why not as default.
The users handling with small icons and don't like it should be able to find the off switch. ;)

rkflx added a comment.Feb 27 2018, 8:27 PM

I can't see any disadvantages for the normal photo browsing user so why not as default.

True, but there's also no advantage. The feature is only relevant for small images (i.e. most likely no photos), and that's what we have to carefully think about.

ngraham added a comment.EditedFeb 27 2018, 8:36 PM

Many photos are actually likely to benefit from this because they are slightly to moderately smaller then the viewing window. Here's a sampling of common sources/user scenarios:

  • Pictures downloaded from Facebook or Instagram
  • Pictures downloaded from email
  • Pictures downloaded from Google Image Search's results view (you should see my sister's collection of < 480p shoe and dress pictures)
  • Pictures downloaded from other random websites
  • Pictures already in users' libraries that are more than 15 years old, before high-resolution digital cameras were widely available

Here's a sampling of common sources/user scenarios:

Now we are making progress. We should apply this scenario / persona based analysis more often and more systematically, and ideally before submitting a patch…

Let me think about it, so far at least I don't have strong feelings against it

Hmh, changed my mind after trying it. I hate the in-your-face appearance of my test image (the purple question mark icon, as you may know by now ;). And I think I'm not alone with this, given how many bug reporters actually use Gwenview to view their icon sets.

What small images do we even talk about? On the one hand, those from your previous comment, where zoom-to-fit might make sense. On the other hand, mostly icons, perhaps some small screenshots (blurry otherwise) or diagrams, but those are all intended to be viewed at 100% zoom anyway, so it makes no sense to blow them up.

Let's step back for a moment.

two out of the three image zoom mode buttons appear to not do anything

That's the real problem, spot-on analysis.

However, the solution in this patch sounds wrong to me, because it solves a problem and creates another one. Can we get a solution which satisfies all use cases? You may have guessed it: Get rid of the checkbox… Only an idea, have not thought this through yet. The basic gist is this:

  • Image larger than screen area: Fit as before.
  • Image only slightly smaller than screen area: Fit and enlarge.
  • Tiny image: Show at 100%, do not enlarge. (We would have to come up with a good zoom factor limit. Tricky, but doable.)

That's for the default Autofit behaviour when navigating to an image. Once we leave that territory, i.e. the user chose another zoom button, it should just work as if the checkbox was enabled.

IOW, make Autofit more intelligent so we can get rid of the checkbox, which regardless of checked state only works for a subset of cases ever. As there still might be a scenario where users want the old behaviour (which I can understand), we might have to make this a OnAutoOff -type radiobutton. Or simply a more flexible but less approachable zoom factor limit spinbox?

Did I miss anything, were are flaws in this?


This is a part of my "better defaults for KDE software" initiative.

That's a great initiative, sorry to spoil the party again requesting a more extensive patch. Let's make this one part of the "Try hard not to regress" initiative too. :D

This is a tricky problem. I agree that the current behaviour needs improving, but I also agree with @rkflx that the proposed solution isn't the right one.

Here's a sampling of common sources/user scenarios:

In my opinion, when viewing slightly-smaller-than-viewport-sized images, enlarging to fit is undesirable, given that it instantly makes things blurry, even with a slight change.

two out of the three image zoom mode buttons appear to not do anything

That's the real problem, spot-on analysis.

Agreed, this is the real issue. Although I don't agree with the proposed solution of a 'smarter' autofit option either, for the reason stated above.

Here's another idea: we get rid of the checkbox in Settings, and place another button in the statusbar next to Fit/Fit Width/100%. These buttons would do the following:

Shrink Only - resize to fit only if image larger than viewport
Fit - always resize to fit the viewport
Fit Width - always resize to fit width to viewport
100% - always display at 100%

Shrink Only (or whatever name it has) would be the default. Perhaps this could also persist between images, rather than be a temporary change that is reset on changing to a different image.

This solves both problems - raster icons for example would be 100% by default, and all the buttons would work as expected all the time.

Thoughts?

Shrink Only - resize to fit only if image larger than viewport

That's a cool idea, but it also has problems:

  • Clicking on Shrink will do nothing once the image fits the viewport, while all other buttons will (in most cases anyway) result in an immediate action. I know it's now written on the button, but still…Thus we reintroduce parts of the problem (less grave than hidden in the config dialog, though).
  • 4 buttons to read/understand/choose from are not ideal from a usability perspective, 3 would be better.
  • ConfigureImage ViewZoom Mode is already complicated, Shrink should not introduce yet another persistence behaviour.
  • Deal-breaker: With the sidebar shown, for some languages we have a minimum width problem, see D8306.

Can we simply change the wording, placement and implementation of the checkbox in such a way it only affects zooming when you navigate to an image, i.e. when Autofit comes into play? Subsequent button presses could then perform their actions, unlike now. That way we would keep the current behaviour for initial viewing (which makes most sense to me), and solve the non-functioning buttons problem for zooming afterwards.

In addition, we could promote the checkbox to the View menu (better than nothing for Nate's Instagram pics, I guess).


  • Pictures already in users' libraries that are more than 15 years old, before high-resolution digital cameras were widely available

Really old pictures are hi-res scans, and those with let's say a 640x480px digital camera (could you even buy those?) who also use Gwenview and cannot find the checkbox are certainly not what we should optimize for.

Can we simply change the wording, placement and implementation of the checkbox in such a way it only affects zooming when you navigate to an image, i.e. when Autofit comes into play? Subsequent button presses could then perform their actions, unlike now. That way we would keep the current behaviour for initial viewing (which makes most sense to me), and solve the non-functioning buttons problem for zooming afterwards.

I like this idea. Apply the config option initially, then allow the user to override that by clicking the buttons.

We would need to ensure that the correct button is enabled/checked after that initial auto size decision.

Good discussion. Let me throw another idea into the fire: Get rid of the checkbox and default to automatically choosing the most appropriate mode for each image based on its size:

  • Larger than the viewport: Fit
  • Between 51 and 99% (negotiable) as large as the viewport: fit, and rely on the fact that Gwenview smooths out images up to 200% zoom level
  • Under 50% as large as the viewport: 100%

This would essentially be a behavior change for the default "Autofit each image" setting. In fact, I think Gwenview already selectively has this behavior; for example when I browse SVG icons, they're not blown up to fill the entire screen even with "enlarge images" checked. We could just extend this behavior to everything with a few tweaks, basically.

Thoughts?

huoni added a comment.Feb 28 2018, 2:03 AM

Good discussion. Let me throw another idea into the fire: Get rid of the checkbox and default to automatically choosing the most appropriate mode for each image based on its size:

  • Larger than the viewport: Fit
  • Between 51 and 99% (negotiable) as large as the viewport: fit, and rely on the fact that Gwenview smooths out images up to 200% zoom level
  • Under 50% as large as the viewport: 100%

    This would essentially be a behavior change for the default "Autofit each image" setting. In fact, I think Gwenview already selectively has this behavior; for example when I browse SVG icons, they're not blown up to fill the entire screen even with "enlarge images" checked. We could just extend this behavior to everything with a few tweaks, basically.

    Thoughts?

As a user, I'd like an option to have it always display 100% or shrink to fit (i.e. never enlarge to fit). I wouldn't want to keep clicking 100% for every image between 51% to 99% viewport size.
Perhaps that's an unusual opinion?

rkflx added a comment.Feb 28 2018, 7:51 PM

As a user, I'd like an option to have it always display 100% or shrink to fit (i.e. never enlarge to fit). I wouldn't want to keep clicking 100% for every image between 51% to 99% viewport size.
Perhaps that's an unusual opinion?

No it's not, I'm with you ;)

Good discussion. Let me throw another idea into the fire: Get rid of the checkbox and default to automatically choosing the most appropriate mode for each image based on its size:

That's exactly what I proposed in D10897#215325 (except that you want to prevent non-enlargement entirely), isn't it?

when I browse SVG icons, they're not blown up to fill the entire screen even with "enlarge images" checked.

That's Bug 364822, and I remember it very well, because apparently I solved it a while ago:

Date: Wed, 11 Oct 2017 00:16:29

I should clear out my patch queue one day ;) For a start, see D10926: Enlarge small SVGs too.

rkflx added a comment.Feb 28 2018, 7:53 PM

Let me summarize what we learned so far:

  • Agreement: Buttons should work after initial Autofit → needs patch
  • Disagreement: Removal of option to never enlarge → just keep it
  • Disagreement: Default behaviour of Autofit → needs more thinking

Regarding the last point, I looked at several other image viewers:

  • Linux: gThumb, Geeqie, Viewnior, showFoto, GNOME's eog, Pix, Nomacs, PhotoQt, Ristretto, qiv, LXImage, Ephoto, feh
  • Windows: Photos, Windows Photo Viewer, IrfanView
  • macOS: Preview

Only a single app enlarged the image by default (PhotoQt), and this was a pretty weird fullscreen app anyway. Sometimes being different might be beneficial, here I don't think it makes sense.

Are there many bug reports wanting this behaviour as a default? Not that I know of.

I acknowledge there are some use cases where enlarging without having to click might be beneficial. But as there are also other use cases where it is not, I'd advocate to not change this for now. Instead we could make it easier to reach the setting.

Better ideas for deducing what the user wants for a given image are welcomed ;)

Good summarizing!

But I don't understand how we can keep the config option, but change Autofit. Aren't they mutually exclusive?

Example:

Enlarge small imagesActual image sizeDisplayed image sizeButton states
OFFSmaller than viewport100%100% checked
OFFLarger than viewportShrink to viewportFit checked
ONSmaller than viewportEnlarge to viewportFit checked
ONLarger than viewportShrink to viewportFit checked

In all cases, it can be manually set by the user.

But I don't understand how we can keep the config option, but change Autofit. Aren't they mutually exclusive?

How do you define "change Autofit" here? Perhaps that might clear it up either for me or for you…

I don't want to alter its behaviour, but once we do, we'd indeed need something like the radiobuttons mentioned in D10897#215325.

But I don't understand how we can keep the config option, but change Autofit. Aren't they mutually exclusive?

How do you define "change Autofit" here? Perhaps that might clear it up either for me or for you…

I don't want to alter its behaviour, but once we do, we'd indeed need something like the radiobuttons mentioned in D10897#215325.

Well I was a bit wrong there.
But currently Autofit is only having an effect on larger-than-viewport images, where it automatically shrinks to fit. But the config option is taking away the automatic behaviour when it comes to smaller-than-viewport images.
Therefore if we keep the config option, I don't see any reason to change the current Autofit behaviour (I think we can all agree large images should be shrunk to fit). Unless I'm misunderstanding what Autofit is.

rkflx added a comment.EditedMar 1 2018, 12:23 AM

We are on the same page, I guess. In my book the current behaviour is fine, we should just fix the problem of the non-operational zoom buttons after Autofit already did its job. (And perhaps improve how the current options are presented in menu and config dialog.)

@ngraham As you started this, it might be time for you to comment, otherwise we'll get nowhere ;)

You guys have done a superb job of discussing the issue in depth, and I think I can agree with you that enlarging by default isn't an appropriate default. I realize that my true objections are as follows:

  • Two-thirds of the zoom mode buttons seem broken with the current default. I think that's the issue we need to fix.
  • It's too hard to figure out how to make images enlarge if you want that behavior

I think we should find a way to make the enlarge feature somehow accessible within the main window, rather than hidden away in the Configure window.

Here's another idea: perhaps the new Fill feature should always enlarge? After all, its name already implies that's what it'll do. It's pretty odd to view an icon, click on a button labeled Fill, and have nothing happen.

rkflx added a comment.Mar 1 2018, 11:04 PM

Here's another idea: perhaps the new Fill feature should always enlarge? After all, its name already implies that's what it'll do. It's pretty odd to view an icon, click on a button labeled Fill, and have nothing happen.

But isn't that exactly the same fix as this:

  • Two-thirds of the zoom mode buttons seem broken with the current default. I think that's the issue we need to fix.

As far as I understood the discussion so far, the Enlarge smaller images checkbox should be changed to only apply to the initial Autofit and not have any affect if you manually press on a zoom button. IOW users can check the checkbox if they want Autofit to automatically enlarge, and if unchecked they would have to manually click on Fit or Fill.


I think we should find a way to make the enlarge feature somehow accessible within the main window, rather than hidden away in the Configure window.

We don't have enough horizontal space to add another string to the statusbar. Either it will become an awkward arrow opening a one-item menu, or we add it to the regular menubar menu.

Regardless, I don't think you want to regularly change your preference for that feature (because then you could also directly use the zoom buttons). Either you like it, or not. It's a one-time choice. We should not spread the whole settings dialog over the main UI only because in some cases this might be useful.

ngraham added a comment.EditedMar 1 2018, 11:07 PM

As far as I understood the discussion so far, the Enlarge smaller images checkbox should be changed to only apply to the initial Autofit and not have any affect if you manually press on a zoom button. IOW users can check the checkbox if they want Autofit to automatically enlarge, and if unchecked they would have to manually click on Fit or Fill.

That makes sense to me. I can work on that, if there's consensus on the matter.

rkflx added a comment.Mar 1 2018, 11:12 PM

As long as you don't suggest to check the checkbox by default, I don't think anybody would be against this nice improvement ;)

huoni added a comment.Mar 1 2018, 11:35 PM

if there's consensus on the matter.

I think this is the best solution, so I say go ahead!

rkflx requested changes to this revision.Aug 25 2018, 6:41 AM
This revision now requires changes to proceed.Aug 25 2018, 6:41 AM
rkflx resigned from this revision.Aug 25 2018, 8:35 AM
ngraham abandoned this revision.May 14 2021, 2:48 PM

Not worth it.