|Summary:||THUMBBAR : wrong items selection with shift key|
|Product:||digikam||Reporter:||Dennis Grunert <post>|
|Component:||Thumbs-BarView||Assignee:||Digikam Developers <digikam-bugs-null>|
|Severity:||normal||CC:||caulier.gilles, post, skarmoutsosv|
|Latest Commit:||https://commits.kde.org/digikam/98bdea2b65ddef17eb2e973f748359b3ced3555b||Version Fixed In:||5.5.0|
Description Dennis Grunert 2012-12-13 20:22:08 UTC
openSUSE 12.2 digikam 2.6.0-3.1.2-x86_64 from openSUSE 12.2 OSS repo When selecting consecutive images with the shift key, the wrong selection is done (see steps to reproduce for details) Reproducible: Always Steps to Reproduce: 1. open digikam 2. select an album 3. view the images in the mode "view image", so that below is the image and on the top are the thumbnails of the images in the album in a row. 4. select the n-th image with a left mouse click 5. Press m times the spacebar to view the n+m-th images. 6. Now press the shift key and on the same time click the x-th image (with x > m+n) to select consecutive images Actual Results: The images n to x are now selected. Expected Results: But the user expects the images n+m (his last viewed one) to x selected. When you press the spacebar to view the next images, the blue frame which marks the currently selected images is always at the images which the user views (that's good behaviour) but when you select images with shift+mouseclick the beginning of the selection always starts where your last mouseclick was (even if it was 100 images before) and not where the blue frame is (what the user expects), so that's bad behaviour.
Comment 1 Marcel Wiesweg 2012-12-13 21:28:52 UTC
I remember I had a look at that problem previously, there may be an older bug report. What I recall, there is a field in QAbstractItemView which constitutes the "where your last mouseclick was". This field is in a private structure and inaccessible, meaning it's not fixed easily without rewriting considerable amounts of code.
Comment 2 Dennis Grunert 2013-05-23 22:41:43 UTC
It's still there in digicam 3.1, so even if (like Marcel Wiesweg said) there needs to be a lot of code rewritten, it needs to be done. The user have trust in such a simple and common function of the UI and if it doesn't work as expected, it can have consequences that one maybe only recognize later. I for myself delete photos that way (look at them with the keyboard and then mark the subset of them, which I want to delete, with shift+mouseclick). Even with a high resolution of 1680x1050 I can only see 6 photos a once, so I only notice that I deleted way to much photos once it is too late. Likely I only deleted with del-key and not shift-del and I noticed this bug quickly, but others won't.
Comment 3 Dennis Grunert 2013-07-30 14:14:49 UTC
Why is this bug not marked confirmed? Marcel Wiesweg already confirmed it's existence in his comment. This bug is one of the reason, why the amount of people with the opinion "KDE sucks" grows lager every day. KDE cannot getting to work a simple and important UI feature properly. Instead data loss is risked (I had data loss), because someone used a private instead of global structure? Somebody is willing to fix this. Where is the person, who is responsible for this wrong programing decision anyway? Com'on that all can't be true. Soon you have one person more, who buys "KDE suck" t-shirts.
Comment 4 caulier.gilles 2014-08-30 17:00:43 UTC
Denis, This file still valid using last digiKam 4.2.0 ? Gilles Caulier
Comment 5 Dennis Grunert 2014-09-04 17:56:50 UTC
Sorry, I still have 3.5 installed. But I doubt that it got fixed without marking it here upstream because the problem is already known to the devs and complicated to fix.
Comment 6 caulier.gilles 2014-09-08 12:45:09 UTC
I confirm the bug with 4.3.0 Gilles Caulier
Comment 7 Skarmoutsos Vangelis 2014-11-17 10:08:34 UTC
This bug describes erratic selection when using spacebar at preview image. I have filed the https://bugs.kde.org/show_bug.cgi?id=341032 bug, which describes about the same problem but with the use of on screen left-right navigation arrows. I confirm this bug with digiKam 4.4.0 under Debian testing (jessie) with Gnome 3.14.1 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'. Vangelis Skarmousos
Comment 8 caulier.gilles 2015-05-16 21:25:46 UTC
*** Bug 341032 has been marked as a duplicate of this bug. ***
Comment 9 caulier.gilles 2016-07-06 19:38:16 UTC
This file still valid using last digiKam 5.0.0 ? Gilles Caulier
Comment 10 caulier.gilles 2016-11-25 14:47:06 UTC
What's about this file using digiKam AppImage bundle 5.4.0 pre release given at this url : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
Comment 11 Dennis Grunert 2017-01-13 23:07:04 UTC
Yes, the bug is still valid with the digiKam AppImage bundle 5.4.0 pre release which you have provided. Everyone can test this easily with the steps described in the first comment. Only today, I deleted a few images by accident because of this bug.
Comment 12 Maik Qualmann 2017-01-15 09:39:13 UTC
Git commit 98bdea2b65ddef17eb2e973f748359b3ced3555b by Maik Qualmann. Committed on 15/01/2017 at 09:35. Pushed by mqualmann into branch 'master'. fix syncing thumbbar selection FIXED-IN: 5.5.0 M +2 -1 NEWS M +7 -2 app/views/stackedview.cpp M +9 -11 utilities/importui/views/importstackedview.cpp https://commits.kde.org/digikam/98bdea2b65ddef17eb2e973f748359b3ced3555b