[PATCH] Font color fixes with partly inverted color schemes

[Michael Reiher]

Erm... to be honest I can't really follow you here ;) My main problem was that 
I couldn't read the normal fonts (no selection, no highlight). This is simply, 
either because the foreground color is not set at all (InlineEditorWidget) 
while the background is or because the foreground color is set, but to the 
wrong value.

The hover thing is "something I came across". Not really a problem for me. 
I've sitting this on my disk for a while now, and honestly as I think about it 
I don't know why I did that ;) Well, part of it was that it seemed wrong to 
not use highlight foreground when the background is colored with 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 part.

One thing left is that you can easily create color schemes where some things 
in the context area become hard to read e.g. the 5 entries in the "Current 
Track" applet when no song is currently playing.

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...

Michael

On Sunday 25 October 2009 18:02:16 Thomas Lübking wrote:
> 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
> 
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amarok_font_colors2.diff
Type: text/x-patch
Size: 4179 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20091025/03180bf9/attachment-0001.diff