Bug 341032

Summary: THUMBBAR : Multiple selection on preview image (after using onscreen arrows) has wrong edge
Product: [Applications] digikam Reporter: Skarmoutsos Vangelis <skarmoutsosv>
Component: Thumbs-BarViewAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: caulier.gilles
Priority: NOR    
Version: 4.4.0   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=311652
Latest Commit: Version Fixed In: 6.3.0

Description Skarmoutsos Vangelis 2014-11-16 19:42:21 UTC
We have the following situation:
If we preview image1 and then press one of the onscreen arrows (lets say the next arrow), then we preview image2. Now if we try to have multiple images selected with shift+click on image5, then the selected images are not image2 to image5 as expected but image1 to image5.

The above behavior happen only if we use onscreen arrows. Keyboard arrows or click on the top thumbnails, are working fine.

If a user is selecting more thumbnail images using the horizontal scrollbar then it is impossible to know that the selection is wrong. So we can consider this bug as important.
Comment 1 caulier.gilles 2014-11-17 08:50:34 UTC
Vangelis,

It's a duplicate of bug #311652 ?

Gilles caulier
Comment 2 caulier.gilles 2015-05-16 13:36:46 UTC
Vangelis,

did you seen my previous comment ?

Gilles Caulier
Comment 3 Skarmoutsos Vangelis 2015-05-16 20:09:03 UTC
Gilles: yes I did. I posted a comment on bug#311652 

This bug #341032 describes erratic selection when using on-screen left-right navigation arrows at preview image.
The bug #311652 describes erratic selection when using spacebar at preview image.

Both bugs have exactly the same erratic behavior.
They can be merged if it is clearly stated that there are two ways to create erratic selection when previewing images.

When a bug causes implicit data loss it should be considered important. Especially in the case of digiKam which is targeted to a more professional user base, data loss should be considered 'fatal'.
Comment 4 caulier.gilles 2015-05-16 21:25:46 UTC

*** This bug has been marked as a duplicate of bug 311652 ***
Comment 5 caulier.gilles 2019-08-15 08:12:55 UTC
Fixed with bug #311652