[KimDaBa] another feature request

[Jesper K. Pedersen]

Sorry, I haven't read the whole thread - I have quite a bit of backlock with 
kimdaba mails :-)

For KimDaBa 2.2 I plan to improve the offline mode in two ways:
1) If an image is not on disk, prompt the user to make it available
2) Make an option (I think) to (alternatively) store thumbs in the 
~/.thumbnail directory (there is a semi standard for this). I'm not sure if I 
can for storing thumbs next to images any more.

Cheers
Jesper.

On Friday 06 May 2005 16:48, Eivind wrote:
| On Friday 06 May 2005 12:45, Martin Höller wrote:
| > I'm afraid, you didn't get what i mean. Is my English that weird? ;-)
| > Let me try again.
|
| Dunno, I'm Norwegian, to me it made perfect sense. That migth be because my
| englisch understanding is correspondingly weird though :-)
|
| > What I want to do is burn part of my images to a CD and remove them from
| > disk. Therefore any kind of links wouldn't help me in any way here.
| >
| > Am I the only one who wants to save images on a CD, remove them from
| > disk but keep the thumbnails? Or am I just missing something?
|
| I don't think so. And furthermore, this is really just a subset of the
| people having (or wanting) a read-only image-directory.
|
| At work we've hacked it with symlinks (pointing the xml-file aswell as
| every thumbnail-directory to files/directories under $HOME/.kimdaba/ but
| it's a hack.
|
| I would *really* like to see an option for Kimdaba, something like: "store
| thumbnails and data under $PATH where $PATH defaults to the image-dir,
| which would give the same behaviour as today, but could be changed to
| something else by people with that need.
|
| For example, at work we've got a large image-database. It is *VERBOTEN* to
| change, in any way, images stored there. We ensure this in practice by
| having it exported read-only from a NFS-server. It is however allowed to
| change the tagging of the images, infact several different people are
| allowed to do this. We've fixed that by symlinking the xml-file to a file
| on a read-write file-server where the people with tagging-permission are
| members of a group with read-write on the xml-file, whereas all others
| have only read on the xml-file too.
|
| > Do you think people do this? I have all my images in /home/martin/fotos/
| > where /home is on one filesystem.
|
| We do this. Infact the images are on a completely separate fileserver.
|
| > But even if they do, what could be the reason for this? Maybe because
| > part of their images are on a removable device. If this is the case they
| > could prefer to have the thumbnails available even if the removable
| > device is not mounted.
|
| Images are read-only. Tagging-data and thumbnails are not. Kimdaba supports
| this paradigm very well, by refraining from messing with the images
| itself.
|
| Suggestion:
|
|
| Currently:
|
| xml-file is in $PICROOT/index.xml
|
| thumbnail for $PICROOT/$PICDIR/$IMAGE is in
| $PICROOT/$PICDIR/Thumbnails/$IMAGE
|
| How about making this configurable ? All one would need to do would be to
| add a $CONFIGROOT that defaults to $PICROOT then the xml-file would go in:
| $CONFIGROOT/index.xml and the Thumbnails in $CONFIGROOT/$PICDIR/$IMAGE
|
| Changing $CONFIGROOT to say $HOME/.kimdaba would allow kimdaba to work
| perfectly with a read-only $PICROOT.
|
| (yeah, I am fully aware Kimdaba ain't programmed in shell.)
|
| I realise I should prompt my boss into paying for this by the way :-)
|
|
| 	Eivind Kjørstad
|
| _______________________________________________
| KimDaBa mailing list
| KimDaBa at mail.kdab.net
| http://mail.kdab.net/mailman/listinfo/kimdaba

-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://ktown.kde.org/kimdaba might be the answer.