Re: Drag 'n drop 'n rename?!
- From: Maciej Katafiasz <ml mathrick org>
- To: Alexander Larsson <alexl redhat com>
- Cc: nautilus-list gnome org, smurfd <smurfd gmail com>
- Subject: Re: Drag 'n drop 'n rename?!
- Date: Mon, 18 Jul 2005 12:41:21 +0200
Dnia 18-07-2005, pon o godzinie 11:35 +0200, Alexander Larsson napisał:
> I once had the idea of allowing renames in the property dialog for
> multiple files. Say you select multiple files and bring up the property
> dialog, and all the files start are of the form "fooXXXXbar.jpg". It
> would be cool if the entry for the name allowed you to edit the "foo"
> and the "bar.jpg" part of the names, while displaying an uneditable
> symbolic representation for the XXXX part.
How do you determine XXXX though?
Say you have these 3 files (taken from my current downloads queue):
[AF-F]Petit_Cossette_Vol1[R2_DVD][91878FA5].avi
[AF-F]Petit_Cossette_Vol2[R2_DVD][320FFC2F].avi
[AF-F]Petit_Cossette_Vol3_end[R2_DVD][16818DF3].avi
What is XXXX here? I do realise that variables syntax is more complex
than we'd like it to be (for the above, to get the correct names in
Purrr, I'd use something along
"Le Portrait de Petit Cossette - ([C,,,2]) \[sub]\[AF-F].avi"
or
"Le Portrait de [B_6:20] - ([C,,,2]) \[sub][B:6][e.]"
if I really wanted to be idiosyncratic, and the second option is no
doubt way too complex), but I don't believe you can meaningfully attempt
to guess what user wants. What I'm going to do for 1.0 is instead sort
of visual query builder, with mechanism that will attempt to prefill
based on input file names, but with ability to easy change that in case
XXXX recognition fails (and no doubt, it will fail in many cases).
> This would be a very natural way of doing multi-file renames that
> doesn't involve writing complicated rename rules with variables in them
> or anything like that.
That would be the best for simple cases, but as I said above, I don't
believe it can be done (at least, not without creating MS Office
Clippy-like creeping horror which will annoy the heck out of you each
time it shows its ugly face).
Cheers,
Maciej
PS. While we're at renaming and naturalness, there's unpleasant
discrepancy between FileChooser's save mode and Nautilus rename
operation. Namely, FileChooser shows name completions, which
a) saves typing b) immediately shows you which names are already taken.
In contrast, renaming files, especially in crowded folder with many
different names and occasional short series (that is, my images folder)
is real PITA. Renaming file from 1121682601.jpg to
maria_sama_ga_miteru5.jpg involves first scrolling to distant part of
folder to see that 4 is last taken number, remembering that, then going
back to 1121682601.jpg to rename it (which is not easy, in folder with
1000+ files), then finally lots of typing to actually rename the file. I
was under impression that someone implemented GtkEditable and completion
support for file name labels, but I can't find it anywhere on the list,
nor in commits, so perhaps I was wrong. Consider this an enhancement
proposal then. I will file proper bug when I have some free time.
--
Being really good at C++ is like being really good at using rocks to
sharpen sticks. (Thant Tessman)
--------
Maciej Katafiasz <ml mathrick org>
http://mathrick.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]