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 <
[hidden email]> 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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
