- User Since
- May 12 2019, 5:07 PM (26 w, 1 d)
Fri, Nov 8
I've tested it and it works fine for me, thanks. One minor issue is noted below.
Mon, Nov 4
Ok. I would like to test this, will need a few days though.
Sat, Nov 2
The same determination is done in LoadingDocumentImpl::init().
Tue, Oct 29
That looks better, thanks. Not sure if it's the best place for the connect, but I'll leave that to Nate.
Mon, Oct 28
make sure that an url passed on the command line is loaded and shown before the possibly long running dirlister
Wed, Oct 23
Don't worry, Nate will apply it.
Mon, Oct 14
And if updating the current index takes longer than 250 msec it would fail again, wouldn't it?
Oct 12 2019
Oh, I didn't know about that, thx for the hint. Will see how it can be integrated.
Oct 9 2019
Sep 14 2019
Pls. note that the usage of CMAKE_CXX_STANDARD requires bumping cmake_minimum_required to 3.1.0 .
Jul 18 2019
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.
Jul 7 2019
Jun 28 2019
Jun 27 2019
Jun 23 2019
Added kconfig update script. Tested with make install and works as expected.
Jun 2 2019
Jun 1 2019
Need to postpone this until end of June.
May 25 2019
...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.
May 24 2019
You guys really have to setup clang-format or astyle to automate those whitespace formatting issues, IMO.
Fix unit test.
Sry, I missed that.
May 23 2019
Sry, I should really enable Kate's spell checking.
Docs updated. Need to apply https://phabricator.kde.org/D21329 first, to avoid conflict.
May 22 2019
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:
May 21 2019
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.
May 19 2019
Use private mapping and handle nullptr.
May 17 2019
May 14 2019
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.