diff options
Diffstat (limited to 'x11-libs/qt/files/0044-qscrollview-windowactivate-fix.diff')
1 files changed, 0 insertions, 38 deletions
diff --git a/x11-libs/qt/files/0044-qscrollview-windowactivate-fix.diff b/x11-libs/qt/files/0044-qscrollview-windowactivate-fix.diff
deleted file mode 100644
index 9a6df32..0000000
--- a/x11-libs/qt/files/0044-qscrollview-windowactivate-fix.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-qt-bugs@ issue : N45716
-applied: no
-author: Enrico Ros <>
-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
---- 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;
- }