[KimDaBa] another feature request

[Martin Höller]

Hi again!

On 05 May 2005, Robert L Krawitz wrote:

>    Date: Thu, 5 May 2005 21:50:28 +0200
>    From: Martin =?ISO-8859-1?Q?H=F6ller?= <martin at xss.co.at>
> 
>    On 04 May 2005, Robert L Krawitz wrote:
> 
>    >    Date: Wed, 4 May 2005 17:04:38 +0200
>    >    From: Martin H=F6ller <martin at xss.co.at>
>    >
>    >    As i was trying to move some of my older images to a CD i found out
>    >    that offline-support in kimdaba is kind of lacking.
>    >
>    >    What i wanted to do is to move some folders containing pictures to
>    >    another location to burn it on a CD. But when i moved the folders i
>    >    found out that the thumbnails were in a subfolder which prevented
>    >    kimdaba from viewing thumbnails when (re)moving the whole folder.
>    >
>    > The easiest way to do that is to export the photos into the directory
>    > of your choice.  I know I submitted a patch to allow exporting by
>    > links, so it wouldn't consume more disk space.
> 
>    This would only solve part of my problem: i could use your
>    suggestion to create a folder with all the images i want to burn on
>    a CD. That's fine.
> 
>    But on the other hand i would still have these images on disk in
>    the picture-folder, where i wanted to remove them to save some disk
>    space.
> 
> Then use the hard link option when exporting: that won't take up any
> significant amount of extra disk space.

I'm afraid, you didn't get what i mean. Is my English that weird? ;-) Let
me try again.

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?

>    At the moment i have about 40 file with the name
>    64x64-0-dscf0003.jpg.
> 
> Which is a whole lot better than
> 
> a4743227232c6c57105c62d8001b9a80.jpg
> 
> or
> 
> 64x64-0-a4743227232c6c57105c62d8001b9a80.jpg
> 
> since it at least tells you what file the thumbnail is associated
> with, no?

Only if you have unique filenames in the whole tree. What if you have two
folders A and B both with an image dscf0001.jpg in it (that's quite common
for most cameras I know).

Do a selection within kimdaba so that you have both images in the
thumbnail preview and say "Export". What happens is that kimdaba renames
the images to avoid name clashes. That's fine and there is nothing wrong
with this. I'm just trying to show that a name like "64x64-0-dscf0003.jpg"
is not necessarily associated with _one_ image-file.

But if nobody else has to say anything about this let's just stop this
part now, that's just peanuts.

>    Anyway, the actual reason for my mail was not the renaming of the
>    thumbnails but to find another location for them due to a better
>    offline support.
> 
>    My preferred way of saving images to a CD is to take a folder, burn
>    it on a CD and remove it in the original location. This is not
>    possible without breaking the thumbnail preview in kimdaba.
> 
> There are advantages and disadvantages both ways.  I prefer the
> current way; the thumbnails are closer to the actual images.

Ok, that could be an advantage.

> Consider
> what happens if you have the image directory split across multiple
> filesystems; wouldn't you want the thumbnails to stay with the images?

Do you think people do this? I have all my images in /home/martin/fotos/
where /home is on one filesystem.

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.

That's where the whole thing started ;-)

Maybe somebody else can bring in new aspects to help us with this topic.

- martin

-- 
    mailto:martin.hoeller at xss.co.at  |
http://stud3.tuwien.ac.at/~e9926483  |  God is real -
                       icq:45563199  |    unless declared integer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20050506/6375be4d/attachment.sig>