| Summary: | Deleting albums, as described, is either broken or insane | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Kelsey Bjarnason <kbjarnason> |
| Component: | Database-Trash | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 1.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.5.0 | |
| Sentry Crash Report: | |||
|
Description
Kelsey Bjarnason
2010-08-06 06:16:21 UTC
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 |