Version: 0.7.2 (using KDE KDE 3.4.0) Installed from: Gentoo Packages I would appricate a commandline way to overule the "album library path". Given the limited support for on disk structured folders, this would at least allow me to organize the images by grouping them under different library paths with different icons on the desktop. Thanks
Please see last comment in bug 87027. You are in the wrong view. We do have a nice manual ;-)
Yes, that shows the structure. But it leaves the collections rather useless.. I don't really see why it should be the one or the other..
Oke, the directory structure is viewable. But Different collections (vacation versus commercial stuff f.e.) still aren't. Which was the other half of the request.
You can use tags to order your pictures in a different way then the structure on your disk. I think that covers the second part.
what is your request exactly? most users use a single directory to store their photos (obviously with subfolders inside), instead of scattering them all over the desktop. in case you want to change the location, we do provide a method for changing this directory location path.
I have different databases for vacation stuff, webstuff and art. These have each a directory structure and I prefer to keep them separated. At this moment I change the path through the regular settings but I was hoping for a commandline option to overrule this path so I can just make 3 icons with each their own top directory. Of course I realize that this is a rather specialized request, but then again I don't think it's overly complicated either. Thanks..
> what is your request exactly? most users use a single > directory to store their photos (obviously with subfolders inside), This is often not enough. I would like to have two directories. One work related, second only for private photos. Start them from .desktop files with commands digikam --album=$HOME/digi-work and digikam --album=$HOME/digi-priv Another solution would be creation of profiles with keeping all images/albums/tags completely invisible if not belonging to current profile. There are two reasons for that: 1. Icons for albums/tags/collections are big and are taking much space. Space which could be better used for current work. 2. When I am doing small presentation for co-workers I'd like to remove any chance of them viewing photos from my holidays or some private events.
I'm sorry to tell you we will not implement this. It is easy to make a small script which does this. Something like: customPath=`kdialog --inputbox "give name of subfolder"`; sed -e 's/^Album Path=.*/\0\/'$customPath'/' digikamrc > digikamrc.new The requested option will not be used often by the majority of the users, so we will leave it this way for now.
I would like to support the request, because it's an easy way to access a) album library tree of familie members (afair other expressed this desire on the mailing list too) b) an image tree for testing c) makes it easier to implement #103371 ;) I dislike however naming it --album. Maybe something with tree or library in it? Btw. IMHO using the switch should not override the default setting in digikamrc. Achim
> I dislike however naming it --album. Maybe something with tree or > library in it? --imagelibrary? It would be extremely rarely used in CLI so don't have to keep it short. > > Btw. IMHO using the switch should not override the default setting in > digikamrc. Huh? 1. It would break 'cascade option' philosophy of most *nix tools. 2. Hot to override dikimarc?
comment #10 > Huh? > 1. It would break 'cascade option' philosophy of most *nix tools. Cascade option? Do you mean digikam --imagelibrary /one/two --imagelibrary /three/four ? This should open of course open /three/four > 2. Hot to override dikimarc? I'm mean like konsole -vt_sz XxY. Next time you start 'konsole' you do not get a window with XxY again but the still the standard size . Ditto --image-library should not override the default album library patch configure digikam ... -> albums: Album library path. Achim
*** Bug 107442 has been marked as a duplicate of this bug. ***
Reopening to merge to another bug.
*** This bug has been marked as a duplicate of 107871 ***
Fixed with https://bugs.kde.org/show_bug.cgi?id=107871