[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