Version: Revision 816682 (using Devel) Installed from: Compiled sources OS: Linux Konqueror in KDE3, allow to select multiple files selecting the first, and (while SHIFT key is pressed) selecting the last: in this way all files between the two are selected too. Shouldn't this be implemented in dolphin too? This should work even in the "show in groups" mode. Thanks a lot!
I guess this behavior has changed, on KDE3, it like if you had drawn a selection rect, and on KDE4 what happens is what it selects all items between first and last. This is a WORKSFORME, not closing it yet... but I cannot reproduce.
I've just tried dolphin using revision 817980. I select a file (for example the top left one) after i click on the last one with SHIFT ... nothing happens.
What I did here: Ctrl + Click on the first one, Shift + Click on the last one. That works. Your case (selection rect only selecting the first one) and then Shift + Click on the last one doesn't work here either. Thanks for the more detailed explanation. I think this is a Qt bug, and will report it to TT if can write a successfull test case.
Ok, moreover you can select the first file even with the small "+" on the icon, but it doesn't work either.
Confirmed in KDE 4.1 beta 2 The first file is selected either by holding the Ctrl key while clicking, clicking the + icon, or by drawing a rectangle with the left mouse button. After that: 1) Ctrl-click works as expected, selecting and deselecting individual files. 2) Shift-click (select all files between two files, inclusive) only works if the original file was selected with Ctrl-click. Selecting the first file with the + icon or with a rectangle results in 0 files selected.
Created attachment 26438 [details] Screenshot showing wrong selection The attached screenshot shows that dolphin selects additional files when using the SHIFT-method for selection. I selected the file labeled with "first" and the (pressing SHIFT) selected the one labeled "second". The file "above" the first one were selected by dolphin.
I created the screenshot posted before using the kde4daily image updated to revision 838207. Btw. it's hard to select the file using SHIFT if the file icons are as small as set in the screenshot: when selecting the second file, one needs to exactly click on the icon of filename text as otherwise the selection of the first file (that is already selected) is dropped. Perhaps the space between the file items should be smaller ? -> config option: grid spacing = "very small" ? Compare to konqueror in 3.5 where only ~one pixel spacing is applied to the icon view with icons set to smallest size.
I confirm that this behaviour is weird and annoying. The way files are selected seems broken in general. For example, I can't see any way of selecting a single file. On GNOME or Windows, I can left-click on a file to activate it, and then hit Enter to run it or Del to delete it. To select the file in Dolphin, I would have to either hold down Ctrl or make sure I clicked on the little + sign. But then if I hit Del, not only that file would be deleted, but any others that happened to be already selected (and perhaps no longer visibly so). I'd advise taking a good hard look at the whole way that Dolphin handles selection.
Confirmed. I can only select (with SHIFT or CTRL) files on ONE line, if there are several lines of files in dolphin...
Sorry, let me clrafiy: If I select a whole line with SHIFT and try to select also the first item on the next line with SHIFT + RIGHT, this doesn't work as expected. Eventough SHIFT + DOWN still works (but it takes the whole next line, which is a bit rough) BTW, otherwise, I love dolphin ;-)
I can confirm Chris's bug for KDE 4.1.0 (with Qt 4.4.1). And I noticed, that there's an artifact with SHIFT+click selection. To reproduce: 1. In the folder with several lines of objects CTRL+click on the first file of range in some middle line. 2. SHIFT+click on the last file of range in some line below the line of the first file. 3. You selected the desirable range, but also some files from the lines above the line of the 1st file or files from this line, but sitting before the first file of range, are selected. It works not every time, but on the 2nd or 3rd try it will definitely appear (try different combinations of the first and last file of range).
(In reply to comment #11) > 3. You selected the desirable range, but also some files from the lines above > the line of the 1st file or files from this line, but sitting before the first > file of range, are selected. > It works not every time, but on the 2nd or 3rd try it will definitely appear > (try different combinations of the first and last file of range). > There is a pattern here. Check my screenshot from comment #6. Dolphin always additionally selects those files from the first column that have a shorter filename than the one you select first. Referring to my screenshot, when using "k3wizard.h" as selection start then it will select all files above that one except "k3socks.h" and "k3spell.h" because the latter names are shorter. Using the opensuse KDE 4.2 Live CD 1.1.80 (http://home.kde.org/~binner/kde-four-live/) I also found that error in KDE 4.2. At least in that version only the pixel width of the filename matters, not the character count. You can test it by changing from "System Font" to "Monospace" in Dolphin's settings dialog. Can someone confirm this? Btw. thanks a lot for adding the "None" option to the grid spacing box :-)
Bug reproducible only on icon view: Case A: 1) select one single file focusing it with the keyboard 2) press "SHIFT" key and keep it pressed 3) with the mouse click on another file OR, with the arrow keys, change the current file. -> All files between the first and the last will be selected. This is what an user expect and it is correct. Case B: 1) select one single file using the mouse (not using the keyboard like case A) 2) press "SHIFT" key and keep it pressed 3) with the mouse click on another file OR, with the arrow keys, change the current file. -> No file is selected and only the "focus" (dotted rectangle around the file name) is visible on the last file where whe have stop on third step. Case B should behave like case A: when a file is selected with the mouse it have to be possible to select multiple files using SHIFT+click. Case C: 1) Select the first file using CTRL+click 2) press "SHIFT" key and keep it pressed 3) with the mouse click on another file OR, with the arrow keys, change the current file. -> All files between the first and the last will be selected. So the problem is only when the first file is selected with the "+" arrow or drawing a selection around the first.
*** Bug 178871 has been marked as a duplicate of this bug. ***
I am still having problems with this in 4.2. Shift+click after pressing the + button on an icon will select a range that includes the second file I clicked, but the rest of the range that is select appears to be completely random. It also appears to select a random range when I click the plus button and then press an arrow key on the keyboard. There is no problem, however, if I select an icon with ctrl+click or with the keyboard.
Unfortunatly the bug is still reproducible using current trunk (r952068) with Qt 4.5. Moreover if you select multiple files doing: 1) CTRL+click on the first file 2) SHIFT+click on the last one for selecting the range of files between the first clicked and the last Sometimes if the second click (step 2) is done with a micro-mouse move, it will select the files AND start the copy action of the selected files to the same folder and dolphin will ask if you want to overwrite the files (with themselfs). It seems to much sensible.
Finex, using your reproduction instructions in KDE 4.2.2 on Kununtu 9.04, Dolphin selects exactly what I would expect. The problem seems to be resolved, as testing other combination of Shift and Ctrl I feel that I have complete control over what gets selected now. Please test and confirm. Thanks.
@Dothan: would you like to explain exactly the steps you've done? I can still reproduce the bug on current trunk and 4.2.2 too (Arch Linux packages). SHIFT select works only if the first file is selected with CTRL+click (or keyboard select) (on my two PC)
Ctrl-Click first, click + last: First and last files selected Ctrl-Click first, Ctrl-click last: First and last files selected Ctrl-Click first, Shift-click last: First and last files selected, and all files in between them selected as well. -- Shift-Click first, click + last: Only last file selected Shift-Click first, Ctrl-click last: Only last file selected Shift-Click first, Shift-click last: No files selected -- Click + first, click + last: First and last files selected Click + first, Ctrl-click last: First and last files selected Click + first, Shift-click last: Only first file selected -- It seems that there is a problem with Shift-click, which I did not notice before.
You can also try to select the first file dragging a "rectangular selecection" (I don't know the technical name): - rectangular selection on first file, click + last: both first and last are selected - rectangular selection on first file, ctrl+click last: both first and last are selected - rectangular selection on first file, shift-click last: no files selected (the last one has the focus dotted rectangle around the file name)
> You can also try to select the first file dragging > a "rectangular selecection" (I don't know the technical > name) I think that's called the Rubber Band. Rubber Band on first, click + last: First and last files selected Rubber Band on first, Ctrl-click last: First and last files selected Rubber Band on first, Shift-click last: No files selected Just like you got!
I think it really is a Qt issue - I can reproduce it with the Qt-only test case from http://bugs.kde.org/show_bug.cgi?id=162030#c11 I'll try to see if I can find the root cause. Some comments here are unrelated to the original report: Comment 6, comment 7, comment 11, maybe comment 15: seems to be bug 162030, which is also a Qt bug. Comment 8: You might want to enable "Double click to open files and folders" in the System Settings (Keyboard&Mouse -> Mouse). This setting will be accessible in Dolphin's own settings dialog in KDE 4.3.
The "rubberband" issue is due to incorrect handling of QAbstractItemViewPrivate's pressedPosition member, which is used in two contexts, namely to remember the start position of a rubberband selection and to remember the position of the current item. In the described use case, it still contains the start position of the rubberband selection which does not correspond to a valid model index, that's why the selection fails in QListView::setSelection(). The "selection marker issue" is a bit different: if an item is selected this way, pressedPosition is not updated at all (QAbstractItemView::setCurrentIndex would update it, but QItemSelectionModel::setCurrentIndex does not). You can see that by pressing "Home" (which makes the first item the current element), then selecting any other item using the selection marker, and then Shift-clicking a third item. The resulting selection looks like the selection using the selection marker never happened, which may make the result seem random, depending on the previous current index (comment 15). This issue can be worked around in Dolphin using the ugly hack below. But of course, I would not recommend that ;-) Maybe the best fix would be not to use pressedPosition for different purposes. I'll try to come up with a patch&unit test and submit that to Qt Software if I succeed. Sorry about the technical details, I just wanted to record my findings somewhere ;-) Index: src/selectionmanager.cpp =================================================================== --- src/selectionmanager.cpp (revision 982026) +++ src/selectionmanager.cpp (working copy) @@ -134,7 +134,9 @@ } else { selModel->select(index, QItemSelectionModel::Deselect); } - selModel->setCurrentIndex(index, QItemSelectionModel::Current); + QItemSelection oldSelection = selModel->selection(); + dynamic_cast<QAbstractItemView*>(parent())->setCurrentIndex(index); + selModel->select(oldSelection, QItemSelectionModel::Select); } } }
Created attachment 34713 [details] Patch for Qt 4.5.1 This patch fixes the "rubberband" issue for me (both for Shift-click and Shift-Arrow selections that follow the rubberband selection). The only problem is that I did not manage to simulate a rubberband selection in a unit test using the QTest framework so far (Qt Software requires new unit tests for every bug fix). After reading quite a bit of QAbstractItemView's code, I realised that the use of "pressedPosition" makes more sense than I initially thought - it's actually not used to remember the position of the current item, but rather the position of the item that is the starting point of any Shift-Click or Shift-Arrow selection, which is not necessarily the same. You can see that by pressing "Home" to select the first item and then Shift-clicking any other item, which then becomes the new current item. If you Shift-click another item then, everything between this item and the *first* item will be selected. It turns out that QAbstractItemView::setCurrentIndex() updates the "current item" and "pressed position", whereas QItemSelectionModel::setCurrentIndex(), which is used for "selection marker" selections, updates only the "current item". The consequence is that a "selection marker" selection does not update "pressedPosition", i.e., the starting point for the next Shift-selection, and there is no way of changing this inside Qt. If one wanted to change this, something like the hackish patch I pasted in my previous comment would probably be needed.
*** Bug 200877 has been marked as a duplicate of this bug. ***
@Frank: has the patch been accepted by Qt? Selecting files in dolphin is still quite difficult due to this and some other similar bugs.
I haven't submitted the patch yet because I was unable to come up with a new unit test so far (the Qt people require new unit tests for all bug fixes). I don't have much time at the moment, but I hope I'll be able to look further into this at some point. If anyone else has some time to investigate this, feel free to do so - I still think my patch from comment 24 might be the right way to solve this, I just don't know how to simulate a rubberband selection in a unit test.
*** Bug 205137 has been marked as a duplicate of this bug. ***
Created attachment 36679 [details] Simple Qt-only test case for my upcoming merge request
Here is my merge request: http://qt.gitorious.org/qt/qt/merge_requests/1426
The fix has been merged for Qt 4.6.0: http://qt.gitorious.org/qt/qt/commit/807185d250fd8f5152cafdb416f28abe4438275f With this commit, the "rubberband" issue is fixed. The "selection marker" issue has been improved, but not entirely resolved because it's a bit different as I said earlier. There's still bug 200782 to keep track of that, so I think that this report can be closed :-)
Thanks for the good news Frank :-)