[KimDaBa] About the renaming issue

[Dario Spagnolo]

This email from Jean-Michel is filled with good ideas, but I think there
is one thing that should be done as soon as possible to KimDaBa in order
to make any future file handling functions easier. This is some kind of
filesystem abstraction layer based on md5 hashes.
This way KimDaBa should not rely on directories or filenames anymore,
leaving the user the freedom to rename/move files and directories.
This abstraction layer should be able to :
 - let higher-lever functions refer to files only through their md5 hash
 - if the lower-level abstraction cannot find a file, it would mean it has
been moved or renamed, so it should reread the whole root directory and
subdirs and compute md5 on all files to find it again under its new name
or dir (obviously, this process can and should be optimised). If it's
really not there anymore, it means the user has deleted it, so a dialog
box should inform the user about this and delete every record related to
this file in index.xml and its thumbnails).
 - provide a manual button that would update index.xml and autodetect
moved/renamed/deleted/added files. I don't know fam enough to suggest
using it, but maybe it would be a good idea to do so.

Once such a layer has been introduced, it would be much easier to provide
functions like renaming files from within KimDaBa (just rename the file
and update it's record, so that the md5 still points to the right file).

In some future, KimDaBa could even detect if a file has been modified
(resized, red-eyes removed,...) and not consider it as a new file but
keept all the keywords information previously entered. It would notice
that the md5 is new but the location and name of the file match with an
existing entry in the db. So it would ask the user "Have you modified this
file or is it a new file ?".

On last thing would be to provide the user with the thumbnail of the
picture  each time a dialog box asks a question about a file. More
user-friendly and less error-prone.




Jean-Michel FAYARD said:
> 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
>


-- 
Dario Spagnolo
http://www.zaup.org