Nice! I do very much like the idea of improving Dolphin's batch-rename dialog, as the current one is mostly useless except for one specific use case.

For UI inspiration, you might have a look at Nautilus, which I believe has a really nice, powerful, user-friendly batch-rename dialog.

Always using inline rename for renaming a single file makes sense to me, as it's how every other file browser on every other platform does it. Even if we don't do that, I think it makes sense to continue showing the simple rename dialog for the non-inline-rename-a-single-file use case.

Also, I would make sure that the "Use Regex" checkbox is unchecked by default (and maybe it should use the full term with more descriptiveness, i.e. "Use regular expressions matching" or "Match regular expressions")

And BTW, this is heavily relevant to the Usability & Productivity initiative and if implemented, would be featured on https://pointieststick.wordpress.com/category/usability-productivity/

Remember that it should work with all languages, so stuff like #now or #today either need to be translated or get a description that will be translated

Another possible solution would be to remove those two and allow date formatting like Spectacle does: %Y-%M-%D and so on, however things like #now and #today seem a bit easier to use and they would respect the user's locale anyways. As far as translating goes, not 100% sure on that on either way.

Any progress on this? I'm really eager to see it in Dolphin!

Yeah, it's shaping up quite nicely. Most likely on Sunday I'll update this revision with the latest changes. I'll have to look at a few things regarding batch rename added on D9103 which appears to automatically add sequence numbers even though no placeholders were given.

You might need to re-base on master; there have been a lot of changes to master since you began this patch. It currently doesn'y apply for me.

Update to latest diff.

@emateli For initially uploading this patch, you used Arcanist, which is great. Just use arc diff again to update the patch, this way Nate would not have run into issues with arc patch, as Arcanist would have been able to properly track the parent revision your patch is based on.

(Rebasing on master is good practice and required for landing, nevertheless.)

Let us know if you need help with that.

@rkflx The VM on which I initially started the patch and did the first revision failed on me after I did a virtual disk resize, so I had to make a new machine. Since it was late when I finished my work I uploaded it manually rather than finding out if arcanist would allow me to "resume" my work on the existing differential (is there some quick way to do so by the way?).

In D10698#224052, @emateli wrote:

@rkflx The VM on which I initially started the patch and did the first revision failed on me after I did a virtual disk resize, so I had to make a new machine. Since it was late when I finished my work I uploaded it manually rather than finding out if arcanist would allow me to "resume" my work on the existing differential (is there some quick way to do so by the way?).

Clicking on Revision Contents → History, gives me the base revision of your first patch. This means to get it working again if you wanted to start over on the old Dolphin commit, but with your latest patch, you could do this:

git checkout ae67f99
arc patch D10698

This works fine, and you could make more changes and upload them via arc diff.

However, eventually you have to rebase on latest Dolphin master:

git fetch
git rebase origin/master

This will lead to some merge conflicts, which you'll have to solve the usual way (let us know if your google foo fails you for that).

After you completed the rebase, update the revision on Phab again with arc diff.

Hmm, it doesn't apply on top of master for me:

Created and checked out branch arcpatch-D10698.
Checking patch src/views/renamedialog.cpp...
Checking patch src/views/renamedialog.h => src/views/rename/renamers.h...
error: src/views/rename/renamers.h: already exists in working directory
Checking patch src/views/rename/renamers.cpp...
error: src/views/rename/renamers.cpp: already exists in working directory
Checking patch src/views/renamedialog.h => src/views/rename/renamedialogmodel.h...
error: src/views/rename/renamedialogmodel.h: already exists in working directory
Checking patch src/views/rename/renamedialogmodel.cpp...
error: src/views/rename/renamedialogmodel.cpp: already exists in working directory
Checking patch src/views/renamedialog.h => src/views/rename/renamedialog.h...
error: src/views/rename/renamedialog.h: already exists in working directory
Checking patch src/views/rename/renamedialog.cpp...
error: src/views/rename/renamedialog.cpp: already exists in working directory
Checking patch src/views/dolphinview.cpp...
Checking patch src/CMakeLists.txt...
Applied patch src/views/renamedialog.cpp cleanly.
Applied patch src/views/dolphinview.cpp cleanly.
Applied patch src/CMakeLists.txt cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!

In D10698#226153, @ngraham wrote:

Hmm, it doesn't apply on top of master for me

Works fine for me, might be your local setup?

Odd, it was something strange with my Dolphin checkout. The patch applies with a fresh checkout, but doesn't compile:

[ 42%] Building CXX object src/CMakeFiles/dolphinstatic.dir/panels/places/placesview.cpp.o
[ 43%] Building CXX object src/CMakeFiles/dolphinstatic.dir/panels/panel.cpp.o
[ 43%] Building CXX object src/CMakeFiles/dolphinstatic.dir/panels/folders/foldersitemlistwidget.cpp.o
[ 43%] Building CXX object src/CMakeFiles/dolphinstatic.dir/panels/folders/treeviewcontextmenu.cpp.o
[ 44%] Building CXX object src/CMakeFiles/dolphinstatic.dir/panels/folders/folderspanel.cpp.o
/home/dev/repos/dolphin/src/panels/folders/folderspanel.cpp:33:32: fatal error: views/renamedialog.h: No such file or directory
compilation terminated.
src/CMakeFiles/dolphinstatic.dir/build.make:823: recipe for target 'src/CMakeFiles/dolphinstatic.dir/panels/folders/folderspanel.cpp.o' failed

There definitely seems to be something up with the renamed files in this patch.

In D10698#227677, @ngraham wrote:

This is very nice. I think with a bunch of UI polish, it will become a much-beloved feature. To get there, allow me to share some UI suggestions and comments:

Thanks Nate for taking the time to write those up, +1 to pretty much all of your points ;)

• I don't think we need a Close button on the bottom here; the window already has a close button in the titlebar.

For non-application windows in general, i.e. "real" dialogs, we currently always show a Cancel button. I would keep the button and just rename it.

Apologies in advance for the wall of text.

• The table view needs better headers. Instead of "1" and "2", how about something more like "Current names" and "New names"

It's "Name" and "New Name".

• I don't like that the bottom buttons aren't aligned to the bottom of the window. I understand that it's to make room for some text under them, but maybe we can find a better way to display that. KMessageWidgets are often a good fit for this kind of inline semi-transient notification.

I personally prefer a more traditional status bar for such information and rather dislike the KMessageWidget which I have 2 issues against:

1. When it appearts it causes a layout scroll since it will now occupy space in the window.
2. It's not very pretty.

However I have no strong opinion on the matter and best would be to follow the convention.

• Instead of making users click on a Preview button, is there any chance we can preview in real time as you type?

Done. Removed the preview button entirely, once user stops typing or changes one of the settings the preview will be automatically generated.

• What's the difference between #name and #bname? Along with #ext these terms seem excessively jargonistic.

• #name is the full name with extension
• #bname is the base name
• #ext is the extension.

Looking forward on input on how to simplify these. A more verbose, but human-readable templating could be with some sort of indicator, such as @FileName, @BaseName, @Extension. For the date variables I kept the same formatting as Spectacle for consistency but they too could be renamed to things like @Year and so on. Anyhow, this won't fit on a label and needs either a dialog or a link to some manual page to clarify things. Especially given the complexity of the next two modes.

• I couldn't figure out what New name from matches actually did without reading the description you write in this revision. Since it requires the use of regular expressions, I think that detail needs to be mentioned somewhere (and maybe hidden a bit better, since that makes it a very advanced feature).`

Like mentioned, this whole thing needs some documentation page or a help dialog. It's also now called "Captured Groups" but still looking forward to suggestions on how to better label this.

Also, since the Find & Replace tab already does regex matching, could we find a way to collapse New name from matches into that tab?

I'd rather not. That page might become cluttered and the only thing they share is the use of RegEx. Besides, one is Find & Replace while the other doesn't really do any replacing at all.

Issues that have arisen from this:

Batch renaming done in KIO.

The Batch rename command in KIO takes it upon itself to do the expansion for the # placeholder. To make matters worse even if # is not present it will append the number at the end regardless.

What I propose KIO gets is simply a batch rename operation that accepts two lists, the current names, the new names and should simply do the rename in a batch without any additional processing on the file names. A simple rename "these" files into "those".

Localization.

I set the locale to german in the system preferences and tried to reuse some of the existing translations for this, however even though they are translated in german([https://websvn.kde.org/*checkout*/branches/stable/l10n-kf5/de/messages/applications/dolphin.po](I consulted this file)) they won't apply. Probably not big of an issue but I'd rather see how they look and that they are in fact, translated.

In D10698#228277, @emateli wrote:

Apologies in advance for the wall of text.

• The table view needs better headers. Instead of "1" and "2", how about something more like "Current names" and "New names"

It's "Name" and "New Name".

Hmm, I still see "1" and "2". Did you push a new version of the patch up to Phabricator with arc diff?

I personally prefer a more traditional status bar for such information and rather dislike the KMessageWidget which I have 2 issues against:

1. When it appears it causes a layout scroll since it will now occupy space in the window.

That's true, but can be made a smaller issue by locating it right above the buttons. That way only the buttons will move, and the main UI will remain the same.

2. It's not very pretty.

It's currently being redesigned, so hopefully that will be addressed. Regardless, consistency is important, as if we consistently use an ugly thing, we can redesign to to be prettier and everyone benefits. :) I believe @hein is even working on a pop-over version that will address your very legitimate concern about forcing a layout change.

• Instead of making users click on a Preview button, is there any chance we can preview in real time as you type?

Done. Removed the preview button entirely, once user stops typing or changes one of the settings the preview will be automatically generated.

Did you push a new version of the patch to Phabricator? I don't see the changes. You might need to do another arc diff to update the revision here.

• What's the difference between #name and #bname? Along with #ext these terms seem excessively jargonistic.

• #name is the full name with extension
• #bname is the base name
• #ext is the extension.
  
  Looking forward on input on how to simplify these. A more verbose, but human-readable templating could be with some sort of indicator, such as @FileName, @BaseName, @Extension. For the date variables I kept the same formatting as Spectacle for consistency but they too could be renamed to things like @Year and so on. Anyhow, this won't fit on a label and needs either a dialog or a link to some manual page to clarify things. Especially given the complexity of the next two modes.

Might be worth taking a look at how Spectacle handles usability for tokens like these:

Also, since the Find & Replace tab already does regex matching, could we find a way to collapse New name from matches into that tab?

I'd rather not. That page might become cluttered and the only thing they share is the use of RegEx. Besides, one is Find & Replace while the other doesn't really do any replacing at all.

Looking at

...I think an average user would consider this a variant of find and replace. That said, an average user would be rather perplexed by this, so maybe we should hide it better in the first place. It is super-advanced functionality, after all.

In D10698#229954, @ngraham wrote:

Might be worth taking a look at how Spectacle handles usability for tokens like these:

Let me plug Gwenview's importer then, where naming of the variables and usability of the insertion is even better:

Might even be worth thinking about making this a generic component instead of copying the code…

In D10698#229958, @rkflx wrote:

Let me plug Gwenview's importer then, where naming of the variables and usability of the insertion is even better:

Might even be worth thinking about making this a generic component instead of copying the code…

Ooh, that iseven nicer. I would definitely support modularizing that so we can easily use it everywhere tokens are used like this.

How's it going, @emateli? Do you need a hand with anything?

Everything's alright. Just being a bit busier than usual. On the weekend I will update this with some more thoughts on the matter and a new diff.

Wonderful! I don't mean to rush you; take your time.

So this is finally updated with the latest changes and a new test suite for some utility functions and the code which does the macro substitution, find&replace and group capturing.

@rkflx, @ngraham as far as usability is concerned for the first tab with the placeholder replacement, while both the images you submitted are better than the temp label i've been using, I can't help but notice they both take quite a bit of space and would make the form rather large. What do you think of having something like in the image below where you insert the tokens via a dropdown? Again, I have no strong opinion on the matter and would like to have a consistent approach among KDE apps given that Spectacle, Gwenview and now Dolphin will be utilizing some form of that "token replacement".

As far as merging "Find & Replace" with "Capture groups" goes I'd still like to keep them separate, but I look forward to more toughts on the matter.

On a final note, @dfaure: in order to be complete this would need either a new or an update on the batchRename KIO operation, as mentioned in my comment above, it will add the "#" number even if the placeholder is present. This dialog does all the necessary substitutions before sending them to KIO. I think a new batchRename operation which does no additional processing but simply renames a list of files might be needed. Thoughts on the matter? Should I start preparing a new patch for KIO?

This is fantastic work, @emateli. I've got only a new remaining UI comments:

• Rename the "Name" column to "Current name"
• Rename the "Rename" tab to be "Sequential numbering" or something like that
• When I switch to another tab, the preview doesn't automatically update until I change something in one of the text fields
• I still think Capture groups could be rolled up into Find & Replace. Here's how I think it could be done: by allowing you to define multiple find-and-replace substitution pairs in the Find & Replace tab, not just a single one. This essentially replicates the feature of regex capture groups, but in a user-friendly manner.

I really like your idea for a more compact token UI, and agree that whatever we choose, we should use the same thing in all apps that make use of this convention. That suggests that it should be in a framework, and belongs in a separate patch.

I have another comment on the UI: I don't understand how #name, #bname, and #ext are supposed to work.

On a final note, @dfaure: in order to be complete this would need either a new or an update on the batchRename KIO operation, as mentioned in my comment above, it will add the "#" number even if the placeholder is present. This dialog does all the necessary substitutions before sending them to KIO. I think a new batchRename operation which does no additional processing but simply renames a list of files might be needed. Thoughts on the matter? Should I start preparing a new patch for KIO?

Sounds like we can just add a new enum to JobFlag? (which would be used only by KIO::batchRename()).

Hi! I've just played around a little with this. I've deliberately not read this thread to get an unbiased first encounter experience.

$ touch num${000..035}.cvs

First of all: This is very good, a gem!
This is where the tools behaviour differed from my expectations. A soliloquy:

• What is #bname? Let's try it... Ahhh basename.
• #bname.#ext Oh two dots
• Does this escape '#'? file \##ext file \\##ext. Obviously not. Move on to 'Find & Replace'.
• Er..., no list update? Never mind type a 'u' in Find. Aha there's the update
• Type a 't' in Replace and delete 'u' form Find. Hihihi - my bad.
• Does regex capture? \d*(\d+) \1. Oh yeah. \d*?(\d+) Perfect! (Editor's note: remove this. It was expected)
• This is flawless but what might the colons of the checkboxes labels mean?
• On to 'Capture Groups'
• ???
• ???
• Never mind, you'll find out what this is sometime.

Last of all: This is very good, a gem!

@emateli, what do you think about implementing this in KIO rather than Dolphin? That way, it would be really easy to add it to other clients that could benefit because they do a lot of file handling and renaming, like Gwenview.

I don't see why not. Even though this does seem like rather irrelevant functionality for an image viewer. Perhaps it could be useful to the fokls on the Krusader Project ?

Might this patch also fix https://bugs.kde.org/show_bug.cgi?id=392681, or be trivially adjusted to do so?

In D10698#239369, @ngraham wrote:

Might this patch also fix https://bugs.kde.org/show_bug.cgi?id=392681, or be trivially adjusted to do so?

I think that bug is a duplicate of https://bugs.kde.org/show_bug.cgi?id=381483 which I have reported a while back. So I suppose yes. (I also marked the bug you linked as a duplicate of it given that it's older)

@ngraham

Rename the "Rename" tab to be "Sequential numbering" or something like that

The issue with this is that there are more tokens now than just "#", so perhaps that could be misleading in a way?

When I switch to another tab, the preview doesn't automatically update until I change something in one of the text fields

Good idea. Works like that now.

@michaelh

Does this escape '#'? file \ext file \\ext.

It doesn't as you found out but maybe it should I suppose.

This is flawless but what might the colons of the checkboxes labels mean?

Removed, not sure why they were there in the first place.

On to 'Capture Groups' ??? ???

Yeah, this one is a bit trickier to work out than the rest. The idea is that you match some regex groups on the input string and entirely transform the filename by giving it a new name and inserting the matched groups into the placeholders.

This has been discussed a decent amount here, I added some "previews" from the captured groups to better help while working with this. I'll see if it's possible to update the labels and tab name to give a better discoverability of the functionality, but ultimately this is one of those things that is better explained in the documentation. Hene that help button in the form.

Also, given that there was some talk about this being in KIO rather than Dolphin I tried pinging the Krusader (not sure if mentioning it like this even sends any notifications to them. In case it doesn't: Pinging @asensi on whether this would be a good addition to the Krusader project so then we can consider moving it to KIO).

Pinging @asensi on whether this would be a good addition to the Krusader project so then we can consider moving it to KIO).

Thanks, Emateli, I've just communicated it in the development mailing list of Krusader: https://groups.google.com/forum/#!topic/krusader-devel/N1k3WDBvLdc

This is so nice, and getting nicer all the time. Here's an idea for Capture Groups: we could add a little piece of explanatory text to the window to help people make sense of what they're seeing. I just worry that 99% of people who see that tab will have no idea what it does and feel stupid.

More little nitpicks:

• Table view cells are still uselessly selectable. Is this not possible to turn off?
• Let's change the Close button to say "Cancel" to users can be assured that clicking it will leave their files untouched.
• The Insert Token button needs a downward-pointing arrow to indicate that it opens a menu. I know there's a way to get this automatically but I ran't remember what it is right now.
• #ext contains the dot and maybe shouldn't?

Still giving a +1 for moving this into KIO so Gwenview and Krusader can use it too if they'd like.

Again, truly excellent work. You should be very proud of this.

In D10698#253974, @ngraham wrote:

This is so nice, and getting nicer all the time. Here's an idea for Capture Groups: we could add a little piece of explanatory text to the window to help people make sense of what they're seeing. I just worry that 99% of people who see that tab will have no idea what it does and feel stupid.

More little nitpicks:

• Table view cells are still uselessly selectable. Is this not possible to turn off?
• Let's change the Close button to say "Cancel" to users can be assured that clicking it will leave their files untouched.
• The Insert Token button needs a downward-pointing arrow to indicate that it opens a menu. I know there's a way to get this automatically but I ran't remember what it is right now.
• #ext contains the dot and maybe shouldn't?
  
  Still giving a +1 for moving this into KIO so Gwenview and Krusader can use it too if they'd like.
  
  Again, truly excellent work. You should be very proud of this.

Thanks for the kind words, Nate.

Basically the table selection is the default one so it's not changed. I think the row selection may be useful just for highlighting some row you want to focus on but other than that it doesn't do much.

Close to Cancel makes sense.

Lastly, regarding the dot on #ext, that is by design, it will have a dot if the filename has an extension and be empty when there is no extension. Consider the following case:

files to rename: file1.tar.gz, anotherfile and you wanted to rename it into #name(%Y)#ext which will result in file1(2018).tar.gz and anotherfile(2018). If #ext didn't have the dot, you'd have to write #name(%Y).#ext which would produce file1(2018).tar.gz and anotherfile(2018). <- note the dot at the end here.

Still giving a +1 for moving this into KIO so Gwenview and Krusader can use it too if they'd like.

Yes, in the future it can be used by other programs.

Coming from Krusader project...

Sorry, took me some time to answer as we were busy preparing for release.

The idea behind this is not to replace KRename or similar tools, but to add some slightly-more-than-basic batch rename tools while keeping the whole thing user friendly.

It seems like a small tool independent of Dolphin to me. Similar to KRename. In fact, Krusader integrates with KRename quite well, so in case this one becomes an external tool with a similar command line interface, it should work without even changing Krusader code (only settings). Can you summarize what current ties with Dolphin are?

Still giving a +1 for moving this into KIO so Gwenview and Krusader can use it too if they'd like.

What kind of functionality is it proposed to move to KIO? The whole dialog or backend only (i.e. code that is running after pressing Rename button)? I support making this available outside of Dolphin but the best way to do it is unclear.

Regarding the syntax, it needs some work, IMO. For example, how do I rename a.txt, b.txt, c.txt into 1name.txt, 2name.txt, 3name.txt? How do I insert a hash symbol into the file name? Things like this. It should be consistent. If I were working on this, I'd use Python string.format format (similar to what Gwenview Importer does) - it's very flexible, well designed and proven to work well over the years. Another option is to focus on KRename syntax compatibility. I believe if you invent a new syntax, it should be well justified, especially if we target to use it across KDE apps. What do you think about making the discussion broader?

To conclude, I'd like to thank you for working on this. The richer experience we have the better! Looking forward to seeing this integrated.

How's it going @emateli? This feature is too awesome to keep from the public! :)

We have a request in https://bugs.kde.org/show_bug.cgi?id=395405 for an additional token: the current directory name. Possibly also one for the full path to the current directory.

In D10698#257863, @nmel wrote:

It seems like a small tool independent of Dolphin to me.

Could be, but one of those small rename tools has to be baked in the application itself and since Dolphin's rename capabilities at the moment are not great, I thought this was an area that could use some work.

What kind of functionality is it proposed to move to KIO? The whole dialog or backend only (i.e. code that is running after pressing Rename button)? I support making this available outside of Dolphin but the best way to do it is unclear.

From my understanding, both.

Regarding the syntax, it needs some work, IMO. For example, how do I rename a.txt, b.txt, c.txt into 1name.txt, 2name.txt, 3name.txt? How do I insert a hash symbol into the file name?

That would be #name and there is a drop down menu that allows the user to insert tokens. The syntax is like this since the pound sign was already in use by Dolphin and the date tokens with % are used by Spectacle. Gwenview which you mentioned uses a different syntax as well. I'm open to suggestions on the format. Perhaps it could be something that all the applications could converge upon at some point instead of each having its own format. I personally think the Gwenview one looks slightly better and the additional verbosity it has is a non-issue.

The rest of the syntax for Find/Replace and Capture groups is simply the standard regular expression syntax.

In D10698#285135, @emateli wrote:

In D10698#257863, @nmel wrote:

Regarding the syntax, it needs some work, IMO. For example, how do I rename a.txt, b.txt, c.txt into 1name.txt, 2name.txt, 3name.txt? How do I insert a hash symbol into the file name?

That would be #name and there is a drop down menu that allows the user to insert tokens.

It won't work. It will produce a.txt, b.txt, c.txt according to the 3rd screenshot because #name stands for the full file name in the proposed syntax.
"How do I insert a hash symbol into the file name?" - is also a problem.

The syntax is like this since the pound sign was already in use by Dolphin and the date tokens with % are used by Spectacle. Gwenview which you mentioned uses a different syntax as well. I'm open to suggestions on the format. Perhaps it could be something that all the applications could converge upon at some point instead of each having its own format. I personally think the Gwenview one looks slightly better and the additional verbosity it has is a non-issue.

Great! To other people in the discussion: please share your opinion on the format. Let's move to python string.format syntax used by Gwenview if no objections. It solves the problems above.