qt/patches/qt-3.3.4-flickerfree_qscrollview_fixwindowactivate.patch

QScrollView unwanted repaint fix.

This fixes the 'flashing' konqueror window on activation / deactivation by
saving 1 unwanted repaint (when konqueror window has background).
I tracked down to the problem to the internal QViewportWidget of the
QScrollView class.

When a window is activated the activation event is recursively propagated
to all childs triggering the windowActivationChange() functions in the
widget it passes by.
What happens when the event gets to the Viewport?
At this point the event has already been handled by windowActivationChange()
of the parent widget (a QIconView for example) and has then been propagated
to the Viewport that will handle it with the default
QWidget::windowActivationChange implementation, maybe raising an unwanted
update(); so here we stop the event.
As an addition: if the parent reimplements the windowActivationChange()
function, mainly to block the update, it won't be happy if the child will
trigger the update. If the parent do not reimplement the function il will
inherits the default implementation and there is no need for the viewport's
one.

Enrico Ros <eros.kde@email.it>

--- src.orig/widgets/qscrollview.cpp	2004-03-29 10:17:04.000000000 +0000
+++ src/widgets/qscrollview.cpp	2004-03-30 16:40:07.599978320 +0000
@@ -1551,6 +1551,9 @@
         case QEvent::LayoutHint:
             d->autoResizeHint(this);
             break;
+        case QEvent::WindowActivate:
+        case QEvent::WindowDeactivate:
+            return TRUE;
         default:
             break;
         }
1	niro	153	QScrollView unwanted repaint fix.
2
3			This fixes the 'flashing' konqueror window on activation / deactivation by
4			saving 1 unwanted repaint (when konqueror window has background).
5			I tracked down to the problem to the internal QViewportWidget of the
6			QScrollView class.
7
8			When a window is activated the activation event is recursively propagated
9			to all childs triggering the windowActivationChange() functions in the
10			widget it passes by.
11			What happens when the event gets to the Viewport?
12			At this point the event has already been handled by windowActivationChange()
13			of the parent widget (a QIconView for example) and has then been propagated
14			to the Viewport that will handle it with the default
15			QWidget::windowActivationChange implementation, maybe raising an unwanted
16			update(); so here we stop the event.
17			As an addition: if the parent reimplements the windowActivationChange()
18			function, mainly to block the update, it won't be happy if the child will
19			trigger the update. If the parent do not reimplement the function il will
20			inherits the default implementation and there is no need for the viewport's
21			one.
22
23			Enrico Ros <eros.kde@email.it>
24
25			--- src.orig/widgets/qscrollview.cpp 2004-03-29 10:17:04.000000000 +0000
26			+++ src/widgets/qscrollview.cpp 2004-03-30 16:40:07.599978320 +0000
27			@@ -1551,6 +1551,9 @@
28			case QEvent::LayoutHint:
29			d->autoResizeHint(this);
30			break;
31			+ case QEvent::WindowActivate:
32			+ case QEvent::WindowDeactivate:
33			+ return TRUE;
34			default:
35			break;
36			}