[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: [PATCH] found another listview fix
From: Michael Brade <Michael.Brade () informatik ! uni-muenchen ! de>
Date: 2001-07-31 11:09:42
[Download RAW message or body]
Hi!
Finally I know the reason for the following bug: start a drag in e.g. Konqy's
detailed listview, drop the item somewhere and cancel the action-menu. Now
press the Control-button and more the mouse around -> many files will be
selected!
This happens because QListView::contentsMousePressEvent stores true in
d->buttonDown but after starting a drag QListView::contentsMouseReleaseEvent
(that unsets d->buttonDown again) is never called. Now Qt thinks the button
is still pressed in contentMouseMoveEvent after the drag :-(
Solution: KListView calles startDrag() somewhen, so I could just put
QListView::contentsMouseReleaseEvent( 0 ) in
KonqBaseListViewWidget::startDrag() but since the problem could happen
elsewhere I'd like to ask you if the attached patch is better and ok for
committing. It fixes the problem and can't hurt because it just resets
d->buttonDown.
Please review.
Ciao,
Michael
--
Some operating systems are called `user friendly',
Linux however is `expert friendly'.
["diff" (text/x-diff)]
? diff
? xmlgui.diff2
? xmlgui.diff
Index: klistview.cpp
===================================================================
RCS file: /home/kde/kdelibs/kdeui/klistview.cpp,v
retrieving revision 1.146
diff -u -p -r1.146 klistview.cpp
--- klistview.cpp 2001/07/24 17:37:36 1.146
+++ klistview.cpp 2001/07/31 10:51:34
@@ -618,6 +618,7 @@ void KListView::contentsMouseMoveEvent(
newPos.y() < d->startDragPos.y()-d->dragDelay))
//(d->startDragPos - e->pos()).manhattanLength() > QApplication::startDragDistance())
{
+ QListView::contentsMouseReleaseEvent( 0 );
startDrag();
d->startDragPos = QPoint();
d->validDrag = false;
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic