Also see D12509 for Gwenview effects on this issue.

In D12734#259336, @rkflx wrote:

+1, but I'd feel a bit uncomfortable (almost) self-approving my own patch (sans the qMax) here, so perhaps wait until the end of the week for any other opinions before committing.

I did nearly the same in my initial search, except for the separate extent var. So, two ideas leading to the same code can't be wrong. ;) But sure, I'll wait until next week.

BTW, any reason you are targetting master only?

I wanted to be careful here since I'm a bit afraid of changing library functions. If you think it's ok for Applications/18.04 I'll rebase it.

Forgot to mention this...
There's a nice test application in kio for viewing a folder's preview in any desired size (created by KIO::PreviewJob): previewtest. Just enter the full path to the folder here.

In D12734#259445, @muhlenpfordt wrote:

I wanted to be careful here since I'm a bit afraid of changing library functions. If you think it's ok for Applications/18.04 I'll rebase it.

How else would you fix problems in a library ;)

Nevertheless, let's check the impact of this again: https://lxr.kde.org/ident?_i=thumbForDirectory

Does not look too critical to me, and we probably tested most of the code paths.

In D12734#259515, @rkflx wrote:

Nevertheless, let's check the impact of this again: https://lxr.kde.org/ident?_i=thumbForDirectory
Does not look too critical to me, and we probably tested most of the code paths.

The normal KDE file dialog (e.g. Kate → File → Open...) also uses the upscaled preview without any problems.
I searched for (KIO::)filePreview on lxr which gives a couple of results. They all use similar methods to handle the icons and I can't spot anything unsual related to the returned size.
Ok to commit?

In D12734#262368, @muhlenpfordt wrote:

Ok to commit?

Sure, go ahead 👍