1 files changed, 38 insertions, 0 deletions
diff --git a/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff b/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff
new file mode 100644
index 000000000000..9a6df32a7c4f
--- /dev/null
+++ b/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff
@@ -0,0 +1,38 @@
+qt-bugs@ issue : N45716
+applied: no
+author: Enrico Ros <eros.kde@email.it>
+
+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.
+
+--- src/widgets/qscrollview.cpp.orig	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;
+         }