[PATCH] Font color fixes with partly inverted color schemes

[Thomas Lübking]

Ok, after actually reading Michaels mail -thus his intention- i think the core 
problem *in this very case* /might/ be the fact that the delegate does not 
pass a widget (what /could/ be ::parent(), might need to be set)

Therefore the style (even if properly implemented) /cannot/ make up an idea 
about the widget role and therefore will (very likely as that's the default) 
fallback to QPalette::Base for the hover indication shading (if not using 
transparent colors) -> the wrong color is used for shading.

Solution for /this/ case (only): pass the (parent) widget.
(Though this will still fail in case the style hardcodes the base color)

Thomas


Am Sunday 25 October 2009 schrieb Thomas Lübking:
> This is triggered by the very last change, adding "( option.state &
> QStyle::State_MouseOver )"
> 
> The reason is a structural problem, the ui style is invoked to paint the
> general item background, including the hover indicator.
> For many styles this is a shade between the background (or wrongly
>  implemented the base) color and the highlight color, but actually it could
>  be everything (and is in Michaels case rather shifted towards the
>  highlight color, maybe depending on the highlight/background value or
>  contrast)
> 
> This is no problem as long as the style also paints the foreground, but
>  this is not the case here.
> Therefore the style and the delegate do NOT share information about the
> current background structure.
> 
> There three options to solve this:
> a) take full control over the painted background as well (especially the
>  hover indication)
> b) hope for the style to set a proper color and only alter the color when
> really about to paint the packground (focus indicator)
> c) redirect the background painting and analyze it, then pick a contrasting
> color
> 
> The best option would imho be a.
> (b is unreliable and c pretty inefficient)
> 
> To do this you'll have to copy the styleoption, delete the hover flag from
>  the copy, pass this down to the style, paint your own hover indicator
>  that's guaranteed to contrast either with the highlight or window text
>  color. (If you're evil you can store the flag, const_cast the option and
>  reset the flag)
> 
> Side note:
> I'd strongly suggest to make the fg/bg roles properties and set them with
>  the delegate, otherwise e.g. a switch to base/text colors will force you
>  to alter the delegate as well and you could not use the same delegate
>  implemantation of different visual approaches just for a color bug.
> 
> Regards,
> Thomas
> 
> Am Sunday 25 October 2009 schrieb Mark Kretschmann:
> > Michael, the patch does strange things with the text color when
> > hovering over an item with my default color scheme. It's now white
> > instead of black, causing readability issues,.
> >
> > I'm attaching two screenshots that illustrate the problem, first old,
> > then new. See the topmost item of the playlist on the right side.
> 
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>