Copying and pasting a file results in the newly created copy being called "copy of <file>", "another copy of <file>", "third copy of <file>" and after that "Nth copy of <file>". The same goes for links. This is really unfortunate from the usability POV since that copy/link is moved to the location it fits after reordering. Thus one has to wonder where the copy has moved to after pasting. One can select it with Thunar’s selection dialog, however you cannot move that file into view with cursor movement or so. Thus a vast improvement would be to change those strings to "<file> (Copy)", "<file> (Another Copy)" and so on. It isn’t even necessary to try to split file name and extension to insert the copy text. Just move that text to the end. Gain from this: copies are placed next to their original and not moved around in the file list.
I agree with Mathias Brodala. Copies of files would be much easier to handle if they appeared next to the original. > Just move that text to the end. This is not good, especially because one usually wants to rename the copy to something else. In the renamer dialog, the name will be selected, not the extension. How about this simple scheme? file.ext file-1.ext file-2.ext file-...ext Benefits: * The copies are easy to locate, no need for much scrolling. * Renaming is easier, as the name is selected and this requires only minimal cursor movement. * Fewer strings to translate. A disadvantage is that now copies will be scattered if you made copies of many files at once. However, I believe not many users will do this very often. Furthermore, these can still be selected by using pattern selection. Additionally/Alternatively, ask the user for a new file name when pasting single files. I assume in most cases he might want to rename the file anyway after copying it, so this saves an extra keystroke.
(In reply to comment #1) > I agree with Mathias Brodala. Copies of files would be much easier to handle if > they appeared next to the original. > > > Just move that text to the end. > This is not good, especially because one usually wants to rename the copy to > something else. In the renamer dialog, the name will be selected, not the > extension. > > How about this simple scheme? > file.ext > file-1.ext > file-2.ext > file-...ext I agree that this would be the more sophisticated way of handling it but it requires a bit more work. Things like "archive.tar.gz", where only "archive" and not "archive.tar" is relevant should be considered. > Additionally/Alternatively, ask the user for a new file name when pasting > single files. I assume in most cases he might want to rename the file anyway > after copying it, so this saves an extra keystroke. This is the usual behavior in e.g. Gthumb (including a preview of both files involved). For this maybe the rename dialog could be re-used. It would need to be clarified what "Cancel" does then however.
(In reply to comment #2) > I agree that this would be the more sophisticated way of handling it but it > requires a bit more work. Things like "archive.tar.gz", where only "archive" > and not "archive.tar" is relevant should be considered. If you look at the renamer dialog, thunar doesn't care about that in other areas too. It would still be an improvement as it would handle all other files correctly.
On second thought, I don't think it would be difficult to catch such (common) exceptions. I mean: How many possibilities are there really? The code lines you currently spend for creating "xnd copy of" etc. could be replaced by a function checking for these, and you would probably still save some lines and make it less complicated than it is now. You could probably even reuse it for the renamer dialog.
I agree with a lot said so far. The current scheme is terribly annoying. > file.ext > file-1.ext > file-2.ext > file-...ext This is great opinion. I have also seen file(1).ext but who really cares. > Additionally/Alternatively, ask the user for a new file name when pasting > single files. I assume in most cases he might want to rename the file anyway > after copying it, so this saves an extra keystroke. I like this idea, When I think about the reason I copy files it is for one of two reasons, to make a backup so I can screw around with the first one or because I am creating another similar file and would like to use the first as a template. For situation one the renaming is not necessary but if a "This name is already taken, would you like to pick another one?" Dialog pops up it would be of minimal bother if: (a) An "auto-rename" button is present and focused. (b) The name field is filled out with the recommendation. (c) (I'm sure there are more.) This way you would only have to press enter and you are on your way. I think that (for me at least) most copy-paste in the same folder are for template reasons. I think (b) is a better option because It is one less button and you don't lose any info by adding '-#' to the end of the filename. (you can still figure out the original filename)
Sorry for being unclear but for my abc list only one needs to be true.
Nautilus does something that's a hybrid between the Thunar approach and the suggested approach. file.txt file (copy).txt file (another copy).txt file (3rd copy).txt file (4th copy).txt etc In the case of multiple . segments, it puts it before the last one eg: file.tar (copy).gz This may be the best way to handle it in Thunar as well. It would preserve named sorting (other than "another copy" would be listed before "copy"). Thunar could: 1) keep the strings as-is but move them to the end of the file name (but before the final extension) (no change for i18n) 2) replace the strings with copy, copy 2, copy 3, etc. and move them to the end of the file (but before the final extension) (possible simple change to i18n) Even with the introduced space, I think that the "filename (Nrd copy).ext" is better than "filename-N.ext" as it makes it more obvious that it is a copy made by the file manager.
(In reply to Jeff Shipley from comment #7) > Nautilus does something that's a hybrid between the Thunar approach and the > suggested approach. > > file.txt > file (copy).txt > file (another copy).txt > file (3rd copy).txt > file (4th copy).txt > etc That's horrible too. The user still has to do a lot of editing the name after copying the files. Especially annoying with the spaces. > In the case of multiple . segments, it puts it before the last one eg: > file.tar (copy).gz This is a proof for not caring at all on behalf of the developers. Isn't it clear that tar.gz shouldn't be separated? What's worse, it will stop you from opening the file in some applications until you rename it properly. File-roller comes to my mind. Why mess the name up like this? A bit more trivial logic, and everything works fine. > This may be the best way to handle it in Thunar as well. It would preserve > named sorting (other than "another copy" would be listed before "copy"). So actually it doesn't preserve sorting. The only thing nautilus does better here than thunar is that the files will be placed (probably) inconsistently next to the original files, saving you from searching for them. [...] > Even with the introduced space, I think that the "filename (Nrd copy).ext" > is better than "filename-N.ext" as it makes it more obvious that it is a > copy made by the file manager. And why would the user be interested in that? If he copies a file in thunar, he'll know it will be created by the file manager. And it will be selected after pasting, indicating that's the copy. Naming copies like this just makes it more tedious to rename the files afterwards. No, I totally don't agree nautilus does handle this in a user-friendly way.
Created attachment 5110 Option A (using "-N" filenames) Here's an option on how to handle this. It's pretty similar to Harald Judt's suggestion in comment 1: file.ext file-2.ext (assuming the original to be #1, and the first copy to be #2) file-3.ext etc. And for links: link to file.ext link 2 to file.ext link 3 to file.ext etc. This will use the new thunar_util_str_get_extension function, which will recognize extensions such as ".tar.gz". I'm thinking of writing an alternative patch that prompts the user for the new filename (using these names as the suggested default) that uses the rename prompt, but that may not work so well when multiple files are selected for copy/paste.
Appending a digit doesn't do it for me. Its ugly an later on you might not remember why -X was appended. In this case I prefer the Nautilus layout better, but maybe start with (1st copy), (2nd copy).. to preserve sorting. Because the initial point was to fix sorting, not maybe a bit more time renaming.
(In reply to Jeff Shipley from comment #9) > Created attachment 5110 > Option A (using "-N" filenames) > > Here's an option on how to handle this. > > It's pretty similar to Harald Judt's suggestion in comment 1: > file.ext > file-2.ext > (assuming the original to be #1, and the first copy to be #2) > file-3.ext > etc. > > And for links: > link to file.ext > link 2 to file.ext > link 3 to file.ext > etc. Thanks for the patch, it's working great. I don't care about the links, though I think it should be consistent. Very rarely I have used thunar or any other file manager to create links; I'm not even sure if it creates relative links or absolute ones etc. > This will use the new thunar_util_str_get_extension function, which will > recognize extensions such as ".tar.gz". Also finally a satisfying solution! It's especially fine that it works for the bulk renamer too, I wouldn't have thought about that! > I'm thinking of writing an alternative patch that prompts the user for the > new filename (using these names as the suggested default) that uses the > rename prompt, but that may not work so well when multiple files are > selected for copy/paste. Yes, that might pose a problem. I thought about this a bit; maybe one could remember the changes the user made to the old name and use that change for all other files too (perhaps optionally, with the fallback being the user entering the name for each file manually). Example: The filename is "filename.txt". The user changes the copy to "filename-copy-1.txt". Now "-copy-1" will be applied to every other file. But then, that might be too complicated. (In reply to Nick Schermer from comment #10) > Appending a digit doesn't do it for me. Its ugly an later on you might not > remember why -X was appended. In this case I prefer the Nautilus layout > better, but maybe start with (1st copy), (2nd copy).. to preserve sorting. IIRC it's what was forced on Windows users ;-) Since selection has been improved a lot now and is no longer an issue, it doesn't matter too much. So (1st copy),... would now be fine for me too. But not "another copy of", messing up sorting. > Because the initial point was to fix sorting, not maybe a bit more time > renaming. The author of the bug report has agreed with some of my points too. Seriously, if one is about to change this behaviour, why not take other UI aspects into consideration too...
Created attachment 5111 Option B (using " (copy N)" filenames I opted to avoid ordinals, as they're full of rules and exceptions that vary from language to language. It's doable, but not really worth it. For this, links are the same as in Option A. Copies are named "<file basename> (copy N).<extension>" I'm not entirely sure I like it, as it seems that "(copy" and "1)" often end up on different lines in the default view due to line wrapping. Still, it may be the best option. For cases where the user wants to alter the original name it is an additional 7 characters to select/delete, but it's more informative.
(In reply to Jeff Shipley from comment #12) > Created attachment 5111 > Option B (using " (copy N)" filenames > > I opted to avoid ordinals, as they're full of rules and exceptions that vary > from language to language. It's doable, but not really worth it. > > For this, links are the same as in Option A. > > Copies are named "<file basename> (copy N).<extension>" That's good. > I'm not entirely sure I like it, as it seems that "(copy" and "1)" often end > up on different lines in the default view due to line wrapping. It will also depend on font size. > Still, it may be the best option. For cases where the user wants to alter > the original name it is an additional 7 characters to select/delete, but > it's more informative. The amount of additional characters will depend on the translation language too. But it won't matter and this simpler version is less problematic to translate. If necessary, the rename dialog could be improved to make editing filenames easier. For example, hitting some key combination like <ctrl>-<space> etc. could cycle through 3 selections: <file basename>, <(copy N)>, <extension>. Or maybe simply select the <(copy N)> when it is found and select that. But that is not part of this bug. If I may suggest: How about using "<file basename> (link N).<extension>" too for consistency reasons? This too can save you from having to search and scroll and probably it would simplify the code a bit more.
> If I may suggest: How about using "<file basename> (link N).<extension>" too for consistency reasons? This too can save you from having to search and scroll and probably it would simplify the code a bit more. I don't have a strong reason, but I like "link to file". In any case, links are much rarer than copies, and the new link is automatically selected when it is created. I also opted for "link to" instead of "link 1 to" for the first link, as having multiple links would be a very rare case. As it is, links are a little clunky in Thunar. If I had to do very much with them I'd definitely drop down to the terminal. What I'd really like to see is an option (in the Edit menu if not the context menu) to make a link from a previously copied file. This way you could copy a file, switch to a different directory, and then do something like "paste as link". That's outside the scope of this bug though.
All committed in 3d20b81.