In D11942#241128, @huoni wrote:

Can you guys confirm this happens with no animations?

I followed the steps in D11942#241060 and tried different svg and png combinations but can't spot anything wrong. No artifacts as shown in the video above.
The selection rectangle always displays perfect like in this screenshot:

Works perfect now, I can't find any more issues. Just a little style hint (see inline comment).
I hand over to @rkflx for further inspection. ;)

In D11899#239440, @rkflx wrote:

wonder why you branched from master, though, because to me the bugfix sounds like material for the stable branch.

Sorry to say - there is still a problem. When adding the 6th image, the caption jumps from 'a.jpg' to 'f.jpg' and after deselecting it again the caption still shows 'f.jpg'.

In D11715#236077, @rkflx wrote:

one thing caught my eye: QTest::qWait(100) – Is there anything in Qt where you could wait for a condition or a signal instead? The timeout seems brittle and looks a bit weird ;)

In D11715#235890, @muhlenpfordt wrote:

Test #11 failure maybe a config problem on my side? Error log: P179.

Excluded D11714 from diff again

Updated test to wait for signals

Found the problem. :)
Since the modified and saved signals are not emitted directly but after finishing the undo job the test just needed some more delay.

Just noticed that this patch breaks test #4 documenttest. :(
Seems to be an undo problem but I'll have to take a closer look what's going wrong here.
For current master sometimes #11 urlutilstest fails too.

• Updating the thumbnail after the first edit is a side effect of the appearing save bar and therefore changing the view geometry.
• In Browse Mode the provided QModelIndex and thumbail update is correct since the base model is used here.
• In fullscreen mode all visible thumbnails in the autohide bar are repainted after the image view is updated so this problem is not noticeable here.

In D11630#232743, @rkflx wrote:

I wonder whether we should make this option the new default?

In T8194#133776, @rkflx wrote:

looking again at #1 there is not really a good solution, because this affects all apps and it's very tricky to make this foolproof. Should we mark the task as resolved?

The naming looks good to me.
Menu/button always displays Start Slideshow in normal mode and after switching to fullscreen. Only after starting/pausing a slideshow Pause / Resume Slideshow is displayed.

Capture member variables only

In D11493#229909, @ngraham wrote:

Most normal users don't know that ~ is a shorthand for "my home folder", and we should keep in mind Gwenview's target user.

@rkflx Sorry, I don't want to rush - if it doesn't make it for this version it's absolutely ok for me! ;)

In D11479#229372, @rkflx wrote:

Here is an alternative idea: Change this to Add Containing Folder to Places.

"Add File to Places" -> "Add Containing Folder..." / uppercase "This"

Looks good to me - code and Start Page. ;)
What do you think about displaying /home/user/ just as ~? Personally I would prefer this. ;)

In D11477#229715, @rkflx wrote:

Don't forget that Applications/18.04 has now been branched off ;)

Renamed function and code alignment

Works as promised for local urls given as commandline argument or by navigating inside Gwenview. :)
I found only one way to add multiple recent folder entries with multiple slashes: commandline urls like sftp://server/ and e.g. sftp://server/// or http://...////. This is not handled by UrlUtils::fixUserEnteredUrl() inside MainWindow::setInitialUrl(). But I'm not sure if we should touch remote urls?

Maybe it would be cleaner to handle the context menu in HistoryThumbnailViewHelper like e.g. ThumbnailViewHelper does. But this needs some bigger changes to keep track of the selected item. This is done by ContextManager elsewhere.

Since the user can't see any recent folders in File → Open Recent I think it would be confusion to show separate Clear Recent Files and Clear Recent Folders.
But it's no problem to add menu entries here if we find a more obvious way.

In D11202#226207, @huoni wrote:

I guess my question is, is it worth re-working how we store the ratios in order to accommodate this? I'm thinking something like a list of custom objects that contain some metadata in addition to a ratio would be necessary.
Any other ideas?

The click position is not centered but kept at the same location as it is done with Ctrl+Scroll / Ctrl+Click. This feels more convenient to me than the click location jumping to viewport center as suggested in the bug report.
But maybe there are other opinions to this?

Simple change - but feels more convenient this way. 👍

Moved default for LastTargetDir part to other diff

There's one section in the config file that remains after disabling the history. It's from the QFileDialog/KFileWidget (e.g. Copy/Move/Link dialog).

[KFileDialog Settings]
Recent Files...
Recent URLs...

I found no option to disable this. But probably this should be a KDE thing and maybe affected by System Settings → Activities → Privacy.

Just an idea and probably out of focus here: Should we add some kind of shortcut to e.g. square and/or image dimension selection with Ctrl/⇧ + mouse drag like some image manipulation programs do?

The title updates correctly when selecting the image by mouse click.
But when adding or removing images to the multi view or while resizing the window (zoom factor change) the title does not always stick to the selected image.

In D10964#216902, @rkflx wrote:

I guess you used arc diff --edit --verbatim without using arc amend first.

In D10964#216893, @muhlenpfordt wrote:

removed a reviewer: rkflx.

Removed StartHelper destructor

What do you think about the draft in P172 to solve the memleak warning?

In D10853#215810, @rkflx wrote:

memleak

Anything to worry about? Perhaps it' worth trying out Valgrind or ASAN, might solve some of the random crashes on Bugzilla…

Works as it should and adjust display immediately after changing the option.
I shortly thought about moving it back to AbstractImageView but there may be future derived views where it makes sense to ignore/separate this option - so it's fine here. :)

This patch does not improve renaming in browse mode since it's done inside KDirModel::SetData(). Maybe a rename detection e.g. in ContextManager could solve this issue.

I can't see any disadvantages for the normal photo browsing user so why not as default.
The users handling with small icons and don't like it should be able to find the off switch. ;)

Works as described and I can't spot any technical issues.
Just a hint to the BUG-keyword: maybe it works but policy says uppercase.

In D10853#214344, @rkflx wrote:

Therefore, could we simply add this to kstart?

Removed config/commandline options

In D10853#214344, @rkflx wrote:

It's not easy to have to say no to a new feature like that, especially when the patch is already written. But I guess someone has to do this once in a while to keep Gwenview on track. I hope you understand…

In D10853#214226, @rkflx wrote:

Also, is there any other app which has a similar GUI config option? We could take a look at how they phrase it, but if there is none with a similar target user base as Gwenview perhaps this is an indication we should not add this feature.

I thought about a three state option instead of the on/off switch. Any preferences for this version?

Space saving version	... or similar to other radio buttons

In D10745#213482, @rkflx wrote:

Perhaps because of the else in FileOpsContextManagerItem::rename? I guess for Browse mode we'd also need to call setCurrentUrl. Where to get newUrl from, though?