Color issues on itemviews / textedits etc. w/ autoFillBackground() == false

Thomas L├╝bking thomas.luebking at
Fri Sep 5 14:59:04 BST 2008

Various apps deactivate the autobackground of those two widgets (e.g. dolphin)
This looks nice, but casues problems if QPalette::Window contrasts 
QPalette::Base (e.g. black window, white textbase)

As Qt hardcodes the color role for Itemview-Delegates, (needs fix in 
qitemdelegate.cpp and probably various others) a workaround would be to map 
the widgts palette after deactivating the autofill:

/* this is just to avoid errors due to enum changes, one could drop the loop 
as well */
const QPalette::ColorGroup groups[3] = 
{ QPalette::Active, QPalette::Inactive, QPalette::Disabled };

/* remove the solid background */

/* map palette */
QPalette pal = QAbstractItemView::palette();
for (int i = 0; i < 3; ++i)
    pal.setColor(groups[i], QPalette::Base, pal.color(groups[i], 
    pal.setColor(groups[i], QPalette::Text, pal.color(groups[i], 
QAbstractItemView::setPalette(pal); // sic!, NOT the viewport!


QTextEdit >= 4.4 has two functions:

- QTextEdit::setTextBackgroundColor(QColor);
- QTextEdit::setTextColor(QColor);

that alter the colors of the /current/ text format, but i wasn't successfull 
in using them to fix the color
The above techinque used on itemviews however WORKS HERE AS WELL (sorry for 

Unfortunately the autofilling usually gets removed /after/ the widget got 
polished, so we cannot catch them with a workaround in the styles easily... :(
(maybe via eventfiltering QEvent::DynamicPropertyChange...?! - but that'd 
cause problems if the autofilling ever gets reactivated as the original 
base/text colors got lost)


More information about the kde-core-devel mailing list