Bug 107871

*** Bug 102412 has been marked as a duplicate of this bug. ***

*** Bug 105645 has been marked as a duplicate of this bug. ***

I agree.
I have quite a large photo collection now and I would appreciate having half of it on an external USB drive, the most recent ones being on my computer hard disk.

*** Bug 115726 has been marked as a duplicate of this bug. ***

I agree too.
have multiple resources. for pictures and i don't want to put them all in one directory.
despite that little flaw i LOVE digikam :) great work and thanks a lot!

nutz

This makes me think I wanted to write something about that :)

I think it's partially to bug 137694 :
http://bugs.kde.org/show_bug.cgi?id=137694

I suggested there to add 2 command-line options to start digikam.
To be more compliant with the way other softwares work, I would propose the following :
* -f to to specify the full path to digikam3.db, or relative path from the album directory

* directory as argument => this would be the album path digikam use

Eg:

1) # digikam
would behave like now. The 1st time, it will ask for an album path

2) # digikam -f /path/to/digikam3.db
would behave like now except it will use the specific path for the database

3) # digikam /path/to/my/album
digikam will use this directory as the album path, but won't override default album path if there's already one

4) # digikam -f /path/to/digikam3.db /path/to/my/album
would combine 2) and 3)

An alternative possibility is to allow multiple root albums, each associated with a single directory.

Just a thought...

For those interested, I attached a small script that I use to start different instances of digiKam with different configuration files (and so with different path). The script uses zenity to display a gui list of libraries.

For sure, it could be a lot better, but it does the job for me :)

Created attachment 21026 [details]
script to choose configuration file

and so which digikam library to use (uses zenity to have a small gui)

Note: this is somewhat related to #125474 and #114539.  I don't think it's exactly duplicates, but a good solution to any of these might just solve all of these.

*** Bug 124411 has been marked as a duplicate of this bug. ***

Just a brief update for all those waiting for this feature:
This requires a database change. Work is currently in progress 
in digikam's KDE4  branch.

SVN commit 733526 by cgilles:

digiKam from trunk (KDE4) : add Multiple Roots Album Path on setup.

With new database interface implemented by Marcel, digiKam can use more than one root album path as collection of images.
digiKam database file is now stored in a customized place wich still in local and can be different than roots album. 
This is want mean than read only, remote repository, and disconnected repository are fully suported as well.

These collection types are able to use:

- Local drive.
- Remote drive (NFS/Samba) previously mounted in local file system. 
- Removable drive as CD/DVD/USB hard drive.

Each collection set in configuaration dialog page can be named to be identified easily into Album GUI/Folder view.

There is a fresh screenshot of Collection Setup page at this url:

http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_14.png

TODO: in album gui, and especially in album folder view, we need to add a better support of collections name. 

CCMAIL: digikam-devel@kde.org
BUG: 107871
BUG: 114682
BUG: 122516
CCBUGS: 125474



 M  +434 -67   setupcollections.cpp  
 M  +13 -1     setupcollections.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=733526

Great!

But I think wording of this dialog is a bit too technical. If possible
I would like to use simpler terms like in Amarok:

I.

Everything is one Collection (also to make it different from current
Collections).

- "Collection" page in configuration dialog (not "Collections")
- "Collection settings" as title of that page

II.

"Roots album path" is decidedly too technical. Following Amarok please
use simple "Collection folders". Also in lower sections change "This
file is common for all roots album path." into  something like "This
file is common for all folders of collection."

III.

Not sure if wording problem: button Replace. Isn't it just Edit like
thing?

Other thing: write access and editing of images. How it will affect
possibility to write metadata? If it will be not possible (as I am
almost sure) it should be underscored like: you cannot edit your images,
including adding or changing their metadata.

Reason: most users see "editing of images" as only changing them
visually, they are not making clear connection with metadata of image
and embedding of it into actual file.

Sorry for whining and thanks for reading ;)

I would have expected a solution that would have been much easier, not copying things around, not configuring things through a dialog, but just referencing files from wherever they are on the disk.

This implementation just make the problem more complex to manage, and still not as flexible as it should be.

> Also in lower sections change "This
> file is common for all roots album path." into  something like "This
> file is common for all folders of collection."


--> "This file is common to all folders of a collection."
is presumably slightly better
(well, I am not a native speaker ... ;-)

Ad #15: I really like the chosen solution, because I don't want
digikam to scan my whole harddisk(s) which for example
automatically would include backups, small sized copies,
temporary copies for DVD creation etc.etc.
Also: the whole wish discussed here is about 
"Allow multiple album library paths", which is 
implemented now.

Gilles, you wrote "digiKam database file is now stored in a customized place",
what about Fabien's suggestion in #c6: 
  2) # digikam -f /path/to/digikam3.db 
  would behave like now except it will use the specific path for the database
did you already implement that?
(I think it would be very helpful, maybe even with the possibility
of different configuration files for digikam?)

>Ad #15: I really like the chosen solution, because I don't want
>digikam to scan my whole harddisk(s) which for example
>automatically would include backups, small sized copies,
>temporary copies for DVD creation etc.etc.
>Also: the whole wish discussed here is about
>"Allow multiple album library paths", which is
>implemented now. 

I'm totally agree with Arnd.

This is another reason about why digiKam exist. We don't want to reproduce picasa, f-spot, Kphotoalbum here, wich is a non-serious way to work.

To have pictures placed everywhere over the hard-drive have a non sence for me. "Organization" is the first step of a powerfull management, especially in photo.

This subject have been already discuted with the team in the past and the root album path concept have been the way used by digiKam.

Hubbert, if you don't like how digiKam work, you is free to use f-spot. To have seen your presentation from Libre Metting 2007:

http://people.xiph.org/~giles/2007/lgm/LGM_20070505-1-Hubert_Figui%C3%A8re.ogg

...it's not a problem for you!

To resume. Do not ask me to change digiKam in this way. I will never do that...

Gilles Caulier

This is great :) I'm just not sure if I'm ready to upgrade to svn... I'll probably wait for this to come into the stable version.
One q. though: If I add a removable media to my collection (for example an external backup hard disk) will digikam remove the images that are (currently) unavailable at startup when it's scanning the collection?

@ #15

1. I don't want digiKam to scan my 300GB of space constantly.
2. This is how all that type of serious software works.
3. While UI is different this is how Amarok works which is well known
   for KDE users.

==> #19 : digiKam for KDE4 is not yet complete/stable and not be used in production. It still few areas to fix in GUI to support fully multiple roots albums, especially in album folders view.

I have tried to use a removable media (CDROM with backup) and all work fine as well. Of course indeep tests still todo (:=)))

Gilles

#14 ==> to Mik,

Severals strings have been already fixed by Marcel this Week end. Look the new screenshot :

http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_15.png

Note : Look like i have fixed few action name from tool bar to be rendered properlly if icons+names are displayed at the same time (default behaviour with KDE4). Not all is fixed. I'm always waiting your path... This is a non developpers task (:=))) Do you remember ?

About "Not sure if wording problem: button Replace. Isn't it just Edit like
thing?", well no, it's not the same. Look the buttons description :

==> New : Start to edit a new collection path. 
==> Add : Add the new collection in database.

Note: there is 2 buttons for these actions to do have a new dialog again behing the config dialog. Add button is disable until you don't use New and vis-versa.

==> Remove : delete a collection from database (with confirmation of course)
==> Replace : this is not Add button. A collection already referenced by database as a read only path. You cannot edit the path, only the collection name. Changing a collection path is the same than removing a collection and add a new one.

For others strings to fix, i'm waiting your "polish" patch against svn (:=)))

Gilles

At NO POINT I said "scan and add the images automatically". 

And just to debunk any myth:

Gilles: if you don't want to get others feedback, please say so instead of telling people to use something else because you don't like their opinion. My presentation at LGM has nothing to do (you weren't even there). And I don't use f-spot either.

I originally filed bug 105645 that clearly talk about NOT copying the image but referencing in place. It has been made duplicate of this one.

> path... This is a non developpers task (:=))) Do you remember ?

I remember but don't want to patch blindly. Waiting for stable KDE4
environment - few weeks.