Mon, Jun 10
Sun, Jun 9
Honestly i'd prefer if we wait for 5.10 and then use QMetaObject::invokeMethod instead of QTimer::singleShot.
Mon, Jun 3
Sun, Jun 2
Sat, Jun 1
Need to postpone this until end of June.
Tue, May 28
Spectacle also supports both. We could probably do the same here in the meantime. I'm fine with replacing the current toolbar button with this though; it's much more useful, and Kipi still gets its own menu. Please also add the new action's to the file menu, context menu, and Operations panel. That way it's still accessible for people who don't want it in the toolbar.
Sun, May 26
By renaming the config name in gwenviewconfig.kcfg, you'll reset existing users' preferences. Whenever you want to rename a key in a config file, you need to ship a kconfig update script to update existing users' config files. Look at the contents of the kconf_update folder in the source tree for an example of an existing one. And here's the documentation: https://techbase.kde.org/Development/Tools/Using_kconf_update
All of these new variables can be const
Sat, May 25
...also a blurred thumbnail suggests that the image is defocused.
I haven't checked which folder Gwenview actually tries to delete, but the thumbnails are stored in ~/.cache/thumbnails instead of ~/.thumbnails.
Fri, May 24
You guys really have to setup clang-format or astyle to automate those whitespace formatting issues, IMO.
Thanks, just one last little thing...
Fix unit test.
Sry, I missed that.
It's on my to-do list, I'll take a look tomorrow!
Thu, May 23
Thanks. To account for this behavioral change, I think we need to adjust the UI strings in the settings window as well. Did my suggestion above make sense?
Ahh whatever, this is fine as-is then.
Sry, I should really enable Kate's spell checking.
Thanks in advance for fixing this minor typo.
Docs updated. Need to apply https://phabricator.kde.org/D21329 first, to avoid conflict.
Wed, May 22
Perfect, thanks. Works fine and seems like an appropriate solution. Please fix a typo in the comment and then this is good to go!
Counter-proposal: Only generate high resolution thumbs if the user cares to not throw them away when closing gwenview, that is when deleteThumbnailCacheOnExit() is set to false. If set to true, always use the embedded thumbnail regardless of its size.
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
I think blurry is better than pixellated.
Thanks, this makes sense. Is there an easy way to force thumbnail generation to fail for an image to test this?
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.)
Tue, May 21
My bad, sorry. I should have done a closer code review. Fixed with 3a5cd96bfc92741e6fb6285b516934ffb76ae56f.
There are still code styling issues, but too late...
Thanks very much!
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.
Mon, May 20
Thanks very much! However this patch makes the jpegcontenttest crash. Looks like it needs some adjustment to account for your changes.
May 19 2019
Use private mapping and handle nullptr.
May 18 2019
Also, please use MapPrivate.
Please handle possible nullptr result of QFile::map().
May 17 2019
May 16 2019
May 15 2019
Please feel free to submit more patches. Most of us get by with arc, which is really quite nice once you get used to it, though I can understand how it would be annoying to install if you're only wanting to submit a few patches here or there.