incomplete non-MotionNotify event handling in mouse move compression loop

In src/gui/kernel/qapplication_x11.cpp ( QETWidget::translateMouseEvent() ), there exist cases where (perhaps a significant number) of non-MotionNotify events are processed without returning to the event loop, perhaps most importantly, without giving QAbstractEventDispatcher::filterEvent() a chance to see the event first. This is currently impacting KDE (see http://bugs.kde.org/show_bug.cgi?id=275469) which relies on getting PropertyNotify events passed to filterEvent().

I have attached three possible patches to fix this issue, the first, which simply calls filterEvent(&nextevent) prior to processing each non-MotionNotify event in QETWidget::translateMouseEvent(), the second, which reduces the 'aggressiveness' of the mouse move event compression by only treating contiguous blocks of MotionNotify events, and the third, similar to the second, but which allows non-contiguous groups of MotionNotify events.

I have tested all three patches and they appear to fix the KDE issue (http://bugs.kde.org/show_bug.cgi?id=275469). The first patch (or similar), being the least invasive, may be the most appropriate. With the second and third, in my testing I don't see any impact, but the second does reduce the 'degree of compression' achieved, and the third, may cause issues due to event processing re-ordering.

ADDITIONAL INFO:

I mentioned in the first attached patch that the issue may occur elsewhere in Qt X11 event processing code. Specifically, I'm referring to three additional places one in src/gui/kernel/qclipboard_x11.cpp, one in src/gui/kernel/qdnd_x11.cpp, and one in src/gui/kernel/qwidget_x11.cpp.

The attached patch

03-qt-opensource-4.8.0-x11-event-processing-mods.01.patch

includes modifications addressing the issue (along with a tighened up version of my recommended change to
src/gui/kernel/qapplication_x11.cpp).

thanks for your time,
John