[Digikam-devel] [Bug 246869] Deleting albums, as described, is either broken or insane

[Kelsey Bjarnason]

https://bugs.kde.org/show_bug.cgi?id=246869





--- Comment #2 from Kelsey Bjarnason <kbjarnason gmail com>  2010-08-06 12:09:04 ---
On August 6, 2010 01:19:24 am Johannes Wienke wrote:
> https://bugs.kde.org/show_bug.cgi?id=246869
> 
> 
> Johannes Wienke <languitar at 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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.