Version: 1.3.80 (using 4.3.80 (KDE 4.3.80 (KDE 4.4 Beta1)), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.26-2-amd64 When in details view, it is not possible to select more than 2 items using keyboard (SHIFT+Arrow).
Bug confirmed, I'm using the same version (from OpenSuse repositories)
I had first suspected that it has something to do with my fix for bug 201459, but it seems that this is not the case. I then tried to reproduce this using a plain QTreeView with a simple string list model, but selection works fine there. Very strange bug.
OK, I think I know what's going on. Actually, it is due to a change of mine, but a change in Qt, namely http://qt.gitorious.org/qt/qt/commit/807185d250fd8f5152cafdb416f28abe4438275f which fixes bug 163451. But the change in Qt is only the reason why the bug is visible now, it is a bug in DolphinDetailsView. The problem is the Details View redefines the clickable rectangle for each item from the default in QTreeView and reimplements QModelIndex DolphinDetailsView::indexAt(const QPoint& point) accordingly. But it does not reimplement QRect QTree::visualRect(const QModelIndex &index). The result is the following: 1. QAbstractItemView uses d->pressedPosition to track the point in the view which is the starting point for any Shift-selection. 2. If a selection is made using Shift-Click or Shift-Arrow and if indexAt(d->pressedPosition) does not return a valid model index, QAbstractItemView::MousePressEvent and QAbstractItemView::KeyPressEvent set d->pressedPosition to the center of the visualRect of the current item (which is as wide as the "Name" column). However, the center of this rectangle is frequently outside the "real" rectangle for the item -> indexAt(d->pressedPosition) returns an invalid model index again in the next step, and the result is rather unexpected. To check this, just make the "Name" column smaller - as soon as the file names occupy more than half its width, the center of the visualRect returns the right model index, and selection works. So the solution would be to reimplement the visualRect method and return the correct rectangle.
*** Bug 217582 has been marked as a duplicate of this bug. ***
*** Bug 217844 has been marked as a duplicate of this bug. ***
SVN commit 1060716 by freininghaus: Rename Dolphin View's nameColumnRect member to visualRect. This overrides QTreeView::visualRect, such that the "visual rect" matches the area used in indexAt. Fixes the problem that the selection loses items in the Details View when selecting new items with Shift+Keyboard. BUG: 217447 M +15 -15 dolphindetailsview.cpp M +1 -2 dolphindetailsview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1060716
Thanks! Now Dolphin feels much better (this fixed some other selection details).
It is not fixed yet. In some cases the initial selection file might be unselected. I failed to make a simple testcase, it seems I would need to describe the whole folder. Instead video: http://www.youtube.com/watch?v=dCzpMB_cCnI (or download with clive)
Hmm, I can reproduce it sometimes, but only if the view is scrolled down. Is that also the case in your video? It's not so easy to see because it's so small ;-) It looks like the view offset has to be added or rather subtracted at some place, but I would guess that this is somewhere in QAbstractItemView, most likely in lines 1540 and 2091 which were changed in the commit I linked to in comment 3. BTW, thanks for your great reports, it's very helpful to get informed about these little regressions early, so we can try to fix them before they annoy many users!
Created attachment 38997 [details] Patch for QAbstractItemView This seems to fix it for me. Note that the offset has to be subtracted in two places because this can also be reproduced with Shift+mouse click selection. I'll file a merge request with Qt for that, but I have to write a unit test first. That requires more than just two lines of code, I'm afraid. I don't have much time this weekend, but I hope I can do it during the next week.
The issue I've described in comment 9 is fixed in Qt already: http://bugreports.qt.nokia.com/browse/QTBUG-6407 http://qt.gitorious.org/qt/qt/commit/2263a796ac6fc84002ff075eb6cbc67e0ec27802 The fix will be in Qt 4.6.1. David, can you confirm that you see this problem only if the view is scrolled down? If not, it would be good to know how to reproduce this. Thanks!
> David, can you confirm that you see this problem only if the view is scrolled > down? If not, it would be good to know how to reproduce this. Thanks! Yes. So that is why I was not able to make a testcase.
OK, I think we can close this report again then. Using KDE 4.4 Beta 2 or later and Qt 4.6.1 or later, both issues will be fixed :-)
*** Bug 218792 has been marked as a duplicate of this bug. ***
*** Bug 222979 has been marked as a duplicate of this bug. ***
SVN commit 1076115 by freininghaus: Backport commits 1060716 and 1062076 to the 4.3 branch: Rename DolphinDetailsView's nameColumnRect member to visualRect. This overrides QTreeView::visualRect, such that the "visual rect" matches the area used in indexAt. Fixes the problem that the selection loses items in the Details View when selecting new items with Shift+Keyboard (if Qt 4.6 is used). CCBUG: 217447 Reimplement visualRegionForSelection in DolpinDetailsView. Fixes the problem that not the entire area affected by changing the selection gets updated. QTreeView::visualRegionForSelection assumes implicitly that the visualRects of all items have the same width, which is not the case here after the fix for bug 217447. CCBUG: 218114 Fixes will be in KDE 4.3.5. M +30 -15 dolphindetailsview.cpp M +3 -2 dolphindetailsview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1076115
*** Bug 223376 has been marked as a duplicate of this bug. ***