[PATCH] Font color fixes with partly inverted color schemes

Thomas Lübking thomas.luebking at web.de
Sun Oct 25 20:20:08 CET 2009


Am Sunday 25 October 2009 schrieb Michael Reiher:
> Erm... to be honest I can't really follow you here ;) 
Sorry. The basic problem is that the item is painted by two independent libs 
at the same time and there's no communication for them to agree (used)

>  highlight background. I tried a few color settings now and can't find a
>  problematic corner case. So, attached is the patch without the highlight
As mentioned:
the widget style /could/ do "weird" things when painting the hover indicator 
(eg. use the hover color the KDE colorscheme adds that could be much different 
from the highlight color)
As the delegate doesn't really know what the (current!) style does and the 
style /may/ have wrong expectations (Qt likes to hardcode QPalette::Text for 
several standard itemview delegates) things /could/ collide.
(As "ugly" but working approach I just set (bespin) the base color to the 
window color for the various "transparent listview" approaches.)
 
> Another thing is, that it seems strange to set the foreground color
>  scattered across several places (esp. my InlineEditorWidget fix is a bit
>  ugly). Shouldn't it be set at the same central place where the view
>  background is set? I just couldn't figure out where that is...
Yes, that's what i meant by providing the delegate information about the 
attached itemview and it's color roles and use the role variable rather than 
hardcoding a specific one.
 
Thomas


More information about the Amarok-devel mailing list