[KimDaBa] About the renaming issue

[Jesper K. Pedersen]

<SNIP>
| Unfortunately the current way Kimdaba store his data sucks for that.
| Here is what people may want to do :
| (I've put a (**) for things Kimdaba does currently right)
| 
|     0) thanks Kimdaba's #1 design rule : select every n photos you
| 	want, and you can change very easily their attribute
| 
|     1) Someone have a new folder with fotos. He would like to just put it
|     alongside with his friends, and the software find it.(**)
| 
|     2) Kimdaba organize my fotos, this is fine, but I keep my filesystem
|     organized nevertheless. Say I have it like that : 
| 
| [Pictures]# tree -d | grep -v ThumbNails
| .
| |-- 2003-10-15_Strabaparty
| |-- 2003-11-28_BadenBaden
| |-- 2003-12-12_StrasburgNoel1
| |-- 2004-01-01
| |-- 2004-01-07_Normandie_Honfleur_Deauville
| |-- things
| `-- 2004-01-11
|     
|     Now I would like to send all my pictures taken in BadenBaden
|     to the people which were with me.
|     Ideally, I just would have to zip the 2003-11-28_BadenBaden
|     folder and to send it to them

In future versions I envision that KimDaBa will be able to copy a selection
or view to a directory, a cd or mail it.

|     3) Arghh! Not enough room on the hardrive. Someone would want
|     to remove this « 2004-01-01 » folder which take a lot of places
|     and is not very interesting. He just delete it with Konqueror.
|     Those two folders « 2003-12-12_StrasburgNoel1 » and 
|     « 2004-01-01 » are interesting, but take a lot of place.
|     Well, it's time to use this nice CD-burner(**).
|     Now, he see a folder named « things ». That is pretty much unseful.
|     He renames it « 2004-01-03_Paris »
| 
|     4) Someone do some triage in a folder. He can put(**) other fotos in the
|     folder, or remove some fotos he finds ugly.  Once this fotos are
|     deleted, they should not appear anymore in Kimdaba(***)
Well this contradicts the offline mode, but as I said in another answer
this morning, future versions of KimDaBa will include the possibility to
find imagaes not available so you can delete them from KimDaBa.

|     In this folder, there is a lot of photos named dsc_0084-488830.jpg
|     That is plain ugly. He change their names with Konqueror, or with
|     this little bash script :
| 
| next() {
|     res=`echo $1 | sed "s/^0*//"`
|     res=$(( $res + 1))
|     test $res -lt 10  && res=0$res
|     test $res -lt 100 && res=0$res
|     echo $res
| }
| i=0; for file in dsc* ; do i=$(next i); mv $file PartyWithJane_$i.jpg ; done
After this week of KimDaBa work KimDaBa will use md5 sums to it can
recognize when images has moved.

|     5) Someone may want to pick this one and this other photo
|     in ten differents folder, and do something with them,
|     for example, send them to a friend.
On my TODO list

| 
|     6) other scenario you can think of ?
| 
| 
| ******** Sumarry : put a index.xml in each subfolder ******
| 
| For the use cases 2) et 3), the obvious solution which keeps the advantages
| of 0) is to move from this one « index.xml » database to a model
| where each subfolder has is own self-containing little database.
| When Kimdaba starts, he does the equivalent of 
|     find $BASEDIR -type d | grep -v -i thumbnails | xargs HandleDirectory
| 
| The HandleDirectory thing means that we merge all the data together,
| so that 0) is still possible.
| 
| Say I have put things on a cdrom, I just have to do a quick link :
|     ln -s /mnt/cdrom $BASEDIR/fotos_on_cd
| Say I rename, move remove a directory
| Say I send a zipped directory to my friend
|     and this just work
Well there are a number of issues here
1) As I pointed out as an answer to this letter last week:
If you split it into several files then you can't reorder files easily
between directories.
Last evening I was working on KimDaBa, and my girlfriend said to me,
should we look at some of our images, preferable those taken within the
last few month. Had I not had the order correct in the XML file, then the
images would have turned up at random - or I would need something else.
2) The offline mode is still very useful: Imagine you have lots of cds with
images on, you are searching for an image with say a given person on. Now
you get 1000 hits on 10 different cds. With the thumbnails on your hard
disk you can see the images before loading the cd - I do agree though that
the offline mode still is a bit rough in the edges.
3) You can't simply hand over an XML file to your friend. I do for example
call myself Jesper in my "Persons", while if you got an image from me, you
might call me "Jesper Pedersen (aka Mr KimDaBa)". Thus a mapping needs to
happen when importing a foreign database. This feature is already on my
TODO list.

Having said all this, I'm not too reluctant to going away from on XML file,
but its something that will take quite some time to implement, and curretly
I have other feature requests + bugs on my list I'd rather spent time on.

<SNIP>

| ******	Summary : use md5sums or equivalent 
| For 4) to work, we need a thing like md5sums, (i've seend it in your
| TODO list).
| <images> should also have both a « file » attribute, this time
| relative to the subfolder, and a « tag » attribute in which we compute
| the md5sum when we can (for example, after the thumbnails generations)
| (as a side note, thumbnails should be probably renamed according to the
| md5sum when it is compute).
| When we scan the directory, we trust the « file » attribute, and if it's
| not here we use the « tag » attribute. If there is no photo that match,
| the user probably delete it like in (***), so we don't show it.
That's more or less the idea I had, and which I'll implement this week.

| ****** 5)
| This is the one case where Konqueror, bash, ... is _not_ the appropriate
| GUI to handle that. It's better to do it within Kimdaba, you can select
| easily the photos thanks the thumbnails, or do a search thanks all the
| data you've entered
| Then, with this list, we can do something like :
|     create a new directory,
|     create a hardlink for each selected photo in this directory
|     create a hardlink for the relevant thumbnails
Yup on my TODO

|     create a « index.xml » file
| Now, one care share this directory, just like before.
This is the export/import feature I described above.

CHeers
Jesper.