Bug 124411

Summary: Make link instead of copying when adding image to the album
Product: [Applications] digikam Reporter: Piotr L. <piotrlg>
Component: Albums-MainViewAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: caulier.gilles, shafff
Priority: NOR    
Version: 0.8.1   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 7.6.0
Sentry Crash Report:

Description Piotr L. 2006-03-28 11:24:46 UTC
Version:           0.8.1 (using KDE 3.5.1, Debian Package 4:3.5.1-2 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.15.4

I have seen similar whichlist report, but the answer were not satisfactory to me ;-) the problem is still there and it should be easly (?) resolved. 

I was looking for a tool to organize them, make comments etc. digikam looks VERY promising, but...

I have hundreds of scanned photos of many different types (family, nature etc) and they are mixed (ie in the same directory are photos of my family, nature, landscapes, macro etc). 

When I add image to the album this image is *copied* to the album location. this is realy wrong. Scanned images could have 40MB or more, so this is wasting of hdd space.

The only solution is making links to them. So when image is on the disk already just link, not copy.

Thanx for this nice programm and regards
Piotr L.
Comment 1 Dominik Fritz 2006-03-28 13:11:07 UTC
I was also thinking about such a feature until I discovered digikam with it's great tagging features. I think you don't need this linking feature because you can achieve this behaviour by not coping the pictures but instead use tagging to create virtual albums.

Dominik
Comment 2 Piotr L. 2006-03-28 13:51:47 UTC
I'v tried using tags, but I don't get it how could I use them to create albums. Using drag&drop from gqview, or just adding images are definitely the most intuitive and fastest way to create albums. So I vote for the link option. 
Regards
Piotr
Comment 3 Mikolaj Machowski 2007-08-22 12:08:31 UTC
I think this is bad idea. Much better would be adding of feature of "spread collection".
Comment 4 Mikolaj Machowski 2007-08-22 12:39:52 UTC
*** Bug 134817 has been marked as a duplicate of this bug. ***
Comment 5 Arnd Baecker 2007-08-23 11:15:11 UTC
Mikolaj, I agree, symlinks are not a good solution,
I would suggest to close this as WONTFIX.

What do you mean by "spread collection"?
(If that is a better approach to the original problem, 
maybe you could create a new B.K.O for this and leave
a pointer here?)

Comment 6 caulier.gilles 2007-08-23 11:20:40 UTC
Arnd,

With KDE implementation, Marcel has started to implement multiple album path root support.

Marcel, can you give us more informations about ?

Gilles
Comment 7 caulier.gilles 2007-08-23 11:26:18 UTC
... KDE4 implementation i want mean (:=))), dixit this recent commit #703521:

http://websvn.kde.org/?view=rev&revision=703521

Gilles
Comment 8 Mikolaj Machowski 2007-08-23 11:39:43 UTC
> What do you mean by "spread collection"?


Multiple root directories. The best collection management in that type - 
IMO of course - in KDE is in Amarok.

----------------------------------------------------
Niezwyk
Comment 9 Arnd Baecker 2007-08-23 11:43:26 UTC
Isn't then all covered in 
http://bugs.kde.org/show_bug.cgi?id=107871
(i.e. couldn't we close this one here? ;-)
Comment 10 Mikolaj Machowski 2007-08-23 14:58:25 UTC
Close definitely. The only decision is WONTFIX or DUPLICATE? :)

----------------------------------------------------
Z Krystyn
Comment 11 caulier.gilles 2007-08-23 15:01:45 UTC
Mik,

Both. Dupplicate because support of multiple album root library path will solve the problem and because make a file link is a wrong idea...

Gilles
Comment 12 Arnd Baecker 2007-08-23 15:04:23 UTC
OK, marking this as duplicate as this gives more context information,
also for Bug 107871.

*** This bug has been marked as a duplicate of 107871 ***
Comment 13 Marcel Wiesweg 2007-08-23 18:18:47 UTC
Multiple album roots is what you already said, you dont need to constrict yourself to one "library path" as it is now, but you can have multiple. The backend support is partly there, that's not too difficult anymore because since the database code has been merged into libs/database the relevant places have been prepared. Some SQL changes are still needed, and it all comes with the planned revision of the database schema (other parts of which still need discussion)
Of course we will need a nice gui like in Amarok, a directory tree where you can select directories by check marks etc.
Comment 14 caulier.gilles 2022-01-29 14:50:02 UTC
Fixed with https://bugs.kde.org/show_bug.cgi?id=107871