Version: 1.0.0 (Jan 2 2010) (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages If you enter the rename command [file]{r:"%20"," "}.[ext] in the rename dialog of Digikam, the oke-button is unselectable. So you are not able to execute the rename command. The goal of the mentioned command is to replace the text '%20' in the file names with a (real) space. As far as I understand this is a correct rename command. So Digikam should be able to execute it. I was able to execute the command when I also added text to the file name. So for example I issued the rename command ExtraText[file]{r:"%20"," "}.[ext] This works. Yet you should also be able to just replace a part of the filenames.
Hi, can you upload an example file? For me it is working. Maybe Qt already interprets %20 as whitespace and therefore no renaming will take place, because you actually didn't change the filename in that case. The rename tool will only allow renaming if the names actually changed (I guess they are displayed in red in the file list).
Ok I guess the problem is the following: You tried to rename files that contain "%20" and others that don't contain such a string. The problem now is that these files will not have a new name and therefore can not be renamed. The problem is that if this safety check is disabled, KDE will ask you for a new name for every colliding filename. If you rename thousands of images, this can quickly become a pain. A quick workaround should be if you display the albums containing these files in recursive mode and then filter the names by "%20". Now you can select all those images and rename them without a problem.
Hi Andi, Thanks a lot for the superb and quick response. Your second comment is correct on the problem. Thanks for the insight. And the workaround works for me. I guess you mean 'use an (advanced) search' if you say 'display the albums ... in recursive mode'. I guess it speaks for itself that a fine improvement would be if the rename dialog would be intuitive in this sense: that it would allow files to be in the list which will not be renamed because the renaming action doesn't apply to them. Might this be a solution?: The rename dialog for example could filter out these files before the filenames are transfered to the renaming function of KDE?? (Or do I speak nonsense?) Maybe a temporarily solution is if the manual guys point this behavior out in the manual. Well, thanks for the suburb help. Michiel
(In reply to comment #3) > I guess you mean 'use an (advanced) search' if you say 'display the albums ... > in recursive mode'. Either this way or you could select your root album (the collection) in the album folder view, and check the Option "View->Include Album Sub-Tree" in the Menu, to see all your images at once. Then you could simply filter these images with the search field in the status bar. > I guess it speaks for itself that a fine improvement would be if the rename > dialog would be intuitive in this sense: that it would allow files to be in the > list which will not be renamed because the renaming action doesn't apply to > them. > Might this be a solution?: The rename dialog for example could filter out these > files before the filenames are transfered to the renaming function of KDE?? Yes, in general this could work. But ignoring these files silently wouldn't be the best option. I will try to think about some solution. Maybe we could have a wizard-like dialog: The first page is the one we have now, and the second (if needed) shows the conflicting files and offers some tips / buttons / actions / whatever to solve these issues.
(In reply to comment #4) > (In reply to comment #3) > > I guess you mean 'use an (advanced) search' if you say 'display the albums ... > > in recursive mode'. > > Either this way or you could select your root album (the collection) in the > album folder view, and check the Option "View->Include Album Sub-Tree" in the > Menu, to see all your images at once. Then you could simply filter these images > with the search field in the status bar. Clear. Thanks. > > I guess it speaks for itself that a fine improvement would be if the rename > > dialog would be intuitive in this sense: that it would allow files to be in the > > list which will not be renamed because the renaming action doesn't apply to > > them. > > Might this be a solution?: The rename dialog for example could filter out these > > files before the filenames are transfered to the renaming function of KDE?? > > Yes, in general this could work. But ignoring these files silently wouldn't be > the best option. I will try to think about some solution. Maybe we could have a > wizard-like dialog: The first page is the one we have now, and the second (if > needed) shows the conflicting files and offers some tips / buttons / actions / > whatever to solve these issues. Wonderful! Just a thought: Maybe I don't see the human interface thing which is important here. But I tend to think that using the red / black marking which is used now, indicates clearly that some files are affected an others are not. I like that. Maybe it is an idea to even improve that. That keeps it simple and yet powerful.
This bug should be fixed now, files that will not be changed will also not be renamed now. The ok button is only disabled when file names are conflicting.
Top! On Wed, Jun 27, 2012 at 12:24 PM, Gilles Caulier <caulier.gilles@gmail.com>wrote: > https://bugs.kde.org/show_bug.cgi?id=228718 > > Gilles Caulier <caulier.gilles@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Version Fixed In| |2.0.0 > > -- > You are receiving this mail because: > You reported the bug. >