An extended error message (e.g. with Overwrite option) for Browse Mode needs a bit of rework, since the renaming is done by the model (not Gwenview) here.

Looks good to me and works perfect for all sort options. 👍

No issues found with any timestamp combinations I tested. :)

Looks good to me and adding the Rating sort option should be easy.

I think I found the problem.
The enum value Sorting::Rating equals ModelColumns::Permissions, see here.
In BrowseMainPage::updateSortOrder() the sort order is set based on the enum value.
Maybe we should add a special case for rating sort order here.

Works good for me.

Works as promised and code looks good to me.
(Seems like LibreOffice and Inkscape does not support NEF files - dropping an unmodified file here results in a mini preview for LO and an error message from Inkscape, while dropping an edited version is ok.)

Looks fine! :)
I can't spot any different behaviour and the patch also improves readability.

In D13028#268410, @rkflx wrote:

You mean KIO should not be adapted to react to the passed filename extension, and users should manually switch from PNG to JPG when they are pasting from a JPG?

Looks flawless to me and I can't spot any more issues. :)
I think the behaviour is totally comprehensible and it's not worth fiddling with the original image formats.

In D13028#267373, @rkflx wrote:

If the file was modified this results in Dolphin not saving for image/x-tga, etc. and you have to select another mimetype to create the file.

Here it gets interesting: I cannot reproduce your claim for BMP, but I can see it for TGA and PBM.

Works perfect for the common file formats.
For a couple of image formats (e.g. TGA, BMP, PBM, PNG) doc->rawData() returns an empty array (modified or not). If the file was modified this results in Dolphin not saving for image/x-tga, etc. and you have to select another mimetype to create the file. PNG seems to be a special case and works anyway.
I'm not sure if this is a bug or feature of Document?
Any idea how Dolpin selects the preferred mimetype - maybe we could just mark this without setting the data?

In D13010#266816, @huoni wrote:

• ThumbnailBar::selectionChanged is always triggered twice when selection changes. Seems to me there's some sort of selection changed event duplication happening somewhere

In D13028#266284, @muhlenpfordt wrote:

It seems application/x-qt-image is always a PNG image. At least I did not see anything other so far.

@rkflx wrote:

However, I just noticed that pasting a cropped NEF will set the correct mimetype (due to my patch), but the pasting itself will fail in the end. Maybe Dolphin can only paste Qt's image formats after all?

Works good for all images and destination apps I found. :)
There's only one issue with non image selections (see inline comment).

(Not in the scope of this fix - I just noticed that PreviewItemDelegate and ThumbnailBarItemDelegate duplicates some code but it seems not that easy to merge.)

In D12871#265075, @rkflx wrote:

Hm, it's not working very reliably in Browse mode, because depending on what you've done before, the focus (i.e. currentUrl()) might not correspond to the first (or even any) selected image. It's working great for Compare, though.

Get selected, not current item in Browse Mode
Use temp bool to be more readable

Fix: Don't copy all urls in Compare Mode (only current)

Extend comment (edited images)

Use currentUrl() to handle compare mode

In D12871#264875, @rkflx wrote:

Would it be easy to special-case comparing images in View mode, e.g. via mThumbnailView->isVisible(), and then use contextManager()->currentUrl()? There, copying the pixmap of the focused image would probably be what users are expecting. If not, that would also be okay.

const added

Copy content for copy and cut
Copy SVG content

In D12871#264329, @rkflx wrote:

• Is there any reason we don't do the same for copying a single image in Browse mode? Essentially we are working around a missing feature in GIMP and Inkscape (i.e. pasting from a URL), so we might as well apply the same workaround (or feature in case of modifications) there? After all, in Browse mode the modified image is displayed too (thumbnail and save icon). For the multi-selection case we could fall back to selectionMimeData().

Update state when current directory or selection changes

In D12902#263925, @huoni wrote:

However, I notice that in Dolphin, pressing the shortcut (Ctrl+V) still results in an error dialog. So it's not the entire action that is disabled, just the menu item. We should copy that behaviour I think.

Hm, seems like the original intention of this change (0861dd248c01) was to adapt to the Dolphin behaviour which in fact disables the paste action for non writable folders.

In D12871#263254, @huoni wrote:

All except LibreOffice Writer worked as expected (pasted the bitmap). Writer presumably used the URL since the original image was pasted.

In D12902#263261, @huoni wrote:

One issue though - in the case of a read-only directory, this fact isn't very obvious. Before, there was an error message which made it explicit, but simply a disabled action might be confusing and appear to be a bug if the user doesn't realise.

Extend existing Copy action instead of adding another one

In D12871#262544, @huoni wrote:

I think we should change the current Copy action to copy the bitmap, but only in View mode (if we're in compare mode, then only the selected image). There is no ambiguity with multiple selection here.

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.

In D12871#262258, @rkflx wrote:

Do we really need this as a separate action? IIRC the regular Edit → Copy action already works for pasting images to LibreOffice and Dolphin.

I'm not sure about the sidebar position of the menu entry. Technically it's more an image than a file operation, but where would a user expect to find this option?
Should we add a default shortcut (e.g. Ctrl+⇧+C)?

I just noticed another related issue.
In View Mode showing multiple images the Image Operations menu is not updated on changing selection to another image type (raster/vector).

Thanks! Since the changes doesn't seem to affect us, let's go the proven way. ;)

Changed summary to be more precise

In terms of the Phabricator changes - what's the way for Gwenview?
Are there any effects when using #gwenview as reviewer?

Call finishUndoJob instead of duplicate QTimer code

Rebase to Applications/18.04

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#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.

Also see D12509 for Gwenview effects on this issue.

Thanks for the profound explanations. :)
I also tested with a couple of mimetype icons from various icon themes that exists in both or only one theme and did not get any different results for loadMimeTypeIcon()/loadIcon().

Update FIXED-IN version

In D12595#255741, @huoni wrote:

In D12595#255519, @rkflx wrote:

But this shouldn't be a problem for KDE 18.08.

…in case @huoni does not forget to bump the version.

Sorry not sure what you mean.

I can't compile this using Kubuntu 17.10 - seems KIconLoader::setCustomPalette() and KIconLoader::resetPalette() does not exist here ("Since 5.38"). But this shouldn't be a problem for KDE 18.08.

In D9342#255369, @rkflx wrote:

@bschiffner Thanks for your concerns. Please note that the ContextManager is quite delicate to work on, as can be seen by the many implications D8196 had after it landed.

I can try to work on this topic first (if Peter does not mind other patches falling behind), but surely you'll understand that pressure from comments on Phab is not a good reason to rush things in.

Sorry, I'm late...
Just noticed a small issue with the units inside the spinboxes. If I press End the cursor jumps beyond px or % - I expected it stopping after the last digit.

In D12489#254971, @huoni wrote:

Anyway, patch looks good now.
Thanks for being a practice reviewee :)

Rebase to other patch

Removed 0-width check

I digged a little deeper in the libraries... ;)
The base icon is loaded in kio-extras function ThumbnailProtocol::thumbForDirectory().
It uses QIcon::fromTheme() to find an icon and converts this to a QPixmap.
The description for the conversion function pixmap() says:

The pixmap might be smaller than requested, but never larger.

I don't know why non absolute path icons are upscaled anyway but the docu states we can't count on the requested size.
IMO thumbForDirectory() should check and scale this base icon if needed. This will result in a upscaled base icon but higher quality overlay items.
Do you think this is the right way? Should I adapt this patch for kio-extras?

In D12489#254235, @huoni wrote:

In that case, we can revert "Prevent save if one splitter side is collapsed", and put the above in a dependent patch?

In D12489#254156, @rkflx wrote:

As we already provide the separate View → Sidebar option, the built-in functionality from QSplitter is not really needed IMO, so I'd tend to go with simply disallowing a zero width.

In D12489#253984, @huoni wrote:

Well, I've had a play around, and found the following problems:

1. If you switch to the Start Page before quitting, the sizes aren't saved.

Save state before switching to start page
Prevent save if one splitter side is collapsed