Created attachment 50566 [details] [review]
Add batch Rename/resize capability

Based upon f-spot 0.0.13

Sorry, missed storing the small readme that went with the patch :)
------------

Screenshot of the patch.
http://www.thuree.com:8080/bt/testing/F-Spot_Rename_GUI.jpg

-----------------
Here is the first release of the RenameMoveCopy routine.

Please test it and do come with suggestions for features/enhancements.

Gnome HIG I am not sure I am following, neither proper translation standards.
This is my first try at coding in Gnome and C# so bear with me please :)

The command I used to create the diff files were as follows
  diff -Naur ../f-spot-0.0.13.orig/src/Makefile src/Makefile > Makefile.diff
  diff -Naur ../f-spot-0.0.13.orig/src/MainWindow.cs src/MainWindow.cs >
MainWindow.cs.diff
  diff -Naur ../f-spot-0.0.13.orig/src/PhotoStore.cs src/PhotoStore.cs >
PhotoStore.cs.diff
  diff -Naur ../f-spot-0.0.13.orig/src/f-spot.glade src/f-spot.glade >
f-spot.glade.diff

  and then I just copied the RenameMoveCopy.cs file

  I based everything on F-Spot 0.0.13

The changes I introduced to PhotoStore consist of one new method
(RenameFile (string new_base))
which mainly changes the base name (excluding the version name) from the
old to the new_base.
This for all the various versions each photo has.
I also modified the commit method to update the path and name as well.

Confirming so developers will have a look at the patch.

Just had a small request from some friends who had about 500 wedding pictures
from a couple of different cameras. He wanted to rename them into
20050924-1603_nd70s_0357.jpg
20050924-1603_nd70s_0358.jpg
20050924-1605_cs45_4202.jpg
20050924-1605_cs45_4203.jpg

20050924-1946_cs45_4351.jpg
20050924-1946_cs45_4351.wav
Where all the information apart from the sequence number comes from the EXIF
information. (nd70s and cs45 is the camera model)

Just to confirm that there is a need for this function, and as well as an
enhanced (handling more EXIF and XMP/IPTC tags) version as well.

what format is the patch in?  It is unreadble from the browser and the hostname
for the image doens't seem to be resolving.

The Patch is in ZIP format I am sorry to say.
The zip file contain a separate diff file for each source code file.
(My first patch..)

Created attachment 54764 [details]
Screenshot and comments wanted

Since my webserver is down, I attached the screenshot to this bug instead.

I will try to update this patch next week, and try to follow Larrys coding
standards as much as possible.

Do we have any other comments on what should be there or not. Missing features
or?

Larry: Did you managed to have a look at it or?

Added a trace run of what this patch does...

Renaming /home/nrjbeth/tmp/20030426_Jasmine_ 006.jpg ===>
/home/nrjbeth/tmp/tmp1/2003/04/20030424.071006-010.jpg
Renaming /home/nrjbeth/tmp/20030426_Jasmine_ 006 (ver1a).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/04/20030424.071006-010 (ver1a).jpg
Renaming /home/nrjbeth/tmp/20030819_Jasmine_ 009.jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030817.104927-011.jpg
Renaming /home/nrjbeth/tmp/20030819_Jasmine_ 009 (ver2a).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030817.104927-011 (ver2a).jpg
Renaming /home/nrjbeth/tmp/20030819_Jasmine_ 009 (ver2b).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030817.104927-011 (ver2b).jpg
Renaming /home/nrjbeth/tmp/20030822_Jasmine 002a.jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030822.043545-012.jpg
Renaming /home/nrjbeth/tmp/20030822_Jasmine 002a (ver3a).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030822.043545-012 (ver3a).jpg
Renaming /home/nrjbeth/tmp/20030822_Jasmine 002a (ver4b).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030822.043545-012 (ver4b).jpg
Renaming /home/nrjbeth/tmp/20030822_Jasmine 002a (ver3c).jpg ===>
/home/nrjbeth/tmp/tmp1/2003/08/20030822.043545-012 (ver3c).jpg
Renaming /home/nrjbeth/tmp/20040131_JadeJasmine_China_1.JPG ===>
/home/nrjbeth/tmp/tmp1/2004/01/20040131.022805-013.JPG

Created attachment 54938 [details] [review]
Patch against CVS - Need one more new file

I have now modified the patch very slightly and ensure it compiles against CVS.

I do not know how to create a new diff with one new file (that do not exist on
the CVS server), so I will have to create one more comment with the extra file.


===>>> Please add the next comments file as well.

Created attachment 54939 [details]
New file in addition to previous patch

This is the source code for the main file for the RenameMoveCopy patch

Please comment upon it...

/bengt

Perhaps we should incorporate a rename function directly in the import sequence?

First impression looking at the screenshot is wow, that's a huge! dialog.

Why is moving directories in this dialog/patch?  I really think this could
benefit from focusing on doing fewer things and doing them with a simpler UI. 
The build name thing is very clunky looking, and it seems overkill to have a
button for inserting things the user can just type, like space, -, ., and _. 

I'd be extremely scared of this dialog if I was the average user.

My suggestions are to break it into two different features/dialogs, one for
moving, one for renaming.  Get rid of the "Append a number" thing.  Simplify the
builder (get rid of the above keys, only allow long year, put the <XX> info in
tooltips).

Good jobs on this, it looks like it was a lot of work.  Let's get it a little
more user-friendly and get it in!

I agree I am not to happy with the gui to be honest.

I will try to get a tooltip for the pattern window.

The number I want to keep.
1) A number of my friends do want to keep the original number
2) A way to ensure you get a unique file name (append a number serie)
3) Possible to not append a number serie

In my case what I want to do is
1) rename the photos 
2) move them the photos to a Photos/YYYY/MM/picture structure. 
I do not really want to do two different operations. 

Would it be possible to keep the functions in one gui, but re-design the gui?
I will remove the buttons, and add a "legend" popup window or a tooltip.

Future possibilites for instance is to have some kind of regexp to use some EXIF
tags and based upon them set part of the pattern.

Created attachment 58649 [details]
ScreenShot

Modified the gui a little, and added a tooltip, as well as removed all the buttons at the end.
Comments / feedback are very welcome.

Created attachment 58650 [details] [review]
CVS Patch 060204

Created a patch against CVS for the above screenshot.
Comments/Feedback is welcome how we can enhance this small patch.

This looks much better.

Created attachment 58676 [details] [review]
CVS Patch 060204 with Day directory

Since F-Spot stores photos in YYYY/MM/DD I added the DD directory as a radio button. (I store the day as 01 - 31 instead of 1 - 31 though)
Comments?

Is this good enough to ensure we will not loose any photos.
Or should I change from a move command to a Copy command followed by a checksum check and then a delete?

Currently the code looks like this...

try {

if (File.Exists (new_path))
  throw new Exception ("File with this name already exists");

File.Move (old_path, new_path);
PhotoStore.MoveThumbnail (old_path, new_path);

// Set the Original name.
directory_path = System.IO.Path.GetDirectoryName (new_base);
name = System.IO.Path.GetFileName (new_name);

} catch...

Not much interest in this one I guess.

No, be assured, my life depends on this feature! :) I want it badly, that's why I'm CCed to this bug report. Devs, is there a chance we could see this in the next release or something?

Bengt: I've been following this patch since you first posted it. If you'd update it to cvs, I'll try it and try to give some input. It's a very important feature to me, so I'd love to get this straightened out.

Thanks for your great work!

Ok, stupid me for not even trying. I almost compiles, no problem even for me to make it compile cleanly :)

Anyway, a couple of remarks.

The "Create sub directories" seems a bit both redundant and restrictive. I guess one should be able to construct the directory from the target box.

Second, it should save the pattern (and probably also the target) between runs. You usually want that to be the same for each run... 

I'll test some more later, this is indeed a needed feature for f-spot!

Thanks :) Appreciate the feedback. I will have a look at this patch again this weekend I hope. Give you some more time to check ;)

Create sub directories. 
  Yes you should be able to create the subdirectories from the pattern, but I 
  thought that would be extra complicated. Easier with a simple radio box was
  my thinking. 

Saving the pattern. Yes, all these options should be saved somewhere. Any suggestions? I would like to save the last, say, 10 patterns in a drop down list, as well as the last target directory.
Not sure if this should be in Preference, or just simply in a separate file somewhere? A table or file (if file, where)?

I am missing the functionality of simply copying or moving the photo, therefore I put that functionality into this box. Iview MediaPro had it this way, and I liked it. Also, it was very easy to implement by re-using a lot of renaming code.

Regarding HIG I have no clue, and would like comments for this, as well in making this GUI easier and better, but not loosing the needed functionality. 

The logic for the Updater.cs routin bug #329841 was much better.
Similar should probably be implemented here.
---
try
        1) Create Directory
        2) hard link photo
        3) update database
        4) move thumbnails
catch
        revert thumbnails
        remove new hard link
        remove new directory

remove old hard link
remove old directories
---
But Updater.cs was implemented directly towards the database, and files. Did not use the classes. Not to nice to do the same here.
Nice with hard links, was that it was very easy to revert back (all original file names was still there, just to delete all new names). With the photo.RenameFile call, one photo at a time is renamed/moved.
Not sure if it is possible to implement something similar in this case though. Anyone have any idea?

Stian: What changes did you make to get this patch to compile?
Will try to update the patch so it compiles cleanly..

Having a quick look at it, and it looks to modify to the following:
** string origDefaultVersion = photo.GetVersionPath (photo.DefaultVersionId);

remember that the picts must keep all the EXIF data.

regards

As far as I know I am not touching the EXIF part.
Only the photo name and database.
Then again, I might have missed something. Code review is appreciated :)

you dont need touch the EXIF data to remove it. When you modify a pict you must be carefull of mantain the exif data. The first GImp 2.x version have this problem. Just try to make a test :)

see the pict (with a lot of exif data) in eog before resize, resize it, and watch it again in eog. Is all the exif data there?

regards and nice work

PD: i cannot do the test ecause im right now at office i must be working right now :P

Bengt;

I just changed the one instance of DefaultVersionPath to DefaultVersionUri.LocalPath. And it seems to work. But I don't really know Mono, so I'm sure your fix is better :)

Jose: This patch doesn't resize the photo or alter it in any other way, it just changes the name. Thus, the Exif data is still intact.

I'm by no means an artist, but I have some ideas as to how to simplify the dialogue, but I suck at glade, I really don't get it :P

We (I'll try to look at it myself) need this dialogue when we import pictures as well, so that there's less need for the rename/move/copy part, if we get it where we want at import time...

Some more ideas (I'll see if I can get my glade-fu into shape and make a patch myself sometime):

Remove the "Append a number serie"-block. Just have something like <YYYY><MM><DD>-<PPPP> (for 0001, PPP for 001 and so on) and make it start at 1 by default? Isn't that a reasonable default, which simplifies the dialogue a bit? But that might make is hard to use original number series. Hmm. At least remove the padding radio-buttons, and just have the possibility to change the total number of  numbers (if you see what I mean).

Second, by doing the same for the "Create sub directories?"-block as for Picture name pattern, we only need one field, which we can use as: "<YYYY>/<YYYY><DD>/<YYYY><MM><DD>-<PPPP>" (which is the format I store my pictures in...) then it gives you full freedom as to what to call the directories as well (which is impossible now). 

Third, there's no need to have two different target-entries. It's enough with one target, with three radio-boxes?

Hmm. It would have been nice to have some input from someone who knows the HIG well...

And do we really need to be able to copy images from this dialog? Isn't that a bit.. uncommon? :)

Stian:
I agree, the gui can be made much more simple, if we decide to only do one thing.
I used iView Media Pro, and that one had these functions, and I have used all these functions.

We could expand the pattern field, as a few people have suggested. When I created this, I wanted to make it simple. And at least at that time I thought it was much simpler to keep a few things separate, and clicking with mouse makes it more easy I think.

The pattern can become rather huge and complexed if we want to have it all there.
I had some thoughts of adding some REGEXP or similar, to check for EXIF tags and replace some with English. But that is for the future.

Moving the subdirectory part to the Pattern sounds like a good idea. Will try to implement this. Of course, if someone makes a misstake setting the pattern, the photos will end up in weird places.

One problem with moving the number information to the pattern, is that it makes it a bit tricky to modify it for the next time you use it. You need then to modify a small part in the middle. 

I guess I could add a <OrigNum> pattern, as well as a <P> or something (that is not part of the standard ).

The Rename, Move, Copy functions. Hmm
Rename and Move are more or less the same, but you do not have to choose a new directory.
Copy is thought to be used to copy photos to another person perhaps, and sort of anonymize the name while doing it. Perhaps should be in another place? But uses same pattern algorithms and all. For sure Copy is not really part of Rename :)

Any thoughts of how to ensure no data loss in case of a problem?

I think it's best to leave the copy-part to another dialog, but it's your patch, so your call :)

All this talking about iView MediaPro made me curious. And indeed, I really liked the dialog of that application. I'll attach a screenshot for the Windows/Mac impaired. It misses the "move"-part, and the search/replace part could be dropped, at least for now, but it has a nice look, I think.

Created attachment 66088 [details]
Screenshot of the batch rename dialog of iView MediaPro

Did not (yet) tried this one, but one comment anyway:
What's the point of the 'Copy' function ? After modification, which image (original or copied) is stored in f-spot ? If the original image remains on f-spot, your 'copy' thing is more an 'Export' thing, if the modified one is storred, the place for this is at 'Import' time...

btw, I'll try it asap

It's the "consensus" of this bug now, to drop the copy part, maybe make that an own "export" option sometime. :)

*** Bug 350466 has been marked as a duplicate of this bug. ***

*** Bug 352096 has been marked as a duplicate of this bug. ***

Comment from Runako Godfrey:
---
It would be very good if F-Spot would allow photos to be renamed.  Ideally,
rename would work from both the edit page as well as the browse page (via the
F2 key?
---

I will try to work a bit more on this patch in a few weeks...
Try and stream line it to be only rename then, since that seems to be the concensus here...

Hiya,

Just another vote for this feature.  I'm a new (to f-spot) user and wouldn't be too put off by that dialog in the screenshot.

I currently use KRename to rename photos, but then it kind of defeats the point of using f-spot (under ubuntu).  Currently if I want *sensible* names for my image files I have to:

1) copy files off camera
2) sort through deciding which I want to keep (never said I was a good photographer!)
3) rename them all to a sensible name EventName-001.jpg for example.
4) then import them into f-spot
5) Then I'm in a tight spot if I realize now I don't want one of them or want to change the names (have to rename them all and re-import)
6) then use f-spot's features to rotate, and export them to my gallery2 installation

So my desire is to be able to move/copy/rename photos in bulk, automatically adding whatever suffixes I choose, etc. similar to KRename, but be able to do this on an arbitrarily selected bunch of photos in f-spot (whether at import, or after doesn't matter too much to me, as long as the catalogue is updated).  If f-spot gets this functionality I'll stop using any other photo management system for importing and fiddling with photos before uploading them.

-James

Patch probably will need extensive rework, since trunk have changed a lot.
Should also be done as an extension.

Hope someone will continue it... :)

F-Spot has moved to https://github.com/f-spot/f-spot/issues

If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub.

Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.