[KimDaBa] About the renaming issue

[Jean-Michel FAYARD]

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.