Bug 444801

Cannot reproduce.

i'll test again with next release...

fwiw, columns can be rearranged by dragging them, but the list itself cannot be sorted at all (by clicking on the header of the column).
Maybe you got that wrong.

I can reproduce this bug in RC1. Probably the same issue as Bug #443029. The problem seems to appear in any Qt4 application but only in virtual machines (VMware, KVM), not on a physical machine.

This only happens when using the "vmmouse" driver.
This driver produces wrong click events:

----
MotionNotify event, serial 34, synthetic NO, window 0x3200001,
    root 0x5d, subw 0x0, time 827296, (86,46), root:(678,71),
    state 0x0, is_hint 0, same_screen YES

ButtonPress event, serial 34, synthetic NO, window 0x3200001,
    root 0x5d, subw 0x0, time 827297, (86,46), root:(678,71),
    state 0x0, button 1, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x3200001,
    root 0x5d, subw 0x0, time 827381, (86,46), root:(678,71),
    state 0x100, is_hint 0, same_screen YES

ButtonRelease event, serial 34, synthetic NO, window 0x3200001,
    root 0x5d, subw 0x0, time 827381, (86,46), root:(678,71),
    state 0x100, button 1, same_screen YES
----

The MotionNotify seems to cause the problem with qt4. With the "mouse" driver I only get the Button events and sorting the columns works fine.

I also find that occasionally in konquerer text is marked when clicking somewhere on the page.
I assume that the vmmouse driver creates a move event from the last click position to the new click position. Maybe a feature and sometimes needed in vmware?

-> reopening

@KDE team, if you think qt4 is behaving well and the vmmouse is buggy, please assign to the xorg team; I'm not sure where exactly the problem is and if the vmmouse behaviour should not be harmful.

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

Xlib documentation, 10.5.2. Keyboard and Pointer Events:
The X server reports MotionNotify events to clients wanting information about when the pointer
logically moves. The X server generates this event whenever the pointer is moved and the pointer
motion begins and ends in the window. The granularity of MotionNotify events is not guaran-
teed, but a client that selects this event type is guaranteed to receive at least one event when the
pointer moves and then rests.

I don't think the pointer "logically moves" in this case, so this should be a problem in the driver.

Given that a mouse in most cases moves a bit when you press a button because of the sensitivity of today's optical sensors, a toolkit should accept small movements during clicks anyway.

The Xlib documentation Lubos cited states that on moves MotionNotify is generated, but NOT that it is not generated if there is no move. A toolkit has to behave gracefully here.

Adding Egbert for validation, reassigning to kde.

Egbert, do you agree with Matthias here?  If so I'll upstream to Qt's bugtracker.  I guess Qt could discard any MotionNotifys at the same coordinates as the ButtonPress.

(WIP - analysis for Qt:
Summary: Some X11 mouse drivers generate MotionNotify events between ButtonPress and ButtonRelease with the same coordinates.

Our X developers say this is within Xlib specification.    

Because of how QHeaderView handles mouse move events, it is impossible to click QHeaderView given these 'stationary' move events:

If QHeaderView receives mouseMoveEvent while in state QHeaderViewPrivate::MoveSection even if the move is less than startDragDistance,  it shows the section indicator.  If this is visible at the mouseReleaseEvent, the event is treated as the end of a drag, instead of a click.  I suggest not showing the section indicator until a move event that is not at firstPos.

)

bump

Egbert? ping!

FWIW, the issue seems to be fixed in recent releases.
At least in my openSUSE 11.3 VM I do not have any problems anymore with vmmouse.

Thanks. So let's finally close the issue as fixed. :-)