Bug 375154 - Suggestions for improving the display of images in the trashcan
Summary: Suggestions for improving the display of images in the trashcan
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Trash (show other bugs)
Version: 5.4.0
Platform: Appimage Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-16 19:57 UTC by Jens
Modified: 2023-04-12 03:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens 2017-01-16 19:57:59 UTC
First, I like the fact that Digikam 5 now has its own trash can (for those who don't use desktop file manages - or maybe KDE - this is a plus).

However the display should be the same as selected on the toolbar. In my 5.4.0 appimage, the display is always tabular, even when "thumbnails" is selected (not "table" view). Also, XMP sidecar files are visible in the trash, these should IMHO be hidden and synchronized with the respective JPG or movie files.

Metadata like deletion time and folder could be displayed below the images (like in thumbnails view) in addition to the other metadata (the trash display should display images exactly the same as the other folders, except for this metadat).

Just my opinion, though ... it would be more consistent that way.

Thank you  :)
Comment 1 caulier.gilles 2019-03-20 15:16:12 UTC
After 3 weeks of work, i finally completed the compilation of AppImage using Qt
5.11.3 + QWebkit 5.212.

New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the
moment) :

https://files.kde.org/digikam/

Please check if this bugzilla entry still valid.

Thanks in advance

Gilles Caulier
Comment 2 caulier.gilles 2020-08-01 22:01:48 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 3 Jens 2022-01-09 08:17:59 UTC
This is still valid as of digikam 7.5.0 (git appimage 2022-01-04).
Comment 4 Maik Qualmann 2022-01-09 08:30:16 UTC
*** Bug 387319 has been marked as a duplicate of this bug. ***
Comment 5 Maik Qualmann 2022-01-09 08:40:20 UTC
Technically, the trash is outside the database and cannot use the same thumbnail view as the collection.
From my point of view, it's just a trash can to get back accidentally deleted images. If you still want to see metadata or if you are unsure about to delete the image, you should use an album/collection for images that you probably want to delete.

Maik
Comment 6 caulier.gilles 2022-01-09 08:46:04 UTC
I second Maik here :  more simple, you can use picker labels (colored flags) in your workflow. It's dedicated to mark images to plan in drop process (or not).

Gilles Caulier
Comment 7 Jens 2022-01-09 15:24:47 UTC
I understand the technical reasons for the way it is now.
But normal users will not. Especially if you have sidecar images, they will be shown in the "Trash" folder as well, as separate objects.

Can we maybe instead make the "trash" a special Digikam folder (with database and all metadata features)?
Comment 8 caulier.gilles 2023-04-12 03:11:00 UTC
The trash bin view will still a table view representation as contents is outside the database. With next 8.0.0, the file properties can be now visualized in the right sidebar from image properties tab, contents is populated from file metadata, not the database. There is no plan to other advanced layout mode to visualize the contents in trash view. 

The functionality of trash view is well explained in online documentation section:

https://docs.digikam.org/en/main_window/image_view.html#deleting-a-photograph

Gilles Caulier