[Gprename-users] new gprename2.0 replace with a newer one

[Zurd <zu...@ya...>]

I just finished doing the improvements with the selection.
If you select lines and try to rename but it doesn't work
because a file already exist then your selection will keep
being selected.  I replace gprename-2.0.tar.bz2 with the one
I just finished at :
https://sourceforge.net/project/showfiles.php?group_id=40094&package_id=32230

I made some minor modifications, like it will now install
in /usr/local/share instead of /usr/share

I finished the newest ebuild for Gentoo that I submitted at :
http://bugs.gentoo.org/show_bug.cgi?id=92225

GPRename is now listed in the Links section of gtk2-perl.sourceforge.net
as a software that use GTK2-Perl, it's the last one at :
http://gtk2-perl.sourceforge.net/links
(though right now the link doesn't work)

I changed the screenshot that you see at :
https://sourceforge.net/projects/gprename

Finally I change the website to reflect the new GPRename 2.0 at :
http://gprename.sourceforge.net


As for listing all the files that are in conflict with existing files
in a simple message window or showing them with different colors, I 
could have done it easily with the way gprename used to rename files, 
but that way took like 15 seconds to rename 500 files.  For performance 
issue, I'll keep one message window for one error, at least now your 
selection won't disappear ;)


Zurd



--- Lacrocivious Acrophosist <alt...@ya...> a écrit :

> The features I've used have worked very well, and
> while I can't say I've batched enough files to verify
> the speed increase, I can say that the renaming
> operations have appeared to be instantaneous.
> 
> The switch to courier may not look ss good in the UI,
> but a fixed pitch font is definitely an asset in the
> actual work areas where the filenames appear, so I
> applaud this change.
> 
> There is one thing I would like to see, but which I
> suspect needs to wait for another release. That is the
> handling of multiple selections upon encountering an
> existing filename conflict with the selected renaming
> operation.
> 
> Specifically, if I have chosen a few dozen files to
> rename, particularly in scattered groups rather than
> contiguous entries, if one or more of the filenames I
> wish to rename conflicts with existing name(s), then
> upon acknowledging the error dialog I lose all my
> selection markers. This means I have to reselect,
> avoiding the conflicting file.
> 
> If there was another conflicting name beyond the
> first, then I will get another conflict error on my
> second attempt, and so lose my selections again. This
> repeats until my selections no longer contain any
> conflicting filenames. Sometimes this takes quite a
> few selection passes ;-)
> 
> At some point, it would be useful to provide a dialog
> which lists *all* the conflicting files within the
> selected range(s). Further, upon aborting the rename
> operation, it would be useful to retain the selection
> highlights so that the offending files can be
> deselected either singly or in ranges, just as they
> may have been selected in the beginning, singly or in
> ranges.
> 
> Perhaps the conflicting files might be highlighted
> differently from 'normal' selections in the list,
> making it more obvious which ones need deselecting.
> 
> I suppose this requires a level of temporary retention
> beyond that presently used, and therefore may be an
> extremely non-trivial piece of coding to change.
> 
> Overall I am very pleased with GPRename 2.0 and have
> adopted it into my 'cold dead fingers' list of
> utilities... meaning 'you'd have to pry this tool from
> my cold dead fingers' to take it away from me ;-)

__________________________________________________
Do You Yahoo!?
En finir avec le spam? Yahoo! Courriel vous offre la meilleure protection possible contre les messages non nollicités 
http://mail.yahoo.ca Yahoo! Courriel