Bug 190703

Thanks for the bug report! File management-related bugs that are common to Konqueror and Dolphin should always be filed as Dolphin bugs because Konqueror  uses Dolphin's code for file management.

I can confirm the issue in Icons view: If some icons are selected, and you click Ctrl and hold it while you're selecting more with the rubber band, the old selection gets lost as soon as the view starts scrolling.

A workaround is to scroll the view while the rubber band selection is not active, i.e., scroll first to the files you want to select additionally, and then select them while pressing Ctrl.

Zooming of view also should be blocked if the user selects files at the same time.

*** Bug 193749 has been marked as a duplicate of this bug. ***

> A workaround is to scroll the view while the rubber band selection is not
active

That only works partially (RC3 here):
It does work to mark groups of files in the directory this way when moving downwards in the directory. But let's say I have selected all files this way but now I realize I have forgotten the first two files in the directory. So I keep my hands of the keyboard as suggested and done before, scroll up, put my finger on the Ctrl key, grab the mouse and try to draw a rectangle around those two missing files - and voilà: as soon as the cursor touches the directory surface all other files get deselected...

Created attachment 36339 [details]
example

I've noticed one more thing about selecting with ctrl key. It occurs only when there is scroll bar in file's view. I scroll down to the end of view and select some files as on the screenshot. Then I try to select some other files using ctrl key. If the mouse cursor goes below the red line (when selecting), the previous selection disappears. The red line on the screenshot is drawn at about half of last icon row.

Created attachment 37520 [details]
Patch to fix it

The problem is that the Ctrl-modifier gets lost in the faked mouse event which is created in DolphinViewAutoScroller::scrollViewport(), such that QAbstractItemView thinks that a new selection is made and the old one is to be cleared. Comment 5 (which was reported again: bug 202984) seems to be the same issue - both are fixed by the same patch for me.

Note that you have to apply the patch from
http://qt.gitorious.org/qt/qt/merge_requests/1759
to test this in trunk - without it, Ctrl-rubber band selection is broken due to a regression in Qt's 4.6 branch.

*** Bug 202984 has been marked as a duplicate of this bug. ***

SVN commit 1034012 by freininghaus:

Make sure that the faked mouse event in
DolphinViewAutoScroller::scrollViewport() gets the right keyboard
modifiers. This fixes the problem that the previous selection is lost
when several Ctrl-rubber band selections are made and the view scrolls
or the mouse pointer gets close to the edge of the viewport.

BUG: 190703


 M  +2 -2      dolphinviewautoscroller.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1034012

SVN commit 1034013 by freininghaus:

Make sure that the faked mouse event in
DolphinViewAutoScroller::scrollViewport() gets the right keyboard
modifiers. This fixes the problem that the previous selection is lost
when several Ctrl-rubber band selections are made and the view scrolls
or the mouse pointer gets close to the edge of the viewport.

CCBUG: 190703

Fix will be in KDE 4.3.3.


 M  +2 -2      dolphinviewautoscroller.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1034013

There is also one more issue. As I written at point 1 in my first post selecting files and scrolling at the same time doesn't work using mouse scroll doesn't work when ctrl is pressed.

To clarify:
- Ctrl+'mouse scroll' should zoom
- Ctrl+'left mouse button'+'mouse scroll' shouldn't zoom but scroll and select files as 'left mouse button'+'mouse scroll' does it.

Created attachment 37595 [details]
Patch for the issue in comment 10

Please note that it is in general better to file one bug report per issue. This makes it much easier to keep track of the issues.

(In reply to comment #10)
> To clarify:
> - Ctrl+'mouse scroll' should zoom
> - Ctrl+'left mouse button'+'mouse scroll' shouldn't zoom but scroll and select
> files as 'left mouse button'+'mouse scroll' does it.

This sounds reasonable to me. Peter, what do you think?

I've already tried how this could be done because it seemed straightforward (see attached patch), but then I noticed that 'left mouse button'+'mouse scroll' does *not* select any items, no matter if Ctrl is pressed or not - it does so only if you move the mouse after the wheel event. This seems to be a Qt issue (both in 4.5 and 4.6).

Sorry for posting two problems in one report, but they seems to be related to the same activity.

> I noticed that 'left mouse button'+'mouse
> scroll' does *not* select any items, no matter if Ctrl is pressed or not - it
> does so only if you move the mouse after the wheel event. This seems to be a Qt
> issue (both in 4.5 and 4.6).

Actually, it does select items. However there is one condition: there must be so many files in the current view that the scroll bar appears. To select files using my method click left button, then move the mouse to left or right, then scroll using the mouse wheel - all with left mouse button clicked. You will see that the items in dolphin's window are being selected. Now you can realise the left button. This is what I meant. It doesn't work when ctrl is pressed.

(In reply to comment #12)
> To select files
> using my method click left button, then move the mouse to left or right, then
> scroll using the mouse wheel - all with left mouse button clicked. You will see
> that the items in dolphin's window are being selected.

Are you really sure? If I click, move the mouse and then scroll using the wheel without moving the mouse again (this is important), the selection is *not* updated. It is only updated if I move the mouse again.

A quick look at Qt's source code seems to indicate that this is just not implemented - QAbstractItemView does not reimplement QAbstractScrollArea::wheelEvent, which means that the scrolling takes place, but the selection is not modified (because QAbstractScrollArea is not aware of it).

Ok, you're right. After scrolling I must move the mouse once again to update selection, but this is what I mean. When the selection updates and I have done what I intended to do. The things complicates when the ctrl is pressed. Then when I try to scroll the view with the left button pressed the view is zoomed instead of scroll.

SVN commit 1040021 by freininghaus:

Do not zoom the icons if the user presses Control and the left mouse
button while using the mouse wheel. The user is probably trying to
scroll the view during a rubberband selection in that case.

Also simplify the code a bit by handling the icon zooming in
DolphinView::eventFilter().

BUG: 190703


 M  +0 -6      dolphincolumnview.cpp  
 M  +0 -6      dolphindetailsview.cpp  
 M  +0 -6      dolphiniconsview.cpp  
 M  +18 -14    dolphinview.cpp  
 M  +0 -1      dolphinview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1040021

SVN commit 1040024 by freininghaus:

Do not zoom the icons if the user presses Control and the left mouse
button while using the mouse wheel. The user is probably trying to
scroll the view during a rubberband selection in that case.

This will be in KDE 4.3.3.

CCBUG: 190703



 M  +3 -2      dolphincolumnview.cpp  
 M  +3 -2      dolphindetailsview.cpp  
 M  +3 -2      dolphiniconsview.cpp  
 M  +3 -1      dolphinview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1040024