Version: 1.3.0 (using KDE 4.4.95) OS: Linux from help: "When you delete an Album from digiKam it will be moved into the KDE Trash Can. As an option you could change this behavior, so that delete really did remove the Album and all of the photographs in it." So, according to the first, only the _album_ - ***not*** the pictures in it - will be moved to trash, right? Somehow, the documentation here does not fill me with confidence that this is the case. If it _is_ the case - if Digikam behaves sanely and leaves the images alone, simply wiping it's own personal "view" of them, the documentation should be clear on that. Reproducible: Always Steps to Reproduce: Delete an album. Actually, don't. I won't; I can't trust the app, based on the documentation, _not_ to delete everything in sight. Actual Results: No idea; I'm too barking scared to try it. Expected Results: Digikam's "view" - database entries, etc - are wiped, but the files are right where they should be, in their happy little folders, untouched, since I did not select "delete everything you can possibly find", I selected "delete album". Instilled confidence that the developers grasp the concept that deleting things is a bad idea, especially when they completely fail to differentiate between the actual data files and their app's internal "view" of said data files. Delete the view, by all means. Leave the files alone, unless _asked_ _explicitly_ to delete the _files_. Unfortunately, there's no category for "Insanely critical, fix this _yesterday_, not just "causes data loss", but does so catastrophically.
The concept of digikam is to actually manage the real image files. The internal database is always synchronized with the collection roots you have specified. If you do not want digikam to manage certain images, you can place them in a folder that is not under an digikam collection. The part from the documentation only wants to say that you can either chose the trash or a direct delete operation without using the system's trash. Album is nothing more than a folder in the file system, hence it includes the images in it when deleting it. We can try to rephrase the section of the documentation. Who maintains the docs? Do we have an extra component in bugzilla for this?
On August 6, 2010 01:19:24 am Johannes Wienke wrote: > https://bugs.kde.org/show_bug.cgi?id=246869 > > > Johannes Wienke <languitar@semipol.de> changed: > > What |Removed |Added > --------------------------------------------------------------------------- > - Severity|major |normal > > > > > --- Comment #1 from Johannes Wienke <languitar semipol de> 2010-08-06 > 10:19:22 --- The concept of digikam is to actually manage the real image > files. Fine; where does one get a decent image management app, then? Digikam would be fantastic except for its penchant for deleting everything it can at the slightest provocation. That little behaviour renders it the single most dangerous application available to my system, apart from perhaps gparted. > The part from the documentation only wants to say that you can either chose > the trash or a direct delete operation without using the system's trash. Except it fails to mention anything about the _files_ therein, except where it suggests they can be summarily nuked. > Album is nothing more than a folder in the file system, hence it includes > the images in it when deleting it. Therein perhaps lies the problem. I already _have_ a folder of images. Several of them. I don't need another file manager, I have Konq and Dolphin and who knows what for that. I need something to manage my images. Fire up DK, add the images to its database, process, modify, tag, all's good. Tell it to delete the _files_, fine, that's my call. Tell it to delete the "album"... go ahead, delete the album - the description, image tags, all the database fields, you name it, I don't care. Note I said delete _album_. Nothing in that process even hints at deleting _files_. How about renaming the "delete album" function to "recursively delete every single image off the disk, forever", just to be clear? As it's presented in the UI, it _appears_ to work as it _seems_ to work - an "album" being nothing more than a database-backed set of info _about_ images. If, in fact, an "album" is nothing more than a folder, don't _call_ it an "album", as this implies it is _not_ a folder, but something else, something different, with different semantics. You know, something where deleting it _isn't_ deleting a folder, it's deleting an album - the data _about_ the images. Digikam remains simply too farking dangerous to be allowed anywhere near a user's machine, because it conflates two completely different concepts - collections of files and collections of data _about_ the files - presents them as one thing, but _acts_ on them as the other. It _presents_ albums as data sets, but it _acts_ on them as folders. Meanwhile, I'm forcibly blacklisting Digikam[1] on the systems on my LAN, as well as on my clients' systems. Until its UI makes it clear that it does not in fact mean "album", but instead means "folder", delete operations which should be trivial are in fact ridiculously dangerous and thus the app _cannot_ be allowed anywhere near a system where users might actually want to keep their files. [1] Where possible via repository blacklisting; for Windows clients, it'll have to be simple emails and praying nobody's insane enough to use this thing without a triply-redundant backup in place, to recover from the damages it does.
Sorry, but if this is not the behavior you want from a photo management tool than digikam probably isn't the right tool for your job. Most other users expect this behavior.
Johaness > Who maintains the docs? Do we have an extra component in bugzilla for this? ==> digiKam team of course... Gilles Caulier
But there's no extra component?
no extra component yet for digiKam doc (:=)))
Wouldn't it make sense to have one because most of the time documentation can be written without programming and different maintainers can do this?
Sure. done in bugzilla Gilles