Ok guys, thanks for the feedback! I'll get my hands on again.

Reverb and chorus would remain active and you would leak memory. For details, see the link I mentioned above.

You're right. Sorry. I had an orphaned fluidsynth install in /usr/local/ which caused the wrong .so to be used at runtime.

Exactly.

LGTM, thx!

Oh, good spot. I haven't considered malformed zero-size thumbnails, indeed.
In this case, you should also check for prevWidth > 0, otherwise scale
would become zero and we would have another div-by-zero.

I've tested it and it works fine for me, thanks. One minor issue is noted below.

Ok. I would like to test this, will need a few days though.

The same determination is done in LoadingDocumentImpl::init().

That looks better, thanks. Not sure if it's the best place for the connect, but I'll leave that to Nate.

make sure that an url passed on the command line is loaded and shown before the possibly long running dirlister

Don't worry, Nate will apply it.

And if updating the current index takes longer than 250 msec it would fail again, wouldn't it?

Oh, I didn't know about that, thx for the hint. Will see how it can be integrated.

Pls. note that the usage of CMAKE_CXX_STANDARD requires bumping cmake_minimum_required to 3.1.0 .

I vote against bumping Qt to 5.10 just because of a single obsolete method. Qt 5.9 is a LTS release, which is supported until May 2020. E.g. I'm using openSUSE Leap 15.1, which uses 5.9.7 . Also, QImage::sizeInBytes() is recommend for images bigger 2GiB, but I never had success to open images that big with Gwenview.

@ngraham ping

Added kconfig update script. Tested with make install and works as expected.

Need to postpone this until end of June.

Constness.

...also a blurred thumbnail suggests that the image is defocused.

Works for usual and panorama images, e.g.:

I haven't checked which folder Gwenview actually tries to delete, but the thumbnails are stored in ~/.cache/thumbnails instead of ~/.thumbnails.

You guys really have to setup clang-format or astyle to automate those whitespace formatting issues, IMO.

Fix unit test.

Sry, I missed that.

Sry, I should really enable Kate's spell checking.

@ngraham Missed?

@ngraham Missed?

Docs updated. Need to apply https://phabricator.kde.org/D21329 first, to avoid conflict.

I really can't get used to high quality thumbnails. The problem with your approach is that it puts (IMO unnecessary) load on memory bus and CPU: First we would crawl through all files in the directory to quickly display the embedded thumbnail and in a second run we open and decode picture by picture just for generating nice high quality thumbs. This reminds me of https://bugs.kde.org/show_bug.cgi?id=331435

I just followed the steps to repeat described in the bug, i.e. create an empty file: touch test.jpg

P.S.: The unit test fails expectedly. However, I'd first like to get some feedback before fixing it.

Attached is a screenshot demonstrating this suggestion. Even at 512px big thumbs, the embedded thumbnail (160x120) is big enough to get a rough idea of what's on the picture: A landscape, an animal, maybe which one? (not sure if you can tell the difference between a horse and a donkey, but IMO this isn't the purpose of a thumbnail preview anyway.)

Example Canon thumbnail attached:

Unit test fixed. Unfortunately I can't avoid QFile::readAll() entirely. When the same file is saved as the one already open through mem-mapping, we are in trouble when writing to that file: "It is unspecified whether modifications made to the file made after the mapping is created will be visible through the mapped memory." Apparently this might be the case and causes strange behavior when working with the input data later on. And I can't simply unmap the input data, as it may be needed for transformation. Thus postpone QFile::readAll() to JpegContent::save(). At least it speeds up the thumbnail generator.

Typo.

Use private mapping and handle nullptr.

Can you provide your full name and email address so we can land this patch with correct authorship information?

I actually don't have any RAW images I can use to test this.