[KimDaBa] About the renaming issue
Dario Spagnolo
spada at zaup.org
Wed Jan 14 11:56:02 GMT 2004
Jesper K. Pedersen said:
> 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?
There is some first-use loading time anyway because of the thumbnail
generation. But it's true that 0,03 seconds/image is a bit longish (what
kind of computer is that ?), but I guess we could also wrap the md5
function so that it only takes into account the first 10kb and the last
10kb, no ? I guess it would still work perfectly fine for 99,999999% of
situations.
> 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
> _______________________________________________
> KimDaBa mailing list
> KimDaBa at klaralvdalens-datakonsult.se
> http://sulaco.hrhansen.dk/mailman/listinfo/kimdaba
>
--
Dario Spagnolo
http://www.zaup.org
--
Dario Spagnolo
http://www.zaup.org
More information about the Kphotoalbum
mailing list