While renaming a file in inline edit mode, and changing directory with back/forward or in the breadcrumb panel, the wrong file is renamed. instead of renaming/drop changes on such an action the file/folder with the same index in the new folder is renamed instead. Reproducible: Always Steps to Reproduce: 1. Create some folder/file structure, with some files/folder in each folder 2. Start inline renaming one file in a child folder 3. Go out with the breadcrumbs or back botton. Actual Results: Wrong file is renamed Expected Results: Abort renaming action
Thanks for the bug report! I can confirm the problem.
I too confirm this. A similar bug is when in detailed view: 1) Open a folder (say x) 1) Expand a sub folder (say y) 2) Start renaming a file (say f2) below y 3) A new file is created in the y (eg: ongoing download list), the view shifts down by one line and the file above f2 gets the new filename. So if there are files f1 and f2, try to rename f2 to g2, f1 is renamed to g2 while f2 remains unaffected. Should I open a new bug report for the above?
> Should I open a new bug report for the above? Yes, please. Even though these issues are related, I think that both need to be changed separately. The "folder change" issue can probably be fixed by only connecting to the view's slotRoleEditingFinished() signal when starting renaming and disconnecting immediately when renaming is finished, canceled, or the URL changes. Requires a bit of careful code reading and testing though to make sure that we don't break anything else. Anyway, this would not affect the problem that you have found. Thanks for your help!
Thanks for the reply Frank. I've opened a new bug report (bug id #320823). Glad to help!
Git commit 4de9a233642a62ee96bac6031340d3eea21f14f9 by Frank Reininghaus. Committed on 10/06/2013 at 21:15. Pushed by freininghaus into branch 'KDE/4.10'. Do not rename files unexpectedly when changing the URL If the role editor loses focus, it considers the current renaming operation finished, and tells DolphinView to rename the file. This is a problem when changing the directory, because the URL change happens before DolphinView receives the signal, which results in a file in the new directory being renamed unexpectedly. The solution is to establish the connection to the slotRoleEditingFinished signal only when the "rename inline" editor is opened, and disconnect it when renaming is finished or canceled or the URL changes. FIXED-IN: 4.10.5 REVIEW: 110908 M +16 -19 dolphin/src/kitemviews/kstandarditemlistwidget.cpp M +2 -2 dolphin/src/kitemviews/kstandarditemlistwidget.h M +2 -13 dolphin/src/kitemviews/private/kitemlistroleeditor.cpp M +2 -6 dolphin/src/kitemviews/private/kitemlistroleeditor.h http://commits.kde.org/kde-baseapps/4de9a233642a62ee96bac6031340d3eea21f14f9
Sorry - the commit message was completely wrong. I mistakenly swapped two local branches in my git repository - the last commit was actually the fix for bug 320823. But a fix for this bug is coming in a few minutes...
Git commit 5948dc0f3316ac5c60b6825e7cf997d7634642f6 by Frank Reininghaus. Committed on 09/06/2013 at 12:14. Pushed by freininghaus into branch 'KDE/4.10'. Do not rename files unexpectedly when changing the URL This is the real fix now - note that the last commit 4de9a233642a62ee96bac6031340d3eea21f14f9 was actually the fix for bug 320823. Somehow, I have messed up the local branches in my git respository clone - sorry for the confusion! FIXED-IN: 4.10.5 REVIEW: 110908 M +17 -2 dolphin/src/views/dolphinview.cpp M +1 -0 dolphin/src/views/dolphinview.h http://commits.kde.org/kde-baseapps/5948dc0f3316ac5c60b6825e7cf997d7634642f6