There is no error message when renaming a file when the name of an existing file is selected and the image is displayed. An error appears only when renaming within the picture overview. NAME="Ubuntu" VERSION="16.04.4 LTS (Xenial Xerus)" Version 15.12.3 Unter: KDE Frameworks 5.18.0 Qt 5.5.1 (kompiliert gegen 5.5.1) Das xcb Fenstersystem
Thanks for the report. I can confirm the issue with Gwenview 18.04.2. When pressing F2 in View mode, renaming is aborted, but no error is shown. Also I wonder whether we could show a "File already exists: Rename / Overwrite / Cancel" dialog (cf. Dolphin) instead of the plain error message for both View and Browse mode.
Henrik, did you test with KIO 5.47.0? See also bug 394318.
> Henrik, did you test with KIO 5.47.0? See also bug 394318. I now tested with KIO 5.47, but as I suspected the bug is still there. Bug 394318 was about pasting and unconditionally overwriting, while here the issue is with renaming and silently aborting if the file already exists. Sounds like a genuine Gwenview problem to me.
Looked more into this: - Showing a warning in Browse mode instead of the Rename / Overwrite / Cancel" dialog worked before, so it is actually a regression, caused by 6ca0b93e6029 in KIO (according to git blame). Perhaps "setData" in PreviewItemDelegate::setModelData now needs to be replaced with manual handling of the renaming, using KIO::moveAs instead of the implicit KIO::rename. - Showing no warning in View mode is a regression introduced while porting to Qt 5 (it works fine with a KDE 4 based version, but is already broken with Gwenview 14.12.0, KIO 5.7.0, KJobWidgets 5.0.0, KCoreAddons 5.0.0 or somewhere else in KF5). In FileOperations::rename, showErrorMessage() does not seem to have an effect anymore. As nothing relevant changed in fileoperations.cpp in that time frame, this is likely a behavioural change in KF5 (either a bug, or something Gwenview missed to be ported to). To fix the issue, the call can be removed in exchange for setAutoErrorHandlingEnabled(true). However, the better dialog from KIO::moveAs might make more sense. It might be worth checking whether the better dialog for renames in both View and Browse mode can be implemented in a single place, e.g. in FileOpsContextManagerItem::rename.
> a regression introduced while porting to Qt 5 Turns out this was due to a change in what is now KJobWidgets: efbf655b7ab5
Git commit 47c66913c6ec11408504cdee7c6519d9224b6798 by Peter Mühlenpfordt. Committed on 29/06/2018 at 07:22. Pushed by muhlenpfordt into branch 'Applications/18.04'. Enable AutoErrorHandling for rename job Summary: If a rename job started from View Mode fails, no warning message is shown. This is caused by the default disabled `AutoErrorHandling` in `KJobUiDelegate`. This patch enables the flag after creating the job. FIXED-IN: 18.04.3 Test Plan: # Open Gwenview in View Mode # Try to rename image to already existing filename # An error message should be displayed Reviewers: #gwenview, rkflx Reviewed By: #gwenview, rkflx Subscribers: rkflx Differential Revision: https://phabricator.kde.org/D13754 M +1 -1 app/fileoperations.cpp https://commits.kde.org/gwenview/47c66913c6ec11408504cdee7c6519d9224b6798