Contents of /trunk/qt/patches/qt-3.3.4-flickerfree_qscrollview_fixwindowactivate.patch
Parent Directory | Revision Log
Revision 153 -
(show annotations)
(download)
Tue May 8 20:52:56 2007 UTC (17 years, 4 months ago) by niro
File size: 1540 byte(s)
Tue May 8 20:52:56 2007 UTC (17 years, 4 months ago) by niro
File size: 1540 byte(s)
-import
1 | 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 | } |