gprename-users — Mailing list for everyone (users and developers)

[Gprename-users] RE : Re: RE : Polish updated translation for gprename

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

Here it is :

r33 | Zurd | 2006-12-30 22:33:52 -0500 (Sat, 30 Dec 2006) | 1 line
added new polish translation, fixed more warnings message

If you want to be in the Credits, just tell me your name or alias and
I'll add you ;-)


Thanks a lot


--- bg...@ws... a écrit :

> >
> > --- Zurd <zu...@ya...> a écrit :
> >
> > Nice work! Tough you used an old version of the language, much have
> > changed.
> >
> > Could you use the newest one in CVS and translate that one instead?
> >
> > You can get the newest one in the languages directory at :
> > http://gprename.svn.sourceforge.net/viewvc/gprename/
> 
> I am sending one more time the translation cause previous has some small
> mistakes.
> 
> Bartek


__________________________________________________
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  

[Gprename-users] new changes

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

Just to inform that there's been some changes in GPRename in CVS,
mostly the Undo function is now back and functional, next I'll just
make the renaming faster and make an official release of GPRename 2.0


For the changelog from the "svn --verbose log" command : 

fixed renaming on VFAT partition and updated Undo function
undo function re-implemented
add warning dialog if log is more than 100K
minor change in the way it prints to the log
updated dialog window, log and about
removed ==TRUE for the options, was causing warning messages
added shadow_type to dialog window
hide recursive, changed $true to TRUE see use Glib qw;
Added option : Trim double, start and end spaces
Got rid of warnings


__________________________________________________
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  

[Gprename-users] RE : Polish updated translation for gprename

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

Nice work! Tough you used an old version of the language, much have changed.

Could you use the newest one in CVS and translate that one instead?

You can get the newest one in the languages directory at :
http://gprename.svn.sourceforge.net/viewvc/gprename/

Thans


--- bg...@ws... a écrit :

> Hi,
> 
> I updated Polish translation of gprename, use it if you want to.
> 
> Merry Christmas and Happy New Year
> Bartek

__________________________________________________
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  

[Gprename-users] Polish updated translation for gprename

[<bg...@ws...>]

Hi,

I updated Polish translation of gprename, use it if you want to.

Merry Christmas and Happy New Year
Bartek

[Gprename-users] RE : Re: gtk-perl deprecated on Gentoo

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

> I have a question: While I understand the meaning 
> of 'Show recursively' in a general sense, how does
> this option apply to or change display in GPRename?

The option about recursive was added in version 1.3,
since I think it's the version you used the most you can
always try and see what changes it will do to the display 
exactly.

I think I'll do the same thing, do not show the path in the
name or new name column and sort all the names with their
paths.


> On a related note from the 'to do' list, I would
> mention how dangerous any recursive action can be, but
> I'm sure you know that and will take care to make
> recursive naming as safe as possible. The Undo
> function, in my opinion, would be essential to
> recursive operation.

Indeed, the recursive could be real dangerous, when I'll
add it I'll just call the log function instead of the rename
to see if it works great before doing any actual renaming,
that'll be safe enough :-)

__________________________________________________
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  

Re: [Gprename-users] gtk-perl deprecated on Gentoo

[Lacrocivious A. <alt...@ya...>]

--- Zurd <zu...@ya...> wrote:

> I think it'll be a good thing to release GPRename
> 2.0 very soon, even
> if some options are not implemented yet, like
> recursive renaming.
> It doesn't do any good to let GPRename 1.7 as the
> latest release if
> no one can use it.
> 
> Let's try to release GPRename 2.0 in a week.

I agree. The program may not yet be perfect, but it is
certainly good enough and already appears to be better
than the old 1.7. ... But, make that a rather flexible
'week' ;-)

Nothing screams 'Abandoned!' like an application
dependent upon widely deprecated libraries. It is
important to show that GPRename is not abandoned.

> I've also done for now some minor modifications :
> - changed some interpreted strings to literal
> - about dialog has changed
> - modifications on the $str_tips_* variable in the
> languages files
> - got rid of unitialized value warning when opening
> GPRename when
> ~/.gprename was not existing

Having just updated to svn revision 24 and used it
briefly, I like the improvements. I have not tested
the leading/trailing space removal, however.

I have a question: While I understand the meaning 
of 'Show recursively' in a general sense, how does
this option apply to or change display in GPRename?

On a related note from the 'to do' list, I would
mention how dangerous any recursive action can be, but
I'm sure you know that and will take care to make
recursive naming as safe as possible. The Undo
function, in my opinion, would be essential to
recursive operation.

The log is nice. Could be very useful.

Thanks again for your good work on this project ;-)



 
____________________________________________________________________________________
Sponsored Link

Online degrees - find the right program to advance your career.
Www.nextag.com

[Gprename-users] new revision 23

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

Modified the "Trim spaces" option to "Trim doubles, start and end spaces"

If used 
" foo" 
"foo " 
"foo    "
 will be renamed to "foo"

which is done by the new function : trim_spaces_and_return

__________________________________________________
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  

[Gprename-users] gtk-perl deprecated on Gentoo

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

Just like Fedora Core that set gtk-perl deprecated, the same thing
has been done with Gentoo.  Gtk-perl has been masked on the 16 of november
in the portage tree.  It is now asking me to remove it ;-)

I think it'll be a good thing to release GPRename 2.0 very soon, even
if some options are not implemented yet, like recursive renaming.
It doesn't do any good to let GPRename 1.7 as the latest release if
no one can use it.

Let's try to release GPRename 2.0 in a week.


I've also done for now some minor modifications :
- changed some interpreted strings to literal
- about dialog has changed
- modifications on the $str_tips_* variable in the languages files
- got rid of unitialized value warning when opening GPRename when
~/.gprename was not existing



__________________________________________________
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  

[Gprename-users] New revision 18

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

New :

1) Mnemonics on buttons and menus (only for english and french)
It's the underscore under a letter that you can call with ALT-letter

2) Log : each rename will be output to ~/gprename_log
You can view it or clear it from "Options / View log..."

3) Fixed the on/off on the Rename and Preview button wether 
Automatic Preview is selected or not.
For example, if Automatic Preview is not selected, you can't click
Rename if you didn't click Preview.  Just like it was before with 
version 1.7 and older.






__________________________________________________
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  

[Gprename-users] RE : Re: New Revision 17

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

> Whether intended or not, Revision 17 breaks the svn
> checkout command I have been using. Specifically, the
> command:
> svn checkout https://svn.sourceforge.net/svnroot/gprename /usr/local

As I said, I'm not an expert (yet) of SVN, I don't know if what
I did was the right thing to do.  But, on this page here :
https://sourceforge.net/svn/?group_id=40094
Which is the GPRename page about SVN, it says :

"This project's SourceForge.net Subversion repository can be 
checked out through SVN with the following instruction set :"
svn co https://svn.sourceforge.net/svnroot/gprename gprename

This command will create the gprename folder and put everything 
from SVN in it.

Also, I don't think you should use the svn command with the path 
/usr/local, you should first use it in /home/user then run the install 
command from /home/user/gprename, of course nothing stops you from
calling the checkout with /usr/local/gprename but it's not meant to
be used that way ;-)


> This is puzzling. I have wondered why there are not a
> great many participants in at least the discussion of
> GPRename. Perhaps -- this is only a guess -- many
> linux users have learned the command line arguments to
> write their own scripts or use one of several that
> turn up in 'batch file rename' searches.

Who knows why there isn't many participants, probably
because of a few reasons, like there isn't that much
people using linux, I don't even know if GPRename could
be working on Windows or OS X.  That'll be something to
look at when GPRename 2.0 is final.  Probably also because
GPRename isn't in an RPM format, nor in the Portage tree of
Gentoo (.ebuild), nor in the Debian release (.deb) or
the fact that gtk-perl is kind of deprecated which the last
release of GPRename is using.

One interesting page to look at is the statistics of gprename :
https://sourceforge.net/project/stats/?group_id=40094&ugn=gprename
About 80 web page hits and 2-3 downloads per day.

It'll be interesting to see if it ever raise when GPRename 2.0
will be out :-)


> Because GPRename and KRename are the only two GUI
> front ends I can remember seeing for these functions,
> I would have expected a great deal more participation.
> Even with mastery of command line arguments and/or
> scripts to do the same job GPRename does, there is for
> me no genuine comparison. Those of us who are more
> visually oriented prefer to see what we're doing, even
> if we know how to do the job without the graphic
> representation.

Me too, in the searches I've seen, KRename showed up first,
but I really hated it, it might be very powerful, but it's
sure not user-friendly.  I think it's aimed for a developer,
but not a end-user.  I don't even remember seeing another
one except krename and gprename, needless to say on Windows
I found and tested about 10 of them, there is so many :-)


If you have any other suggestions for gprename, please be my
guest!

__________________________________________________
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  

Re: [Gprename-users] New Revision 17

[Lacrocivious A. <alt...@ya...>]

First, regarding your speed improvements for the
actual renaming function, especially for large numbers
of files, I regret that I haven't had and probably
won't have a chance to test this for some days.
However, I applaud your efforts to make the utility
leaner and meaner ;-)


--- Zurd <zu...@ya...> wrote:

> There it's done :
> http://gprename.svn.sourceforge.net/viewvc/gprename/
> We're already at revision 17 though, I kind of
> messed up the
> deletion of the gprename-1.7 folder and had to do it
> a few times, 
> I'm really new to this SVN stuff and I still didn't
> finish the SVN 
> handbook :>

Whether intended or not, Revision 17 breaks the svn
checkout command I have been using. Specifically, the
command:

svn checkout
https://svn.sourceforge.net/svnroot/gprename
/usr/local

...does delete the old /usr/local/gprename-1.7
directory and its contents, but fails to create a new
/usr/local/gprename directory in its place. Thus, the
files and directories are partially written to
/usr/local ... partly, because the operation fails
when  attempting to create /usr/local/bin, which
already exists. Subsequent files are not copied.

I manually created /usr/local/gprename and altered the
svn command to:

svn checkout
https://svn.sourceforge.net/svnroot/gprename
/usr/local/gprename

...which works as I -- and I suspect, you -- intended.


> > Your 'automatic preview' option selection sounds
> fine
> > to me. That way we could toggle the feature on and
> off
> > at will.
> 
> Added in the last revision, see Options / Automatic
> preview

Thanks very much. This option toggle restores the
old-style operation which I prefer for most use, while
offering an easy on-the-fly change to the automatic
preview which is perfect for certain situations.

> > Also, please remember I am only one user, making
> one
> > user's suggestions ;-)
> 
> True, but since you're almost the only one to
> actually make
> a suggestion, I'll follow your advices because I
> have no idea
> what other people are thinking :-)

This is puzzling. I have wondered why there are not a
great many participants in at least the discussion of
GPRename. Perhaps -- this is only a guess -- many
linux users have learned the command line arguments to
write their own scripts or use one of several that
turn up in 'batch file rename' searches.

Because GPRename and KRename are the only two GUI
front ends I can remember seeing for these functions,
I would have expected a great deal more participation.
Even with mastery of command line arguments and/or
scripts to do the same job GPRename does, there is for
me no genuine comparison. Those of us who are more
visually oriented prefer to see what we're doing, even
if we know how to do the job without the graphic
representation.

As I mentioned before, I don't understand why
GPRename's functions are not already a part of
Konqueror and Nautilus ;-)




 
____________________________________________________________________________________
Sponsored Link

Don't quit your job - take classes online
www.Classesusa.com

[Gprename-users] New Revision 17

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

> As for me, I think I should delete the 1.7 in the
> SVN repositery so it only shows "gprename", meaning : 
> that's the latest code. Because working on GPRename 2.0 
> in a 1.7 folder is indeed confusing.

> I agree. I believe it would be a good idea to simplify
> the directory name.

There it's done : http://gprename.svn.sourceforge.net/viewvc/gprename/
We're already at revision 17 though, I kind of messed up the
deletion of the gprename-1.7 folder and had to do it a few times, 
I'm really new to this SVN stuff and I still didn't finish the SVN 
handbook :>


> As for remembering position, in my view this isn't
> very important, and can be put off indefinitely.
> Opening in the middle of the screen (like WinOS tends
> to do) more often than not covers up something you
> need to see. I say let the OS or window manager take
> care of that. In KDE, opening position seems to be
> dependent upon some kind of rotating quadrant
> selector, so each app loads clockwise from the last
> loaded.

Very well said, so let's not implement this.


> But I could always put back the "No Preview" option,
> instead we could call it "Automatic preview", use it or do not
> use it.  If you do not use it, you'll have to click the Preview
> button.  I could put that one by default when the user opens the
> application for the first time.  I guess that'll be okay?

> Your 'automatic preview' option selection sounds fine
> to me. That way we could toggle the feature on and off
> at will.

Added in the last revision, see Options / Automatic preview


> Also, please remember I am only one user, making one
> user's suggestions ;-)

True, but since you're almost the only one to actually make
a suggestion, I'll follow your advices because I have no idea
what other people are thinking :-)


__________________________________________________
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  

[Gprename-users] Performance with GPRename 2.0 - Revision 11

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

> Perhaps I was not clear. I meant to say that v2.0
> loads *faster* than the old versions, particularly
> faster than 1.3. As for operation on files, I haven't
> noticed a significant difference, but v2.0 'feels'
> faster overall.

I just installed version 1.3 to see the difference, 
it's about the same thing really, both opens with around
1-2 seconds of delay, but I think it's possible that 2.0 
feels faster because I'm now using $window->show_all(), 
instead of showing every items one by one (button, menu item, 
radio button, entry box,etc.), perl shows everything in one 
shot, so we're not seeing items created one by one, it's all
appearing together.


Now with the operation of files, that is quite interesting
actually.  I used my watch as a timer and renamed 300 files,
it took 30 seconds, it seemed that the application was frozen
but it was still processing.  30 seconds is a long time.  So
I've gone into the function of check_before_renaming and done
some modification, now it's taking half of the time to rename
the 300 files, so 15 seconds.  A nice improvement.  You will not
see how slow it is if you rename only a few files.  Here's what
my latest test shows when renaming :
100 files : 3 seconds
200 files : 8 seconds
250 files : 11 seconds
300 files : 15 seconds

But still... it is really troublesome, some people might want to rename
10,000 files and having to wait maybe 5 minutes for it is completely
unnaceptable.

So I just tought of a new way that would be much faster to do the
renaming but I will have to implement the undo function first. Here's what
the new function will do :
Check if the file with the new name already exist, if not, rename and pass
to the second file.
If it ever sees a file with the new name that already exists, print an error 
message that the renaming cannot be done because of the error and call the 
undo function.  So it'll be like no renaming has been done.

This was added in the To Do.

__________________________________________________
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  

Re: [Gprename-users] New Revision 11

[Lacrocivious A. <alt...@ya...>]

--- Zurd <zu...@ya...> wrote:

> And here's a few answers :)
> 
> (1) About the revision number :
> Each revision of each files is shown on the SVN
> webpage
> at :
> http://gprename.svn.sourceforge.net/viewvc/gprename/

Thanks. I wasn't aware of (or had forgotten about)
that page.


> (2) "Also I should learn to refer to GPRename 2.0,
> not 1.7"
> Please :) 
> As for me, I think I should delete the 1.7 in the
> SVN repositery
> so
> it only shows "gprename", meaning : that's the
> latest code. Because
> working on GPRename 2.0 in a 1.7 folder is indeed
> confusing.

I agree. I believe it would be a good idea to simplify
the directory name.

> (3) About full-screen :
> That's funny, I have the same preference but the
> other
> way around, I want my application to open always in
> full screen and I dislike the one that never open up
> in full screen :-)

This merely proves how vastly superior my own
intelligence, beauty, taste and fashion sense are than
your own! ;-)

> Nonetheless I added an option, by default, GPRename
> will now
> open in 640x480. Then resize it, bigger, smaller or
> even
> maximize, quit the application (file/quit, close
> button, alt+f4,
> whatever) and open it up again, it'll show with the
> size you
> just choose.  I didn't save the position of the
> window though.
> But should I?  Would it be useful or a nuisance?  Or
> maybe open
> up the application centered in the screen? Or leave
> it like that?

Wonderful! The application does remember its size now.
My preferred size is about 900 x 500 usually, and this
 makes it possible to avoid that every-launch
adjustment.

As for remembering position, in my view this isn't
very important, and can be put off indefinitely.
Opening in the middle of the screen (like WinOS tends
to do) more often than not covers up something you
need to see. I say let the OS or window manager take
care of that. In KDE, opening position seems to be
dependent upon some kind of rotating quadrant
selector, so each app loads clockwise from the last
loaded.

> (4)
> Yeah, it's kind of annoying to always see the
> preview of names even if
> you're just browsing, it's kind of weird, but
> honestly I
> prefer it that way, it's much faster than having to
> hit the
> "Preview" button all the time.  

See 'intelligence, beauty, taste and fashion sense',
above ;-)

> But I could always put back the "No Preview" option,
> instead we
> could call it "Automatic preview", use it or do not
> use it.
> If
> you do not use it, you'll have to click the Preview
> button.  I could
> put that one by default when the user opens the
> application for the
> first time.  I guess that'll be okay?

Your 'automatic preview' option selection sounds fine
to me. That way we could toggle the feature on and off
at will.

Also, please remember I am only one user, making one
user's suggestions ;-)

> (5) Default opening directory :
> Yeah that would really be useful, it was there with
> GPRename 1.7, but since I change the code of the
> Tree Browser,
> I have to redo it all again and I'm really having
> trouble with
> it right now :(

Not to worry. Let that one sort out later. The older
versions defaulted to the user home directory which I
found just as irritating, so actually starting with /
is just fine.


> (6) Load time :
> So GPRename 2.0 is slower to load than with previous
> version?
> I don't think you're talking about the load time
> when you
> open up the application, since they both seems to be
> around the
> same time, like 1-2 second :-)

Perhaps I was not clear. I meant to say that v2.0
loads *faster* than the old versions, particularly
faster than 1.3. As for operation on files, I haven't
noticed a significant difference, but v2.0 'feels'
faster overall.

The old versions loaded pretty quickly on my systems,
but there was an annoying bouncing icon that persisted
for about 30 seconds. I'm pretty sure it was just a
failure to notify Gtk that 'we're finished loading'
but it was still a nuisance. Your new version doesn't
have that problem.

Thank you again for your fast response and bug fixes
;-)



 
____________________________________________________________________________________
Sponsored Link

$200,000 mortgage for $660/ mo - 
30/15 yr fixed, reduce debt - 
http://yahoo.ratemarketplace.com

[Gprename-users] New Revision 11

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

And here's a few answers :)=0A=0A(1) About the revision number :=0AEach rev=
ision of each files is shown on the SVN webpage=0Aat : http://gprename.svn.=
sourceforge.net/viewvc/gprename/=0AMuch more convenient to look at this one=
 than the .svn/entry=0Afile=0A=0A=0A(2) "Also I should learn to refer to GP=
Rename 2.0, not 1.7"=0APlease :) =0AAs for me, I think I should delete the =
1.7 in the SVN repositery=0Aso=0Ait only shows "gprename", meaning : that's=
 the latest code. Because=0Aworking on GPRename 2.0 in a 1.7 folder is inde=
ed confusing.=0A=0A=0A(3) About full-screen :=0AThat's funny, I have the sa=
me preference but the other=0Away around, I want my application to open alw=
ays in=0Afull screen and I dislike the one that never open up=0Ain full scr=
een :-)=0A=0ANonetheless I added an option, by default, GPRename will now=
=0Aopen in 640x480. Then resize it, bigger, smaller or even=0Amaximize, qui=
t the application (file/quit, close button, alt+f4,=0Awhatever) and open it=
 up again, it'll show with the size you=0Ajust choose.  I didn't save the p=
osition of the window though.=0ABut should I?  Would it be useful or a nuis=
ance?  Or maybe open=0Aup the application centered in the screen? Or leave =
it like that?=0ARight now it opens at the upper-left of my screen.=0A=0ATo=
=0Ahave been able to resize the window to 640x480 when it open up by=0Adefa=
ult now, I had to change the width of two Entry fields in Numeric.=0AIt's s=
maller than before.=0A=0AAlso, there's now a new option, call "fullscreen",=
 like the fullscreen=0Aoption all web browsers have (F11).  It's in the opt=
ion menu.=0AOf course if you choose fullscreen and quits, next time you ope=
n it up it will show in fullscreen.=0A=0A=0A(4)=0AYeah, it's kind of annoyi=
ng to always see the preview of names even if=0Ayou're just browsing, it's =
kind of weird, but honestly I=0Aprefer it that way, it's much faster than h=
aving to hit the=0A"Preview" button all the time.  =0A=0ABut I could always=
 put back the "No Preview" option, instead we=0Acould call it "Automatic pr=
eview", use it or do not use it.=0AIf=0Ayou do not use it, you'll have to c=
lick the Preview button.  I could=0Aput that one by default when the user o=
pens the application for the=0Afirst time.  I guess that'll be okay?=0A=0A=
=0A(5) Default opening directory :=0AYeah that would really be useful, it w=
as there with=0AGPRename 1.7, but since I change the code of the Tree Brows=
er,=0AI have to redo it all again and I'm really having trouble with=0Ait r=
ight now :(=0A=0A=0A(6) Load time :=0ASo GPRename 2.0 is slower to load tha=
n with previous version?=0AI don't think you're talking about the load time=
 when you=0Aopen up the application, since they both seems to be around the=
=0Asame time, like 1-2 second :-)=0A=0AI=0Athink you mean the renaming of m=
any files, which is quite=0Atime-consuming, this is all because of the new =
function that I've done=0A: "check_before_renaming", there's got to be some=
=0Aoptimisations I can do in there to make it faster because, yes,=0Ait is =
really slow right now :(=0A=0AI put some files in a folder, about 300 and r=
ename them all=0Anumerically, took like 20 seconds.  Then I change the code=
 of=0AGPRename to not use the check_before_renaming function, the renaming =
was done in about 1 second ;-)=0AAdded in the To Do=0A=0ASo Revision 11 is =
now available in SVN.with the new option fullscreen and the preferences for=
 the size of the window.=0A=0A=0A=0A=0A----- Message initial ----=0ADe : La=
crocivious Acrophosist <alt...@ya...>=0A=C0 : Zurd <zu...@ya...=
>; gpr...@li...=0AEnvoy=E9 le : jeudi 16 novembre 2=
006, 11 h 39 min 52 s=0AObjet : [Gprename-users] Re :  Bug in svn revision =
9 on FC4=0A=0AVersion 10 appears to have fixed this selection=0Aproblem. In=
 tests today only those files selected for=0Arenaming were actually renamed=
. Thank you!=0A=0ABy the way, the Perl version already installed on the=0AF=
C4 box before adding perl-Gtk2 and perl-Glib is=0Aperl-5.8.6-24 (perl.i386)=
.=0A=0AI have a handful of observations:=0A=0A(1) Apart from reading .../.s=
vn/entries I don't see a=0Away to discover which version is currently insta=
lled.=0A=0A(2) I was in error when I claimed revision 9 worked on=0AFC6. I =
had forgotten to run gprename-install.sh after=0Athe revision 9 svn checkou=
t. Also I should learn to=0Arefer to GPRename 2.0, not 1.7.=0A=0A(3) Person=
al preference: I almost never run any=0Aapplication full-screen, and it is =
one of my pet=0Ahatreds that I dislike any program opening=0Afull-screen, *=
especially* when I have previously=0Aresized it not to be. Perhaps an optio=
n to remember=0Aprevious state, or one to open to a smaller window=0Ashould=
 remembering state be difficult with Gtk, would=0Abe useful.=0A=0A(4) Thoug=
h I am trying to get used to the 'always=0Alive' preview state, I must say =
that while it is nice=0Ato see changes on the fly, I find the *always* live=
=0Anature disconcerting, because it affects view of every=0Afile in the dir=
ectory. Might this be changed to an=0Aon/off toggle, or set to display only=
 for the file(s)=0Aselected?=0A=0A(5) A default opening directory, or an 'o=
pen in last=0Adirectory' option may be useful.=0A=0A(6) For whatever reason=
, load time for GPRename 2.0 is=0Amuch reduced over previous versions.=0A=
=0A(7) Having enjoyed the ride during cvs/svn type=0Adevelopment paths befo=
re, I am always aware of the=0Apossibility that programs under development =
may crash=0Awith horrible collateral damage, but your caution=0Aabout using=
 beta software is appreciated ;-)=0A=0A=0A=0A=0A--- Zurd <zu...@ya...> =
wrote:=0A=0A> Thansk for the dependencies information, I added in=0A> the R=
EADME file for the new GPRename : =0A> Requirements   : Perl, Perl-Gtk2 and=
 Perl-Glib=0A> =0A> And yes the selection of file to rename only those=0A> =
was broken in revision 9, try it now with revision=0A> 10, should be fine.=
=0A> =0A> As far as I've tested it works perfectly.  But=0A> needless to sa=
y, this is still the SVN version, so=0A> it's Beta, test before using it fo=
r now ;-)=0A> =0A> =0A> =0A> ----- Message initial ----=0A> I did have to i=
nstall perl-Gtk2.i386 (1.121-1.fc4)=0A> and=0A> perl-Glib.i386 (1.120-1.fc4=
) to satisfy=0A> dependencies,=0A> but this completed without difficulty, a=
s did the=0A> subsequent successful install of GPRename v1.7 via=0A> svn=0A=
> checkout.=0A> =0A> Version 1.7 loads fine and performs, usually, the=0A> =
first rename task without a problem. However,=0A> subsequent operations (an=
y renaming with any option,=0A> so far as I can tell) operates not merely o=
n the=0A> *selected* files but *all* the files in that=0A> directory, with =
predictably awful results. Attempts=0A> to fix the bad renames only makes t=
hings worse.=0A=0A=0A__________________________________________________=0AD=
o You Yahoo!?=0AEn finir avec le spam? Yahoo! Courriel vous offre la meille=
ure protection possible contre les messages non nollicit=E9s =0Ahttp://mail=
.yahoo.ca Yahoo! Courriel  

[Gprename-users] Re : Bug in svn revision 9 on FC4

[Lacrocivious A. <alt...@ya...>]

Version 10 appears to have fixed this selection
problem. In tests today only those files selected for
renaming were actually renamed. Thank you!

By the way, the Perl version already installed on the
FC4 box before adding perl-Gtk2 and perl-Glib is
perl-5.8.6-24 (perl.i386).

I have a handful of observations:

(1) Apart from reading .../.svn/entries I don't see a
way to discover which version is currently installed.

(2) I was in error when I claimed revision 9 worked on
FC6. I had forgotten to run gprename-install.sh after
the revision 9 svn checkout. Also I should learn to
refer to GPRename 2.0, not 1.7.

(3) Personal preference: I almost never run any
application full-screen, and it is one of my pet
hatreds that I dislike any program opening
full-screen, *especially* when I have previously
resized it not to be. Perhaps an option to remember
previous state, or one to open to a smaller window
should remembering state be difficult with Gtk, would
be useful.

(4) Though I am trying to get used to the 'always
live' preview state, I must say that while it is nice
to see changes on the fly, I find the *always* live
nature disconcerting, because it affects view of every
file in the directory. Might this be changed to an
on/off toggle, or set to display only for the file(s)
selected?

(5) A default opening directory, or an 'open in last
directory' option may be useful.

(6) For whatever reason, load time for GPRename 2.0 is
much reduced over previous versions.

(7) Having enjoyed the ride during cvs/svn type
development paths before, I am always aware of the
possibility that programs under development may crash
with horrible collateral damage, but your caution
about using beta software is appreciated ;-)


--- Zurd <zu...@ya...> wrote:

> Thansk for the dependencies information, I added in
> the README file for the new GPRename : 
> Requirements   : Perl, Perl-Gtk2 and Perl-Glib
> 
> And yes the selection of file to rename only those
> was broken in revision 9, try it now with revision
> 10, should be fine.
> 
> As far as I've tested it works perfectly.  But
> needless to say, this is still the SVN version, so
> it's Beta, test before using it for now ;-)
> 
> 
> 
> ----- Message initial ----
> I did have to install perl-Gtk2.i386 (1.121-1.fc4)
> and
> perl-Glib.i386 (1.120-1.fc4) to satisfy
> dependencies,
> but this completed without difficulty, as did the
> subsequent successful install of GPRename v1.7 via
> svn
> checkout.
> 
> Version 1.7 loads fine and performs, usually, the
> first rename task without a problem. However,
> subsequent operations (any renaming with any option,
> so far as I can tell) operates not merely on the
> *selected* files but *all* the files in that
> directory, with predictably awful results. Attempts
> to
> fix the bad renames only makes things worse.
> 



 
____________________________________________________________________________________
Sponsored Link

Mortgage rates near 39yr lows. 
$310k for $999/mo. Calculate new payment! 
www.LowerMyBills.com/lre

[Gprename-users] Re : Bug in svn revision 9 on FC4

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

Thansk for the dependencies information, I added in the README file for the=
 new GPRename : =0ARequirements   : Perl, Perl-Gtk2 and Perl-Glib=0A=0AAnd =
yes the selection of file to rename only those was broken in revision 9, tr=
y it now with revision 10, should be fine.=0A=0AAs far as I've tested it wo=
rks perfectly.  But needless to say, this is still the SVN version, so it's=
 Beta, test before using it for now ;-)=0A=0A=0A=0A----- Message initial --=
--=0ADe : Lacrocivious Acrophosist <alt...@ya...>=0A=C0 : Gprename-=
us...@li...=0AEnvoy=E9 le : mercredi 15 novembre 2006, 22 h=
 08 min 50 s=0AObjet : [Gprename-users] Bug in svn revision 9 on FC4=0A=0AH=
aving used GPRename v1.3 on an FC4 box for some time=0Awithout problems, I =
thought to take advantage of the=0Afaster and nicer interface offered by GT=
K2 and your=0Anew features.=0A=0AI did have to install perl-Gtk2.i386 (1.12=
1-1.fc4) and=0Aperl-Glib.i386 (1.120-1.fc4) to satisfy dependencies,=0Abut =
this completed without difficulty, as did the=0Asubsequent successful insta=
ll of GPRename v1.7 via svn=0Acheckout.=0A=0AVersion 1.7 loads fine and per=
forms, usually, the=0Afirst rename task without a problem. However,=0Asubse=
quent operations (any renaming with any option,=0Aso far as I can tell) ope=
rates not merely on the=0A*selected* files but *all* the files in that=0Adi=
rectory, with predictably awful results. Attempts to=0Afix the bad renames =
only makes things worse.=0A=0AThis does not happen on a FC6 box also runnin=
g=0AGPRename v1.7 svn checkout 9. Perhaps it is something=0Ato do with the =
FC4 Gtk2 code?=0A=0AWhile not a trace, perhaps this may help:=0A[lacrocivio=
us@courtesan emptydir]$ gprename &=0A[1] 15131=0A[lacrocivious@courtesan em=
ptydir]$ Use of=0Auninitialized value in numeric eq (=3D=3D) at=0A/usr/shar=
e/gprename/bin/gprename.pl line 675.=0AUse of uninitialized value in numeri=
c eq (=3D=3D) at=0A/usr/share/gprename/bin/gprename.pl line 675.=0A=0A=0AAn=
 actual trace can be provided if you need it.=0A=0AI reverted to v1.3 and u=
sed it without problem,=0Averifying there was no substantive other change. =
Then=0AI re-checked out svn revision 9 and reinstalled it,=0Aand ran a test=
 on a directory containing copied files.=0AThe bug repeated itself with thi=
s new install of v1.7.=0A=0APlease let me know what else you may need to fi=
nd the=0Asource of this problem. Thank you.=0A=0A=0A=0A____________________=
______________________________=0ADo You Yahoo!?=0AEn finir avec le spam? Ya=
hoo! Courriel vous offre la meilleure protection possible contre les messag=
es non nollicit=E9s =0Ahttp://mail.yahoo.ca Yahoo! Courriel  

[Gprename-users] Bug in svn revision 9 on FC4

[Lacrocivious A. <alt...@ya...>]

Having used GPRename v1.3 on an FC4 box for some time
without problems, I thought to take advantage of the
faster and nicer interface offered by GTK2 and your
new features.

I did have to install perl-Gtk2.i386 (1.121-1.fc4) and
perl-Glib.i386 (1.120-1.fc4) to satisfy dependencies,
but this completed without difficulty, as did the
subsequent successful install of GPRename v1.7 via svn
checkout.

Version 1.7 loads fine and performs, usually, the
first rename task without a problem. However,
subsequent operations (any renaming with any option,
so far as I can tell) operates not merely on the
*selected* files but *all* the files in that
directory, with predictably awful results. Attempts to
fix the bad renames only makes things worse.

This does not happen on a FC6 box also running
GPRename v1.7 svn checkout 9. Perhaps it is something
to do with the FC4 Gtk2 code?

While not a trace, perhaps this may help:
[lacrocivious@courtesan emptydir]$ gprename &
[1] 15131
[lacrocivious@courtesan emptydir]$ Use of
uninitialized value in numeric eq (==) at
/usr/share/gprename/bin/gprename.pl line 675.
Use of uninitialized value in numeric eq (==) at
/usr/share/gprename/bin/gprename.pl line 675.


An actual trace can be provided if you need it.

I reverted to v1.3 and used it without problem,
verifying there was no substantive other change. Then
I re-checked out svn revision 9 and reinstalled it,
and ran a test on a directory containing copied files.
The bug repeated itself with this new install of v1.7.

Please let me know what else you may need to find the
source of this problem. Thank you.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Gprename-users] New revision number of GPRename in SVN

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

Somes new changes in SVN :=0A=0AMinor : =0A- New "To Do" in README=0A- New =
gprename-uninstall.sh (more verbose)=0A- Fixed pixmap, it is now showing=0A=
- The list of files/folders are now showing with colors on alternate rows=
=0A- Added a refresh button but it doesn't work right now=0A- Deleted the p=
review button, with the "do not use the preview button"=0Aoption and the fu=
nction associated with it, also changed the language=0Afile so that $str_bu=
tton_preview is not there anymore=0A=0A=0A=0A=0A=0ALast but not least :=0A-=
 Automatic Preview=0AThat is really nice, whatever you click on, it will au=
tomatically call the preview function, click on Radio button, enter text in=
 the Entry box, change directory and it will show right away.  Which is why=
 I removed the preview button, there's no need for it anymore.=0A=0A=0AThen=
 I hope I'll be able to implement the refresh button and opening the tree w=
hen the application starts, even after trying many things for 10 hours, I s=
till can't find a way to do it.  And I find that the documentation on gtk2-=
perl is missing, there's isn't that much thing.=0A=0AAnd even after sending=
 2 posts on the gtk-perl mailing list and 2 others post to the admin of thi=
s mailing list, no one replied to me, seems like my e-mail aren't getting t=
hrough.  I'm really thinking that they don't want me to code in gtk2-perl, =
missing documentation, no one to help and all the tutorials and examples th=
at I found are just too basic and the IRC channel of gtk-perl is almost emp=
ty and nobody answered me after a few hours.  o_O=0A=0A=0A_________________=
_________________________________=0ADo You Yahoo!?=0AEn finir avec le spam?=
 Yahoo! Courriel vous offre la meilleure protection possible contre les mes=
sages non nollicit=E9s =0Ahttp://mail.yahoo.ca Yahoo! Courriel  

[Gprename-users] gprename

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

I, too, prefer features over eye-candy and as for the new look of gprename,
I have nothing to do with it, by default with gtk2-perl, it changed 
everything.  It's quite nice actually because the old look of GPRename is
so 1980 when you compare it to the new one ;-)

And I know what you mean Marvin about not having the time for it.  The
only good reason why I did it is because I quit my job 1 month ago.  So
I now have more time for GPRename.  A lot more time :)

__________________________________________________
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  

Re: [Gprename-users] GPRename 2.0 coded in Gtk2-Perl

[Marvin S. <ma...@de...>]

Am Sonntag, 5. November 2006 04:13 schrieb Zurd:
> Finally, here it is, GPRename for gtk2-perl !

Hi,

good work! I sadly have to say, that i had no time todo GTK2 porting.
My Job took a lot of time the last half year. Fortunately I'll have vacatio=
n=20
in dezember :)

>
> Since they switch gtk-perl 1.x to gtk-perl 2.0, I think it makes
> sense to change gprename version from 1.x to 2.0.  But note that
> this is GPRename 2.0 Beta, read on for why it's still in Beta.
>
> Even tough I say "finally here comes the new gprename", I must say
> it was a good thing that we waited.  The function of the tree we
> were using was CList which is now deprecated, to replace it you
> must use TreeView and it is quite complex.  To create a tree with
> this new function would have taken me quite some time.  Fortunately,
> someone else already made a tree using TreeView and posted it for
> everyone to see at :
> http://mail.gnome.org/archives/gtk-perl-list/2006-October/msg00003.html
> which date from october 1.  Only a month ago.  Would have been quite
> hard to port to gtk2-perl before that.
>
> It took me a week of about 6 hours a day to port to gtk2-perl.  I had
> to recode about 70% of the code.  Especially because the code was really
> bad and I'm the one to blame for that :-)  I didn't use an object-oriented
> way of coding and I just put new stuff in it before understanding the
> code first (I'm really lazy).  But now since I had to use new functions
> instead of the deprecated ones, I had to understand everything.  Also,
> the code is now much better in term of comments for documentation.
>
>
> Now, as for what as changed :
>
> On the first line we could see before :
> use strict;
> no strict "vars";
> Which is kind of funny, first use strict, and after use no strict,
> there's no point in it, use it or do not use it.  Now we see :
> use strict 'vars';            # require variables to be declared before
> using them use strict 'subs';
>
> We also now use :
> use warnings;                 # print warning messages on the command line
> So if anyone sees warnings messages, tell the mailing list or fix it.
> Getting rid of the warning messages is a good programming habit of course.
>
> Because of the use strict now, we have to declare every variable that
> comes from other files, like the languages file, which is why there's a
> bunch of :
> our $str_button_apply;
> our $str_button_preview;
> our $str_button_undo;
> our $str_case_all_lo;
> our $str_case_all_up;
> ...
>
> The file bin/langs.pl changed to languages/langs.pl
>
> The section :
> ######################################
> # Tree and file/folder list          #
> ######################################
> Is almost completely new since CList as I said was deprecated
> and so are all the functions related to it.  Old functions like
> expand_tree, collapse_tree, has_sub_trees, select_item, show_files
> and show_files_recursive have been deleted in favor of the new
> ones : process_dir_at_iter, pathname_from_iter,
> populate_node, list_files_dirs, list_dir_in_tree
>
> The "at the end" option in "Insert / Delete" has been removed
> See "Help / Tips" in the menu on how to insert/delete text at
> the end.  Looks more clear, simple and precise without showing
> the option.
>
> The position of the manipulation items at the bottom (insert/delete,
> case, replace/remove and numeric) have been changed, it's in a new
> order, kind of the less complicated to the more complicated from a
> user point of view.
>
> Now renaming the case with accents work, like e acute will give E
> acute (=E9 to =C9), before with version 1.7 it didn't work.
>
> New function : language_selected, that one is call when GPRename
> opens and when a user change the language, everything is rename
> automatically, no need to restart GPRename for the changes to take
> effect. There's only 2 label that I don't know how to change their
> text tough, see line 607 and 608.  It's in the To Do.
>
> Now gtk2-perl finally comes with a Dialog window function.  No
> need to create one from scratch, just call Gtk2::MessageDialog->new
> Very very handy.
>
> The function apply has now been broken into 2 smaller functions, it's
> so much more easy to read now.  There is check_before_renaming,
> which checks for error (like if a file already exist with the name
> we want to rename it to) and there is also the function rename_now
> which do the actual renaming if everything is ok with
> check_before_renaming.
>
> The function : insdel, case, replace and numeric have been recoded
> completely, I especially like the new insdel with his 40 lines of code,
> before with gprename 1.7 it was 100 and looks so ugly ;)
> Tough with other functions it might be larger than with version 1.7
> because of all the initialisation of variables (good programming habit).
>
> In the insert/delete tab, the position has changed. Before, to insert
> text at the start, the position had to be 1, now it has to be 0.
>
> You can now see hidden files and folders in the tree, it's on by default,
> very nice from gtk2-perl.
>
> See the start of the file gprename.pl for URL links on documentation of
> gtk2-perl
>
> The language files TW for Taiwan has been removed, they contained too many
> empty strings.
>
>
> Now why this is GPRename 2.0 **Beta** : because I coded almost everything
> GPRename 1.7 had, but not all.  To do :
>
> The undo function, now it doesn't work.  I'm thinking of everytime there
> is a renaming to log it into ~/gprename-renaming.log and to undo the
> rename just read that file backwards.
>
> The recursive function doesn't work anymore.  Have to recode it
> completely and that is a complex one :(
>
> The tree will not open in the directory you're in when you open it.
> Have to recode that also.
>
> The option "do not use the preview button" do not work also, I could
> code it right now and be finish with it in 5 minutes, but I'm
> thinking of getting rid of it in favor of an automatic preview.
> Everytime you change something in the manipulation items, it automatically
> call preview.
>
> Some strings in the language files have been changed.  Other than
> english or french the other files have many empty strings.
> Translators : please help! :)
>
> So new version but less features.  That is why it's in Beta, let's fix
> these things first and release an official version.
>
>
> So that's about it, I may have forgotten 1 or 2 things tough.  It's
> quite a big update, next time I'll do a smaller one.  I just couldn't
> stop coding for that past week.
>
> As usual, call "svn co https://svn.sourceforge.net/svnroot/gprename
> gprename" to get the new changes.  Also the "Last log entry" column in SVN
> Browse doesn't show anything because I have no idea how to put something
> there, I never finished reading a book on SVN ;)

I'll have a look at the new code, to get to know it. I also will do the wor=
k=20
for the german translation.

Regards
Marvin Stark
=2D-=20
 .""`.     Marvin Stark <ma...@de...>
: :"  :    Homepage: www.der-marv.de
`. `"`
  `-  Debian - when you have better things to do than fix a system

[Gprename-users] Heralds Trumpet, Wine Flows, Maidens Offer Themselves

[Lacrocivious A. <alt...@ya...>]

In an amazing coincidence, my plea for a GTK2 version
of GPRename has been met within mere hours by a new
release!

The trumpet blares are surpassed only by the splendor
of the banquet feast and the beauty of the maidens
attending! ;-)

Oh, and the wine. That's good too.

While I have not yet explored all the functions or the
limitations of those documented not to be presently
implemented -- the wine, you see -- I can happily
report that the SVN build launched immediately and
without complaint.

The redesign, such as I have seen, appears to be an
improvement. And the appearance overall is much
improved as well, though I confess to preference of
function over eye candy.

Thank you, Zurd! May your glass never be empty, nor
your bed ever lack wanton wenches ;-)





 
____________________________________________________________________________________
Want to start your own business? Learn how on Yahoo! Small Business 
(http://smallbusiness.yahoo.com) 

[Gprename-users] RE : Wailing, Anguish, Rending of clothes and Weeping

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

Seriously, that is so much of a coincidence that I almost finish coding it
in gtk2-perl right now.  Awesome.  You just came in at the right moment.

It's right there now for gtk2-perl :
http://gprename.svn.sourceforge.net/viewvc/gprename/
You can always get it with :  svn co https://svn.sourceforge.net/svnroot/gprename gprename
If you don't have Subversion tough I could always make a .tar.bz2 file of it and send it
to you.

As you can read from my last post, it's not complete, but it is functional.

Guess I'll be able to sleep well tonight then ;)




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

> Having grown accustomed to using GPRename on a regular
> basis, I have recently upgraded one system to Fedora
> Core 6 and discovered that this distro has abandoned
> Gtk-perl entirely, due to its early Cretacious Period
> dependencies.
> 
> Despite my best efforts, lame as they are, to rebuild
> FC5 rpms so that I could use GPRename anyway, I have
> encountered the limits of my poor knowledge in the
> form of config.log death poems beyond my ability to
> interpret.
> 
> It is astonishing to me that GPRename or its
> equivalent is not a part of all core distros. No
> matter the power of any CLI, there remain many
> instances where the *visible* and *on-the-fly
> selection* of files to rename are so much better
> addressed by a GUI that the CLI becomes irrelevant.
> 
> I have hit similar barriers attempting to adapt
> KRename to FC6, but I must say that I don't like the
> way KRename does things in the first place. I have
> become addicted to GPRename. And now I cannot have it.
> 
> No dog has ever howled more pitifully than I, upon
> realizing that on my FC6 system at least, I cannot use
> GPRename until it is ported to GTK2. Sneaking through
> from another system via mount points does work, of
> course, but it is such an ugly method in my view.
> 
> Unfortunately, I cannot program my way out of a simple
> bash script, let alone contribute at the level
> GPRename operates. The best I could offer is to be a
> test animal, and to help edit the English
> documentation should that be of any use.
> 
> In any case, I very much hope that Zurd and/or
> Tristesse (a mailing list comment implies Tristesse
> may have moved on) is actively working on a GTK2
> update for GPRename.
> 
> If not, I hope you can sleep at night, knowing that I
> remain here, disconsolate, wailing, tearing my clothes
> while crouching on a mound of ashes, because I cannot
> use GPRename as it exists on my FC6 machine ;-)

__________________________________________________
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  

[Gprename-users] GPRename 2.0 coded in Gtk2-Perl

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

Finally, here it is, GPRename for gtk2-perl !

Since they switch gtk-perl 1.x to gtk-perl 2.0, I think it makes
sense to change gprename version from 1.x to 2.0.  But note that
this is GPRename 2.0 Beta, read on for why it's still in Beta.

Even tough I say "finally here comes the new gprename", I must say
it was a good thing that we waited.  The function of the tree we
were using was CList which is now deprecated, to replace it you
must use TreeView and it is quite complex.  To create a tree with
this new function would have taken me quite some time.  Fortunately,
someone else already made a tree using TreeView and posted it for
everyone to see at :
http://mail.gnome.org/archives/gtk-perl-list/2006-October/msg00003.html
which date from october 1.  Only a month ago.  Would have been quite
hard to port to gtk2-perl before that.

It took me a week of about 6 hours a day to port to gtk2-perl.  I had
to recode about 70% of the code.  Especially because the code was really
bad and I'm the one to blame for that :-)  I didn't use an object-oriented 
way of coding and I just put new stuff in it before understanding the 
code first (I'm really lazy).  But now since I had to use new functions 
instead of the deprecated ones, I had to understand everything.  Also, 
the code is now much better in term of comments for documentation.


Now, as for what as changed :

On the first line we could see before :
use strict;
no strict "vars";
Which is kind of funny, first use strict, and after use no strict,
there's no point in it, use it or do not use it.  Now we see :
use strict 'vars';            # require variables to be declared before using them
use strict 'subs'; 

We also now use :
use warnings;                 # print warning messages on the command line
So if anyone sees warnings messages, tell the mailing list or fix it.
Getting rid of the warning messages is a good programming habit of course.

Because of the use strict now, we have to declare every variable that
comes from other files, like the languages file, which is why there's a
bunch of :
our $str_button_apply;
our $str_button_preview;
our $str_button_undo;
our $str_case_all_lo;
our $str_case_all_up;
...

The file bin/langs.pl changed to languages/langs.pl

The section :
######################################
# Tree and file/folder list          #
######################################
Is almost completely new since CList as I said was deprecated
and so are all the functions related to it.  Old functions like
expand_tree, collapse_tree, has_sub_trees, select_item, show_files
and show_files_recursive have been deleted in favor of the new
ones : process_dir_at_iter, pathname_from_iter, 
populate_node, list_files_dirs, list_dir_in_tree

The "at the end" option in "Insert / Delete" has been removed
See "Help / Tips" in the menu on how to insert/delete text at
the end.  Looks more clear, simple and precise without showing
the option.

The position of the manipulation items at the bottom (insert/delete,
case, replace/remove and numeric) have been changed, it's in a new
order, kind of the less complicated to the more complicated from a
user point of view.

Now renaming the case with accents work, like e acute will give E 
acute (é to É), before with version 1.7 it didn't work.

New function : language_selected, that one is call when GPRename
opens and when a user change the language, everything is rename
automatically, no need to restart GPRename for the changes to take
effect. There's only 2 label that I don't know how to change their
text tough, see line 607 and 608.  It's in the To Do.

Now gtk2-perl finally comes with a Dialog window function.  No
need to create one from scratch, just call Gtk2::MessageDialog->new
Very very handy.

The function apply has now been broken into 2 smaller functions, it's
so much more easy to read now.  There is check_before_renaming,
which checks for error (like if a file already exist with the name
we want to rename it to) and there is also the function rename_now
which do the actual renaming if everything is ok with 
check_before_renaming.

The function : insdel, case, replace and numeric have been recoded
completely, I especially like the new insdel with his 40 lines of code, 
before with gprename 1.7 it was 100 and looks so ugly ;)
Tough with other functions it might be larger than with version 1.7
because of all the initialisation of variables (good programming habit).

In the insert/delete tab, the position has changed. Before, to insert
text at the start, the position had to be 1, now it has to be 0.

You can now see hidden files and folders in the tree, it's on by default,
very nice from gtk2-perl.

See the start of the file gprename.pl for URL links on documentation of
gtk2-perl

The language files TW for Taiwan has been removed, they contained too many
empty strings.


Now why this is GPRename 2.0 **Beta** : because I coded almost everything
GPRename 1.7 had, but not all.  To do :

The undo function, now it doesn't work.  I'm thinking of everytime there
is a renaming to log it into ~/gprename-renaming.log and to undo the
rename just read that file backwards.

The recursive function doesn't work anymore.  Have to recode it
completely and that is a complex one :(

The tree will not open in the directory you're in when you open it.
Have to recode that also.

The option "do not use the preview button" do not work also, I could
code it right now and be finish with it in 5 minutes, but I'm
thinking of getting rid of it in favor of an automatic preview.
Everytime you change something in the manipulation items, it automatically
call preview.

Some strings in the language files have been changed.  Other than
english or french the other files have many empty strings.  
Translators : please help! :)

So new version but less features.  That is why it's in Beta, let's fix
these things first and release an official version.


So that's about it, I may have forgotten 1 or 2 things tough.  It's
quite a big update, next time I'll do a smaller one.  I just couldn't 
stop coding for that past week.

As usual, call "svn co https://svn.sourceforge.net/svnroot/gprename gprename"
to get the new changes.  Also the "Last log entry" column in SVN Browse doesn't
show anything because I have no idea how to put something there, I never finished
reading a book on SVN ;)


__________________________________________________
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  

[Gprename-users] Wailing, Anguish, Rending of clothes and Weeping

[Lacrocivious A. <alt...@ya...>]

Having grown accustomed to using GPRename on a regular
basis, I have recently upgraded one system to Fedora
Core 6 and discovered that this distro has abandoned
Gtk-perl entirely, due to its early Cretacious Period
dependencies.

Despite my best efforts, lame as they are, to rebuild
FC5 rpms so that I could use GPRename anyway, I have
encountered the limits of my poor knowledge in the
form of config.log death poems beyond my ability to
interpret.

It is astonishing to me that GPRename or its
equivalent is not a part of all core distros. No
matter the power of any CLI, there remain many
instances where the *visible* and *on-the-fly
selection* of files to rename are so much better
addressed by a GUI that the CLI becomes irrelevant.

I have hit similar barriers attempting to adapt
KRename to FC6, but I must say that I don't like the
way KRename does things in the first place. I have
become addicted to GPRename. And now I cannot have it.

No dog has ever howled more pitifully than I, upon
realizing that on my FC6 system at least, I cannot use
GPRename until it is ported to GTK2. Sneaking through
from another system via mount points does work, of
course, but it is such an ugly method in my view.

Unfortunately, I cannot program my way out of a simple
bash script, let alone contribute at the level
GPRename operates. The best I could offer is to be a
test animal, and to help edit the English
documentation should that be of any use.

In any case, I very much hope that Zurd and/or
Tristesse (a mailing list comment implies Tristesse
may have moved on) is actively working on a GTK2
update for GPRename.

If not, I hope you can sleep at night, knowing that I
remain here, disconsolate, wailing, tearing my clothes
while crouching on a mound of ashes, because I cannot
use GPRename as it exists on my FC6 machine ;-)



 
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups 
(http://groups.yahoo.com)