1 files changed, 0 insertions, 38 deletions
diff --git a/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff b/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff
deleted file mode 100644
index 9a6df32a7c4f..000000000000
--- a/x11-toolkits/qt33/files/0044-qscrollview-windowactivate-fix.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-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;
-         }