Re: [gcmd-dev] [NEW] Advrename on steroids

[Piotr Eljasiak]

> Good idea, i use $c nearly every day...hmm, howbout making 
> c=2 default ?

> Or just a better idea, how taking the number of selected files as a
base
> for the (dynamic) default ? That is, c=log(n)+1 For example, it
happened
> that i renamed >100 camera downloads with c=2, and ran into huge
trouble
> to sort out the right order later (you know, file/image managers
sorting
> 100 after 10 and such).

But (unfortunately) gcmd doesn't set anything to defaults while opening
advrename dlg. Everything is as the user left it the last time...


> Maybe we can convert very long filenames now to CamelCase and vice
> versa. (Any suggestion ? ;)

Simply use regexes ;o)

long file name -> CamelCase

    regex: '\b(\w)(\w*)\b'   replace: '\u\1\L\2\E'

CamelCase -> long file name

    regex: '\p{Lu}'   replace: ' \l\0'

> Would be nice to also have 'remove all blanks' as an option then.

    regex: '\s+'   replace: ''

IMHO the best approach here is to implement support for storing/loading
advrename settings - this way there'd be convenient way for defining
by user its own rename schemas.


> How about linking that in the Help ?

Definitely yes, just wanted to publish the code first...


> Somehow i seem to see ctime instead, or at least it's not updated
after
> 'apply'.

You're right, this is the same as in gcmd file list. I meant ctime.


> How about access to intview (F3), in case you like to check if some
> image file really is what you think it is...yes you can do that in the
> main window but then have to throw away toe selection.

Good idea - added to context menu as rev. 2286. I haven't assigned F3,
as it'd be working only for focused file result.


> Somehow it feels a little bit odd that there's no feedback that
anything
> went fine...like successful renames painted red and blinking wild...
or
> maybe it would feel better if mtime works ?

> >       The file list is updated with new file names
> >       (marking the failed renames)

> that's good. hmmm... could this be done in preview too ? Could be
helpful.

> For example i remember i once wondered what would happen if a rename
> would overwrite another file, and i went to try it out. With
on-the-fly
> color feedback, it would be clear immediately.

That's not that easy. Basically speaking - gcmd doesn't know if the
rename will be successful unless it tries (eg. read-only mounts or file
systems not case-aware). Moreover, there even are some renames that
COULD be perfectly performed, but gcmd can't resolve it automatically,
like:

    file1 -> file2
    file2 -> file3
    file3 -> file4

So I'm afraid that the preview color feedback could be a bit misleading.
As a solution - in case of duplicates - I think that showing the alert
should be enough here.

But there is still one question left - what to do AFTER rename? There
are 3 possible scenarios:

    1. just close the dlg
    2. leave dlg open, empty results list leaving rename failures
    3. leave dlg open, update file names in reults list and mark
failures

1) is not an option; 2) doesn't give the user a chance to backstep - one
needs
to close dlg and to start it again; so I decided for 3)


Piotr