[KimDaBa] About the renaming issue

Wed Jan 14 11:28:27 GMT 2004

One quick question from a quick read though while compiling.
If I split up the index.xml file, how would you the represent it in the xml
files when images has been moved in KimDaBa.

Imagine I have this order in KimDaBa:
misc/img1 party-42/img12 misc/img2 party42/img42

currently I get the order from the order in the XML file, but if I split
up one file per directory, I would loose that feature.

Regarding the idea only of having md5 sums in the db (from Darios email):
I tried creating md5 sums for 892 images, which took approx 30 secs.
Are you really willing to wait 30 secs/1000 image when KimDaBa starts up?

and back to work.....

Jean-Michel FAYARD <boulot.dodo at laposte.net> writes:

| Hello
| I've browsed the ml-archives, and I've seen people asking for
| some kind of support for renaming files, and so on
| 
| I think it's a difficult issue that would need a lot of work, 
| if we want to do it right, a bit like why you don't have currently
| mass files renamings and ID3-tag changing in popular jukebox like
| rhythmbox.
| That would bring bloat in Kimdaba, killing his currently simple,
| well-thought, efficient GUI-design.
| 
| I will be much better if people use the right tool for that,
| i.e. Konqueror, bash, the init script of your USB camera or whatever you
| want. 
| 
| ***********************
| 
| 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
| 
|     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(***)
|     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
| 
|     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.
| 
|     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
| 
| Thanks to that, we don't have the use anymore of Kimdaba's offline mode,
| which is in my humble opinion irritating when you have removed unuseful
| files like in (***)
| 
| As a side note, it is now very cheap to handle photos with multiple
| roots :
|     find $BASEDIRS -type d | grep -v -i thumbnails | xargs HandleDirectory
| 
| 
| How would the new index.xml per subfolder looks like ?
| The current version of the database is like that : 
| start  = 
|     element KimDaBa {  Config & kimdaba.Options & ConfigWindowSetup &
|     Member-groups? & Images }
| A design goal is that this database makes sense on his own,
| so that we need to have the « Images » portion, the relevant subset
| of « member-groups », and the relevant subset of « kimdaba.Options »
| 
| The rest is just configuratin stuff, irrelevant to share, and should
| probably go in $HOME or $HOME/.kde
| 
| 
| ******	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.
| 
| ****** 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
|     create a « index.xml » file
| Now, one care share this directory, just like before.
| 
| ****************
| So, it's time to stop this mail which is already too long.
| I think it's worth that we force the filesystem and one's prefered
| file manager do 90% of the work for us, instead of implementing
| something complicated.
| 
| But this would changed the file format used, so it's better to discuss
| what we need (not), and what else we need (other use cases ?) before
| we reach global world domination.
| _______________________________________________
| KimDaBa mailing list
| KimDaBa at klaralvdalens-datakonsult.se
| http://sulaco.hrhansen.dk/mailman/listinfo/kimdaba
| 

-- 
Jesper K. Pedersen          |  Klarälvdalens Datakonsult
Senior Software Engineer    |  www.klaralvdalens-datakonsult.se
Peder Skrams Gade 27 3. tv. |
6700 Esbjerg                |  Platform-independent
Denmark                     |  software solutions