Workaround for a (IMHO) design-flaw in the style/palette handling. Styles

like liquid that need to recalculate things on a palette change can get
seriously confused when a class specific palette is polished

1 files changed, 23 insertions, 0 deletions

diff --git a/qt/qte234-for-opie091-setpalette.patch b/qt/qte234-for-opie091-setpalette.patch
new file mode 100644
index 0000000..2aee4e5
--- a/dev/null
+++ b/qt/qte234-for-opie091-setpalette.patch
@@ -0,0 +1,23 @@
+        --- src/kernel/qapplication.cpp.origSat Sep 21 05:01:47 2002
+        +++ src/kernel/qapplication.cppSat Sep 21 05:24:42 2002
+@@ -1187,8 +1187,19 @@
+ {
+     QPalette pal = palette;
+ #ifndef QT_NO_STYLE
+-    if ( !startingUp() )
++    if ( !startingUp() ) {
+                qApp->style().polish( pal );// NB: non-const reference
+        +if ( className ) {
+        +    // if we just polished a class specific palette (this normally 
+        +    // only called by qt_fix_tooltips - see below), we better re-
+        +    // polish the global palette. Some styles like liquid can get 
+        +    // confused, because they can not detect if the polished palette 
+        +    // is the global one or only a class specific one.
+        +    // (liquid uses this palette to calculate blending pixmaps)
+        +    QPalette p = qApp-> palette ( );
+        +    qApp->style().polish ( p );
+        +}
++    }
+ #endif
+     bool all = FALSE;
+     if ( !className ) {