No subject

is under the "control" of digikam. These images
then get changed, e.g. by adding GPS info etc.
So by this it is ensured, that there is always an untouched copy,
straight from the camera (ignoring data-integrity problems
for the moment ;-).

> One thing that I noticed about digiKam: I tried to delete an album and a
> scary dialog came up: "These albums will be moved to the Trash Bin". And
> a checkbox saying "Delete files instead of moving them to the trash".
>
> Album = Folder? is this going to delete the folder from my file system?
>
> or
>
> Album = abstract entity, collection of pictures as represented inside
> digiKam?
>
> I got my answer, and I did not like it: Album = Folder.
>
> Which means that when I first created an album, it duplicated the files
> from the first folder used for it. Then, when I added pictures from
> another folder to that album, it duplicated them too. When I tried to
> delete the album, the dialog did not inform me of its location.

OK, that makes sense to me. Could you file a wish
in the bug-tracker (See "Reporting bugs and wishes" at
http://www.digikam.org/?q=contrib) to report the location
of the album when it is to be deleted ?

> But when
> I tried to delete an individual picture, it did.
>
> Adobe Lightroom used to behave like that during beta testing. For
> release, they got the message. Now, removing the equivalent of an Album
> only removes it from the database (by default), leaving the files and
> XMP sidecar untouched. I can elect to have the files deleted as well,
> but it is an option, not the default. I can copy files into Lightroom's
> own folders, but I can also have it leave them where they are and only
> add them to the database.
>
> Is this possible with digiKam as well? I have not found out yet how.

Currently this is not possible.
For digikam >=0.10 (which uses Qt4/KDE4) multiple
root albums will be realised.

There are quite a few changes in the database for >=0.10, see e.g.
http://www.digikam.org/?q=node/257
http://www.digikam.org/?q=node/256
and in the wiki
http://wiki.kde.org/tiki-index.php?page=digikam
under
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion

For digikam >=0.10 the database schema are described in
http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log
and a similar document exists for 0.9.x:

> I wish the delete dialog would be less threatening to me. I wish it
> would clearly tell me whether I am deleting an abstract entity or an
> actual folder/file.

(see above ;-)

> > Well, there is of course much more, like support for geo-tagging,
> > or the brilliant light-table to compare images side-by-side ...
>
> yes, the light-table is brillant. I have a few ideas, but maybe others
> had them already. How about a "diff mode", where the two images are
> super-imposed?

Personally I don't think I would use that much - but
there are many features I don't use ;-).
Sounds like another wish for the bug-tracker...

[...]

> > Gerry already explained it, see also
> > http://www.digikam.org/?q=node/219
> >
> > This problem will be solved with digikam 0.10 which uses KDE4,
> > and is under heavy development, see
> >   http://www.digikam.org/?q=about/releaseplan
>
> I understand. Given that support for network drives is a killer
> criterium for me, and that 0.10 is planned for the summer, I will not
> adopt digiKam right away. But I will have time to test it thoroughly,
> and maybe give more feedback?

Constructive feedback is always welcome!
What is important: in order to ensure that good
ideas are not forgotten, they need to be put into
the bug-tracker. This ensures that other people can vote
for the wish, that their comments are preserved, that
patches can be added and duplicates can be added.
(Browsing through the 400+ bugs/wishes for digikam
is interesting on its own ;-).

It also has the advantage (at least in an ideal world),
that only one issue is discussed at a time,
in contrast to e-mail discussions, which tend
to have (too) many different aspects in one thread ... ;-)

[...]

Best, Arnd