Bug 493193 - Deletion of image from album in thumbnail view re-indexes active position to top row
Summary: Deletion of image from album in thumbnail view re-indexes active position to ...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-ItemsSort (show other bugs)
Version: 8.5.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-16 10:44 UTC by Roland
Modified: 2024-09-16 17:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roland 2024-09-16 10:44:30 UTC
SUMMARY
On a file delete via an Album (thumbnail) view, the physical position of the active item changes if the item isnt on the top row of displayed thumbnails. 

STEPS TO REPRODUCE
1.  For any album with say 100+ images indexed, where there may be say 4 rows of 5 columns of thumbnails shown, select say Row3 Column3 and delete that image via 'Del' key

OBSERVED RESULT
Selected image is deleted, and list of thumbnails is reset such that the now-active/selected image (which will be the next image in sequence unless the last image) is in the correct column (Column3), but the view has shifted the listed thumbnails up so that you are now at position Row1 Column3

EXPECTED RESULT
The physical position of the newly active (focus-inheriting) image thumbnail should not change on an item delete. This jump of active image position is exactly what you would expect if you had accidentally selected a group of photos before hitting Delete, and that is both concerning, and it tends to be a bit of a lurch where effectively no other systems- from a file delete in Explore (Windows) to an image preview in whatever viewer- shift the active cursor position (exception for the last file in the collection, where the position must move to the new 'last' item in the collection).

SOFTWARE/OS VERSIONS
Windows: 10 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Roland 2024-09-16 10:53:31 UTC
Incidentally, as a drag-to-move a file from one album to another is treated as a delete for the source album, this same re-index of focus/position behavior happens on moves.
Comment 2 Maik Qualmann 2024-09-16 11:50:31 UTC
In this comment you wanted the item to be placed at position 1 in the view after the deleted ones. ((:-))

https://bugs.kde.org/show_bug.cgi?id=489501#c2

Maik
Comment 3 Maik Qualmann 2024-09-16 17:50:39 UTC
Git commit 580be98aefe99d259bc8ceb6ba1995fd377c19ef by Maik Qualmann.
Committed on 16/09/2024 at 17:49.
Pushed by mqualmann into branch 'master'.

check if current item is within the view after deletion
FIXED-IN: 5.8.0

M  +1    -1    NEWS
M  +4    -5    core/libs/widgets/itemview/itemviewcategorized.cpp

https://invent.kde.org/graphics/digikam/-/commit/580be98aefe99d259bc8ceb6ba1995fd377c19ef
Comment 4 Maik Qualmann 2024-09-16 17:54:53 UTC
Explanation of current behavior with this commit.
If the current item is within the view after deletion, we do nothing.
If the next current item is outside the view after deletion, we now scroll it to the center of the view.

Maik