I just found out, that also the Icons view (it does not matter whether the "Show in Groups" Option is enabled or disabled) is also affected by this bug.

The Columns View is the only one that is not affected by this bug

what do you exactly expect?

Some tests using my home directory (default folder when dolphin starts, I've about 10 directories and 5 files)
Dolphin from trunk r999148
Qt 4.5.2-3 (archlinux)



*** ICON VIEW ***

1) start dolphin (not use an already opened window)
2) select first two files with the "+"
3) shift+click a file below

-> the files from the last selected on point 2 until the shift-clicked file plus the first file selected on point 2 will be selected

4) now click on an empty space (the selection is lost)
5) repeat point from 2 to 3

-> only the first file stay selected



*** LIST VIEW ***

1) start dolphin
2) select the first file of the list with the "+"
3) select the third file of the list with the "+"

-> the first file is un-selected but i keep testing the "shift-click" behaviour

4) shift+click to the last file

-> all files between the one selected on point 3 and on point 4 are selected

5) click on an empty space to loose the selection

6) repeat point from 2 to 4
6.2 ) click on the first file with "+"
6.3 ) click on the second file with "+"

-> good, this time both are still selected

6.4 ) shift-click to the last file

-> the first two selected files are no more selected and only the last shift-clicked file is selected.



*** COLUMN VIEW ***

1) start dolphin
2) select the first file of the list with the "+"
3) select the third file of the list with the "+"

-> both are still selected, good...

4) shift clik the last file of the list

-> the last file is added to the selection, like when CTRL+click

5) click on an empty space to loose the selection

6) repeat the steps from 2 to 4

-> like before: the last file is added to the selection, like when CTRL+click


*** FINAL NOTES ***

It looks that selection is still on a odd state, there are some other issues reported on the past which has similar problem, or maybe all problems have a common root, I don't know...

FiNeX: this was already noticed by you in http://bugs.kde.org/show_bug.cgi?id=163451#c4, it's a bit different from the rubberband selection issue which was discussed originally in that report, see my comment http://bugs.kde.org/show_bug.cgi?id=163451#c23.

To make Shift-selection in combination with selection markers work as expected (i.e., make Shift-Arrow select all items between the last one which was selected with a selection marker and the new current item), the only solution I can see currently is to use something like the hackish patch in my comment http://bugs.kde.org/show_bug.cgi?id=163451#c23.

To be precise, an ugly patch that (hopefully) makes the combination of Shift-selection and selection marker-selection work as expected is

Index: src/selectionmanager.cpp
===================================================================
--- src/selectionmanager.cpp    (revision 999357)
+++ src/selectionmanager.cpp    (working copy)
@@ -134,7 +134,10 @@
             } else {
                 selModel->select(index, QItemSelectionModel::Deselect);
             }
-            selModel->setCurrentIndex(index, QItemSelectionModel::Current);
+            QItemSelection oldSelection = selModel->selection();
+            dynamic_cast<QAbstractItemView*>(parent())->setCurrentIndex(index);
+            selModel->clearSelection();
+            selModel->select(oldSelection, QItemSelectionModel::Select);
         }
     }
 }

The earlier version which I posted in the other bug report makes the "-" selection marker not work any more.

I always find it amazing how complicated item selection is - it looks so simple at first sight, but the longer you try it, the more issues you find ;-)

@Frank: yes, I remember that bug, this only add one more step before (the first of the two "+" clicks). I've rewrote all again for completeness :)

(In reply to comment #5)

:-)

You're right, it was not obvious at first sight if all these issues are related or not, but after reading the relevant code, I'm pretty sure they are.

@Frank: Probably *all* the selection problems are related :-)

The situation will be somewhat improved when using Qt 4.6.0 because of the fix for bug 163451.

This will work now: a Shift-click or Shift-Key selection after a "selection marker" selection should yield the expected result if no item was selected using a direct mouse click (or Ctrl-click) or using the keyboard before. It will also work if a rubberband selection was done before the selection marker selection.

This will not work: imagine you have a folder with five files A, B, C, D, E. Ctrl-click A (or just click it in single-click mode). Click the selection marker "+" on E. Then Shift-click C. After that, A, B, and C will be selected, and not C, D, E as expected.

To fix the remaining issue, one could use my hackish patch from comment 4. An alternative might be to send a Ctrl-click event for the item whose selection marker was clicked to QAbstractItemView in SelectionManager::setItemSelected (Ctrl-click and clicking the SelectionToggle have essentially the same effect, and simulating a click event would assure that QAbstractItemView sets QAbstractItemViewPrivate's pressedPosition member correctly). I cannot see any other way at the moment.

Actually, we can now fix the "This will not work" part from my last comment with the new view engine that Dolphin gets in KDE 4.8 :-)

Git commit 513b831eebe3a5845f5a1a141ee370fd10d7172b by Frank Reininghaus.
Committed on 15/12/2011 at 00:36.
Pushed by freininghaus into branch 'master'.

Start an anchored selection when clicking a selection marker

BUG:200782
FIXED-IN:4.8.0

M  +4    -0    dolphin/src/kitemviews/kitemlistcontroller.cpp

http://commits.kde.org/kde-baseapps/513b831eebe3a5845f5a1a141ee370fd10d7172b