[Digikam-devel] Suggestion: Support for multiple base Directories

[Florian Ehinger]

Hi

I think a quite useful and not to difficult to implement feature would be a
menu for quick-switching the base directory of the database.

With that it would be easier to handle external media since you could just
create a new database for every media an selecting it when starting digikam.

Bye
  Florian
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

On Friday 13 October 2006 15:21, Florian Ehinger wrote:

> Hi
>
> I think a quite useful and not to difficult to implement feature would be a
> menu for quick-switching the base directory of the database.
>
> With that it would be easier to handle external media since you could just
> create a new database for every media an selecting it when starting
> digikam.
>
> Bye
>   Florian

There are a lots of wishes in KDE bugzilla about multiple album collections
management path.

This will be done later 0.9.0 release, when we will ported digiKam & co to Qt4
and re-writted a new database backend interface like Amarock have done (this
one will not be limited to SQlite DB)

After that, managed multiple path can be done more easily.

Regards

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Colin Guthrie-6]

Gilles Caulier wrote:
> There are a lots of wishes in KDE bugzilla about multiple album collections
> management path.
>
> This will be done later 0.9.0 release, when we will ported digiKam & co to Qt4
> and re-writted a new database backend interface like Amarock have done (this
> one will not be limited to SQlite DB)
>
> After that, managed multiple path can be done more easily.

As you will probably be aware, Amarok is trying hard to support things
like NFS shares, removable HDs and CD/DVDs.

Amarok uses a single database and Florian suggested adding a new
collection.db for each path. I think a single database is better as you
may only have read only access to the path in question (e.g. DVDs).

Anyway, all I'm pointing out is that Amarok has code to identify a
particular NFS share, DVD etc. by creating a unique key for the media
and storing that in the DB. That way when a share is not mounted or a CD
is not in the drive it knows to ignore/hide (but not delete) that metadata.

Just thought I'd point that out FYI.

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> As you will probably be aware, Amarok is trying hard to support things
> like NFS shares, removable HDs and CD/DVDs.
>
> Amarok uses a single database and Florian suggested adding a new
> collection.db for each path. I think a single database is better as you
> may only have read only access to the path in question (e.g. DVDs).
>
> Anyway, all I'm pointing out is that Amarok has code to identify a
> particular NFS share, DVD etc. by creating a unique key for the media
> and storing that in the DB. That way when a share is not mounted or a CD
> is not in the drive it knows to ignore/hide (but not delete) that metadata.
>
> Just thought I'd point that out FYI.

Yes, amarok has some cool features here:
- what you mentioned: Dynamic Collection
http://amarok.kde.org/wiki/Dynamic_Collection
- identification of files which have been moved or renamed in the collection
http://amarok.kde.org/wiki/AFT

>
> Col
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel