MultiRename v1.8
MultiRename v1.8
Not much to say, yet another batch file renamer, written in Bash and Gtkdialog-0.8.4...
I used to use gFnRename, which is a great tool, but unfortunately it treats any string after the first dot as extension, so files like "my.file.txt" weren't processed as I wanted them to be.
MR does it differently (see Notes below).
Although I believe no major bugs are in the code, this is an initial release and I've been the only tester (for now), so it's better to take a careful look at "New Name" column before pressing the 'Commit' button and, at least in the initial period, work only on copies of important files.
And of course, please report any spotted bugs.
I wrote this app on Fatdog and briefly tested on TahrPup.
___________
Notes:
- MultiRename treats any string after the last dot as extension, but it can also recognize some common double extensions like .tar.gz, .tar.xz, etc.
- operations can be performed independently on basename or on extension or on both of them (base and extension are treated as one entity)
- operations are performed sequentially, just like they are arranged in the GUI (from top to bottom), i.e. if you select 'Prepend abc' and 'Case to Upper' options, 'Prepend' is performed first and then 'Case to' on the resulting filename: file -> abcfile > ABCFILE
- the 'offset' can be a negative number, e.g. '-1' is the position right after the last character, '-2' is the position before last character and so on
- if the resulting filename is the same as original, it won't be displayed in "New Name" column.
This is quite important to know, because even I caught myself a few times thinking that there must be something wrong with the code when nothing got displayed, until I realized the fact that the options I chose didn't actually change the name.
Known issues:
- files/dirs with newline (0x0a) in their names are not supported, but I did my best to handle everything else (like *`"|$\) properly.
But keep in mind that there are filesystems (e.g. vfat) that won't accept some special characters.
___________
NLS pet contains the following translations:
- German (L18L) [needs updating]
Have fun &
Greetings!
I used to use gFnRename, which is a great tool, but unfortunately it treats any string after the first dot as extension, so files like "my.file.txt" weren't processed as I wanted them to be.
MR does it differently (see Notes below).
Although I believe no major bugs are in the code, this is an initial release and I've been the only tester (for now), so it's better to take a careful look at "New Name" column before pressing the 'Commit' button and, at least in the initial period, work only on copies of important files.
And of course, please report any spotted bugs.
I wrote this app on Fatdog and briefly tested on TahrPup.
___________
Notes:
- MultiRename treats any string after the last dot as extension, but it can also recognize some common double extensions like .tar.gz, .tar.xz, etc.
- operations can be performed independently on basename or on extension or on both of them (base and extension are treated as one entity)
- operations are performed sequentially, just like they are arranged in the GUI (from top to bottom), i.e. if you select 'Prepend abc' and 'Case to Upper' options, 'Prepend' is performed first and then 'Case to' on the resulting filename: file -> abcfile > ABCFILE
- the 'offset' can be a negative number, e.g. '-1' is the position right after the last character, '-2' is the position before last character and so on
- if the resulting filename is the same as original, it won't be displayed in "New Name" column.
This is quite important to know, because even I caught myself a few times thinking that there must be something wrong with the code when nothing got displayed, until I realized the fact that the options I chose didn't actually change the name.
Known issues:
- files/dirs with newline (0x0a) in their names are not supported, but I did my best to handle everything else (like *`"|$\) properly.
But keep in mind that there are filesystems (e.g. vfat) that won't accept some special characters.
___________
NLS pet contains the following translations:
- German (L18L) [needs updating]
Have fun &
Greetings!
- Attachments
-
- multirename_NLS-1.7.pet
- Langpack (de).
- (1.92 KiB) Downloaded 461 times
-
- Screenshot.jpg
- (101.67 KiB) Downloaded 1118 times
-
- multirename-1.8.pet
- MD5: 58e46b95b4274d4096f9acf1f66e0276 multirename-1.8.pet
- (8.81 KiB) Downloaded 614 times
Last edited by SFR on Mon 13 Jun 2016, 14:16, edited 11 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Changelog
Version 1.0:
- initial release
Version 1.1:
- Fix: small bug in error handling.
- Removed the ability to go to parent directory using 'Backspace' key - checking the condition every time user presses arrow keys makes the browsing a bit too sluggish.
Additionally, with this feature removed MR will run (almost) perfectly with Gtkdialog-0.8.0.
Version 1.2:
- Fix: proper sorting of numbers within text (thanks to MochiMoppel)
Version 1.3:
- Preservation of items in "New Name" column (thanks to MochiMoppel)
Version 1.4:
- Fixed a typo (thanks to MochiMoppel)
- Added missing 'gettext' in one spot
- Column headers now clickable (thanks to MochiMoppel)
Version 1.4-1:
- Fixed a bug in pinstall.sh (thanks to 666philb)
Version 1.5:
- Fix: renaming didn't work if an item contained leading or trailing spaces
Version 1.6:
- Fix: revert gettext in one spot
- Enhancement: manual renaming of selected item (Right-Click or Shift+Enter)
Version 1.7:
- Manual editing: focus the destination field and fill it with old name if new name doesn't exist (thanks to MochiMoppel)
- Manual editing: the dialog now pops up under mouse pointer, not in the centre of the screen
- gettext fix (thanks to L18L)
- Added German translation to NLS pet (thanks to L18L)
Version 1.8:
- a bit faster Preview
- added keyboard shortcuts to 'Show hidden', 'Numeric sort', 'Preview' and 'Commit' buttons
- 'Old Name' column header has fixed initial width (300px), which means it doesn't auto-resize anymore, so even in case of long filenames the 'New Name' column is always visible
- added 'Numeric sort' togglebutton - it toggles the use of sort's '-V' switch.
It "resolves" the problem that with '-V' all numbers are sorted naturally, but unicode characters aren't.
Without '-V' it's the other way around. Now you can choose...
Version 1.0:
- initial release
Version 1.1:
- Fix: small bug in error handling.
- Removed the ability to go to parent directory using 'Backspace' key - checking the condition every time user presses arrow keys makes the browsing a bit too sluggish.
Additionally, with this feature removed MR will run (almost) perfectly with Gtkdialog-0.8.0.
Version 1.2:
- Fix: proper sorting of numbers within text (thanks to MochiMoppel)
Version 1.3:
- Preservation of items in "New Name" column (thanks to MochiMoppel)
Version 1.4:
- Fixed a typo (thanks to MochiMoppel)
- Added missing 'gettext' in one spot
- Column headers now clickable (thanks to MochiMoppel)
Version 1.4-1:
- Fixed a bug in pinstall.sh (thanks to 666philb)
Version 1.5:
- Fix: renaming didn't work if an item contained leading or trailing spaces
Version 1.6:
- Fix: revert gettext in one spot
- Enhancement: manual renaming of selected item (Right-Click or Shift+Enter)
Version 1.7:
- Manual editing: focus the destination field and fill it with old name if new name doesn't exist (thanks to MochiMoppel)
- Manual editing: the dialog now pops up under mouse pointer, not in the centre of the screen
- gettext fix (thanks to L18L)
- Added German translation to NLS pet (thanks to L18L)
Version 1.8:
- a bit faster Preview
- added keyboard shortcuts to 'Show hidden', 'Numeric sort', 'Preview' and 'Commit' buttons
- 'Old Name' column header has fixed initial width (300px), which means it doesn't auto-resize anymore, so even in case of long filenames the 'New Name' column is always visible
- added 'Numeric sort' togglebutton - it toggles the use of sort's '-V' switch.
It "resolves" the problem that with '-V' all numbers are sorted naturally, but unicode characters aren't.
Without '-V' it's the other way around. Now you can choose...
Last edited by SFR on Mon 13 Jun 2016, 14:18, edited 10 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Otsukaresama!
Don't know how to say this in English
Not surprisingly I didn't find bugs. I'm not really a suitable tester because I don't need this tool, which limits my eagerness to dig deeper.
Surely I've noticed the biggest improvement over gFnRename: The "Rename" button is now called "Preview". Good.
Something that in my view needs urgent fixing is the way selections are treated. After each preview the selection is lost, and if after a preview all files aren't manually reselected, the next preview will again destroy the selection. Very frustrating. See how gFnRename retains the selection and even allows adding files to the selection and then renaming only those added files. I've tried to achieve the same effect by removing your "destructive" cp -f $TMPDIR/list_main $TMPDIR/list_mod statement in the func_review and find the result much better, but not perfect. I'm sure you'll figure it out.
This brings me to my biggest problem with gFnRename and MultiRename: Both accept only directories, not files. Look at the screenshot. My task is to rename the single digits of the first 9 files in /abc to 2digits (1 to 01). Because of the strictly alphabetic sort order in gtkdialog it becomes already a nightmare to select those files in MultiRename. Losing this selection will trigger a barrage of unprintable curses.
I think it would be a great improvement if MultiRename could accept multiple files. This would eliminate the manual selection process, sorting problems and the danger of losing the selection. Everything in the list is the selection, very similar to the ROX bulk renamer.
Don't know how to say this in English
Not surprisingly I didn't find bugs. I'm not really a suitable tester because I don't need this tool, which limits my eagerness to dig deeper.
Surely I've noticed the biggest improvement over gFnRename: The "Rename" button is now called "Preview". Good.
Something that in my view needs urgent fixing is the way selections are treated. After each preview the selection is lost, and if after a preview all files aren't manually reselected, the next preview will again destroy the selection. Very frustrating. See how gFnRename retains the selection and even allows adding files to the selection and then renaming only those added files. I've tried to achieve the same effect by removing your "destructive" cp -f $TMPDIR/list_main $TMPDIR/list_mod statement in the func_review and find the result much better, but not perfect. I'm sure you'll figure it out.
This brings me to my biggest problem with gFnRename and MultiRename: Both accept only directories, not files. Look at the screenshot. My task is to rename the single digits of the first 9 files in /abc to 2digits (1 to 01). Because of the strictly alphabetic sort order in gtkdialog it becomes already a nightmare to select those files in MultiRename. Losing this selection will trigger a barrage of unprintable curses.
I think it would be a great improvement if MultiRename could accept multiple files. This would eliminate the manual selection process, sorting problems and the danger of losing the selection. Everything in the list is the selection, very similar to the ROX bulk renamer.
- Attachments
-
- gtkdialog_sortorder.png
- (212.9 KiB) Downloaded 1103 times
Hey MochiMochiMoppel wrote:Otsukaresama!
Don't know how to say this in English
Not surprisingly I didn't find bugs. I'm not really a suitable tester because I don't need this tool, which limits my eagerness to dig deeper.
Surely I've noticed the biggest improvement over gFnRename: The "Rename" button is now called "Preview". Good.
Thanks for testing & feedback!
Yeah, I know what you mean. I'll see what I can do about it.Something that in my view needs urgent fixing is the way selections are treated. After each preview the selection is lost, and if after a preview all files aren't manually reselected, the next preview will again destroy the selection. Very frustrating. See how gFnRename retains the selection and even allows adding files to the selection and then renaming only those added files. I've tried to achieve the same effect by removing your "destructive" cp -f $TMPDIR/list_main $TMPDIR/list_mod statement in the func_review and find the result much better, but not perfect. I'm sure you'll figure it out.
Hmm, I don't understand... In what sense?This brings me to my biggest problem with gFnRename and MultiRename: Both accept only directories, not files.
Ah, I didn't check the 'file-[number].ext' scenario, only '[number].ext' and thought 'sort -h' is good enough.Look at the screenshot. My task is to rename the single digits of the first 9 files in /abc to 2digits (1 to 01). Because of the strictly alphabetic sort order in gtkdialog it becomes already a nightmare to select those files in MultiRename. Losing this selection will trigger a barrage of unprintable curses.
Took me a while to figure it out, but turned out to be as easy as 'sort -fV'.
Will be fixed in next version.
I'm not sure I understand, again... You can quickly select all items with CTRL+A, if that's what you mean by "Everything in the list is the selection".I think it would be a great improvement if MultiRename could accept multiple files. This would eliminate the manual selection process, sorting problems and the danger of losing the selection. Everything in the list is the selection, very similar to the ROX bulk renamer.
Thanks again &
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
No, that's not what I mean. I mean that MultiRename now accepts only folders as arguments. The list in MultiRename will always show the content of a complete folder. Could be hundred of files, though the user is only interested in 10 files to rename. If he could select those 10 files in ROX, then drag&drop to MultiRename, this could mean that the resulting list in MultiRename contains only those 10 files. All of these files are to be renamed, no need to select anything within this list. The selection process is already finished when MultiRename receives the filespecs. This is how it is done in ROX bulk renamer.SFR wrote:I'm not sure I understand, again... You can quickly select all items with CTRL+A, if that's what you mean by "Everything in the list is the selection".
Here is a show stopper: MultiRename doesn't like foreign languages
< lies, rumors and false claims removed >
Last edited by MochiMoppel on Sat 03 Oct 2015, 12:08, edited 2 times in total.
As you can see I was highly inspired by gFnRename, but e.g. pRename also operates on whole directories (but gives you no option to work only on selected items).MochiMoppel wrote:No, that's not what I mean. I mean that MultiRename now accepts only folders as arguments. The list in MultiRename will always show the content of a complete folder. Could be hundred of files, though the user is only interested in 10 files to rename.
One problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.If he could select those 10 files in ROX, then drag&drop to MultiRename, this could mean that the resulting list in MultiRename contains only those 10 files. All of these files are to be renamed, no need to select anything within this list. The selection process is already finished when MultiRename receives the filespecs. This is how it is done in ROX.
But even this is highly problematic, because if you drop more than one file there, they're separated by spaces, so filenames with spaces will be splitted in two (or more).
On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..?
If I manage to preserve already renamed items, like it is in gFnRename, that won't be a problem anymore, I believe.
See screenshot.Here is a show stopper: MultiRename doesn't like foreign languages
Greetings!
- Attachments
-
- no, it's a problem of selected option ;).jpg
- (5.42 KiB) Downloaded 1030 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
pRename....that can hardly be a bechmark for you.SFR wrote:As you can see I was highly inspired by gFnRename, but e.g. pRename also operates on whole directories
This has nothing to do with gtkdialog. Arguments are handled by the script before entering gtkdialog. You call a function, now it's func_readdir, which prepares the list. I don't see a problem. Filenames with spaces should also be no obstacleOne problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.
I knew you would say this It's a question of workflow. More often than not I have the files already selected in ROX or at least "in focus" and want to do something with them. I don't want to start anew in a different application. If I would start the day with a "Let's rename some files today", then fire up your renamer and start selecting, only then you would be right. It wouldn't make a difference. Still would leave the problem of having unrelated files in the list. But it's your choice, I'm not in a position to tell you what you should do.On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..?
As for the show stopper: Sorry for that, the show can go on.
Ok, I just uploaded v1.2, but only with the 'sort' fix for now; have to really rethink how to properly implement preserving the preview of already renamed items...
Yes, dropping onto the app's icon or invoking from command line would work work, of course.
So, let's say it's a TO-DO with LOW priority.
[EDIT: Damn! I pressed 'Edit' instead of 'Quote' and entered a new post within this very post, deleting it. Hopefully I recreated it as it was.]
Greetings!
Oh, I thought you meant drag'n'dropping onto the window of already working application.MochiMoppel wrote:This has nothing to do with gtkdialog. Arguments are handled by the script before entering gtkdialog. You call a function, now it's func_readdir, which prepares the list. I don't see a problem. Filenames with spaces should also be no obstacleOne problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.
Yes, dropping onto the app's icon or invoking from command line would work work, of course.
Have to rethink that, too, but since I prefer the "browse" way, I think it would be too much hassle to maintain two approaches.I knew you would say this It's a question of workflow. More often than not I have the files already selected in ROX or at least "in focus" and want to do something with them. I don't want to start anew in a different application. If I would start the day with a "Let's rename some files today", then fire up your renamer and start selecting, only then you would be right. It wouldn't make a difference. Still would leave the problem of having unrelated files in the list. But it's your choice, I'm not in a position to tell you what you should do.On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..?
So, let's say it's a TO-DO with LOW priority.
[EDIT: Damn! I pressed 'Edit' instead of 'Quote' and entered a new post within this very post, deleting it. Hopefully I recreated it as it was.]
Don't worry, it did happen to me a few times, too.As for the show stopper: Sorry for that, the show can go on.
Greetings!
Last edited by SFR on Sat 03 Oct 2015, 19:46, edited 3 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Alright, I managed to implement that quite gracefully and everything seems to work just fine.me wrote:have to really rethink how to properly implement preserving the preview of already renamed items...
Btw, in order to remove a specific item from "New Name" column, it's just a matter of selecting it, unchecking everything on the right pane and clicking 'Preview' button.
Clicking the 'Refresh' button will remove them all.
First post updated.
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Much, much better! Good work!
Only minor points:
- I suggest that you set column-header-active to true. Might be useful to sort the 2nd column and have all renamed items at the top for further fine tuning, even if it means that the sorting is lost after a preview. Resorting is still easier than having scattered renamed files in the list.
- The warning after hitting Commit is frightening (and contains a typo ). A similar message, warning that all intended changes will be lost when the dialog shows Renamed items >0 and the user hits one of the top buttons would make the dialog almost fail safe.
Only minor points:
- I suggest that you set column-header-active to true. Might be useful to sort the 2nd column and have all renamed items at the top for further fine tuning, even if it means that the sorting is lost after a preview. Resorting is still easier than having scattered renamed files in the list.
- The warning after hitting Commit is frightening (and contains a typo ). A similar message, warning that all intended changes will be lost when the dialog shows Renamed items >0 and the user hits one of the top buttons would make the dialog almost fail safe.
Very useful script. Works well with cyrillic file names.
Thank you, SFR!
Thank you, SFR!
- Attachments
-
- multirename1.3.jpg
- (87.92 KiB) Downloaded 925 times
Hmm, on a second thought it might be useful, indeed. Done.MochiMoppel wrote:- I suggest that you set column-header-active to true. Might be useful to sort the 2nd column and have all renamed items at the top for further fine tuning, even if it means that the sorting is lost after a preview. Resorting is still easier than having scattered renamed files in the list.
Realy? Fixed.- The warning after hitting Commit is frightening (and contains a typo ).
It's not a bad idea, but introduces some technical difficulties regarding 'Show hidden' togglebutton - if a user has chosen 'No', the button gets toggled anyway (although hidden files are not shown).A similar message, warning that all intended changes will be lost when the dialog shows Renamed items >0 and the user hits one of the top buttons would make the dialog almost fail safe.
And even if I employ some tricks with refreshing, in order to reinstate previous state of the button, in such a case the warning message is displayed twice in a row.
Same would happen with checkbox, btw.
At this moment I don't see an elegant solution for this...
Thanks, Toni!saintless wrote:Very useful script. Works well with cyrillic file names.
Thank you, SFR!
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Could be a bit "unfriendly" when preview happily produces invalid duplicates and only when the user hits Commit he is informed that "One or more names are duplicated". Finding the duplicates could be a nuisance. Some kind of hint before hitting Commit might be better. Maybe something like this:
The best solution I've seen so far would give a warning ("n files will not be renamed because of duplicate names. Proceed anyway?". If the user confirms the renaming proceeds, but leaves the unprocessed files together with their conflicting new names in the list. The user then can concentrate on these remaining files and change the pattern until finally all files are successfully renamed (indicated by an empty New Names column).
- [ "$NEW_NAME" = "$OLD_NAME" ] && NEW_NAME=""
[[ $(<$TMPDIR/list) == *$NEW_NAME$'\n'* ]] && NEW_NAME="$NEW_NAME (DOUBLE!)"
The best solution I've seen so far would give a warning ("n files will not be renamed because of duplicate names. Proceed anyway?". If the user confirms the renaming proceeds, but leaves the unprocessed files together with their conflicting new names in the list. The user then can concentrate on these remaining files and change the pattern until finally all files are successfully renamed (indicated by an empty New Names column).
- Attachments
-
- duplicate_warning.png
- (28.29 KiB) Downloaded 912 times
@Mochi: Both methods would be problematic, because conflicts can occur not only in "New Name" column alone, but also in relation between "New Name" & "Old Name", e.g. if you rename only the first file:
Old | New
file -> file2
file2
Greetings!
Old | New
file -> file2
file2
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
hi SFR,
i'm getting this error on the pinstall.sh
i'm getting this error on the pinstall.sh
Code: Select all
multirename-1.4/pinstall.sh: line 23: syntax error near unexpected token `fi'
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Thanks, Phil. Fixed and reuploaded.666philb wrote:hi SFR,
i'm getting this error on the pinstall.shCode: Select all
multirename-1.4/pinstall.sh: line 23: syntax error near unexpected token `fi'
Btw, the error (caused by a lonely 'fi' at the very end of the script) wasn't disturbing the proper execution during normal install, but probably could break it while building with Woof-CE...
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Version 1.6
I added an option to manually rename selected item.
Just right-click (or shift+enter) it and appropriate dialog will show up.
Greetings!
I added an option to manually rename selected item.
Just right-click (or shift+enter) it and appropriate dialog will show up.
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Hi SFR, manual editing ... it's getting sophisticated
I was a bit confused by the dialog. My proposal:
- Avoid the impression that the first field is editable
- Always fill the second field with a default. Makes editing much easier
- Put the focus on the second field, not the first
This worked better for me:
I was a bit confused by the dialog. My proposal:
- Avoid the impression that the first field is editable
- Always fill the second field with a default. Makes editing much easier
- Put the focus on the second field, not the first
This worked better for me:
- <frame '$(gettext "Rename the item manually")'>
<hbox>
<entry editable="false" has_frame="false">
<variable>varMANUAL_OLD</variable>
<input file>"'${TMPDIR}/manual_old'"</input>
</entry>
<pixmap stock-icon-size="3"><input file stock="gtk-go-forward"></input></pixmap>
<entry has_focus="true">
<variable>varMANUAL_NEW</variable>
<input>N="'$(<${TMPDIR}/manual_new)'"; [ "$N" ] && echo $N || echo "'$(<${TMPDIR}/manual_old)'"</input>
</entry>
</hbox>
</frame>
Hi MochiMochiMoppel wrote:Hi SFR, manual editing ... it's getting sophisticated
Well, suspiciously often there's a black sheep in a group of similarily named files:
Manual editing is quite helpful in such cases.01-somename
02-another
03 -black sheep
04-this one's normal
Hmm, 'has-focus' crossed my mind - I don't know why didn't I use it.I was a bit confused by the dialog. My proposal:
- Avoid the impression that the first field is editable
- Always fill the second field with a default. Makes editing much easier
- Put the focus on the second field, not the first
This worked better for me:
<frame '$(gettext "Rename the item manually")'>
<hbox>
<entry editable="false" has_frame="false">
<variable>varMANUAL_OLD</variable>
<input file>"'${TMPDIR}/manual_old'"</input>
</entry>
<pixmap stock-icon-size="3"><input file stock="gtk-go-forward"></input></pixmap>
<entry has_focus="true">
<variable>varMANUAL_NEW</variable>
<input>N="'$(<${TMPDIR}/manual_new)'"; [ "$N" ] && echo $N || echo "'$(<${TMPDIR}/manual_old)'"</input>
</entry>
</hbox>
</frame>
Anyway, I like the changes and they will be in next version (thanks!), with slight modification of <input>...</input> part, because some characters in names (especially <) can break it, so we have to use cat instead:
Code: Select all
<input>[ -s "'${TMPDIR}/manual_new'" ] && cat "'${TMPDIR}/manual_new'" || cat "'${TMPDIR}/manual_old'"</input>
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Beware, this will make you a candidate for the Useless Use of Cat AwardSFR wrote:we have to use cat instead
If you need to employ a (useful) cat, make it a cat with a tail:
Code: Select all
<input>cat "'${TMPDIR}/manual_old'" "'${TMPDIR}/manual_new'" | tail -1</input>
In my version '-n' must not be added to echo "$MANUAL_OLD", only to echo -n "$MANUAL_NEW", otherwise cat will not work as expected. It seems to work, but I haven't tested with all your odd filenames, so I leave it as an idea.(of course I also added '-n' to both 'echo -n "$MANUAL... > $TMPDIR/manual...' lines)