SUMMARY The rename dialog suggests generated filenames with spaces (e. g. "file 1.jpg"). These filenames are awkward to manage with Linux/UNIX shells (e. g. bash) and tools usually don't generate such filenames by default This is hard-coded in RenameDialog::suggestName (https://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/classKIO_1_1RenameDialog.html#a30f6800aedcf9a8d95ef9af04c192827). At the very least there should be a configurable template to allow the user to set an appropriate template, but this dialog should not suggest names that don't follow OS conventions. This makes it impractical for me to use Automatic Rename All (bug 165398), which would make my life a lot easier in some cases (e. g. when I'm photographing an event with two cameras, and at some point they happen to be using the same image basenames).
We've had this request before and it's been rejected, I'm afraid. Our preference is to default to human-friendly names rather than shell-friendly names.
Then can there at least be a template provided, such that someone can change the separator? Spaces in filenames are just not standard in UNIX filenames. If the request has been made before, it's obvious that there are other people with the same issue. And an underscore is not particularly unfriendly.
I don't think we would reject out of hand a patch that implemented the requested feature in an unobtrusive and user-friendly way, so if you want to give it a try, be my guest! :)
An unobstrusive way would be: - "file.txt" collision detected - User clicks "Suggest New Name" - Dialog suggests "file (1).txt" - User edits the suggestion to e.g. "Copy 1 of file.txt" or "file[001].txt" - Dialog remembers these changes as the template for further suggestions (and for automatic suggestions) A requirement would be that the original filename and extension is still part of the edited suggestion, and that at least one field with a number is still part of the additions. Otherwise automatic suggestions cannot work, and it would fall back to the "Name (#).ext" for next suggestions. Good luck :) *** This bug has been marked as a duplicate of bug 317320 ***