Visual glitches in ProcessWidget

[Matthew Woehlke]

Matthew Woehlke wrote:
> ProcessWidget is tinkering with its palette, causing two undesirable 
> effects:
> 
> 1. The colors it chooses are commonly indistinguishable from the window 
> background (i.e. in any scheme where background() == mid(), e.g. 
> '[Digital] CDE', 'Dark Blue', 'Solaris', 'High Contrast Black')
> 
> 2. Styles that draw using the highlight color draw incorrectly.
> 
> ...not to mention that hard-coding of colors as done by several parts 
> (grepview, to name one) is A Bad Thing; these need to be configurable 
> somehow (for a REALLY nasty example, consider the effect of using 'High 
> Contrast Blue'). Is this being done in KDevelop4? (I wonder if this sort 
> of thing should be system-wide - and more importantly, scheme specific - 
> ala <https://bugs.kde.org/show_bug.cgi?id=136719>...) KATE gets away 
> with its application scheme system because you are never combining a 
> system scheme color with a KATE scheme color. The alternative of course 
> would be for ProcessWidget to do likewise; draw the list itself (NOT THE 
> SCROLLBARS!) and use an application scheme background color rather than 
> the system scheme color.
> 
> Is the palette changing really needed, or can it be removed?

No, it isn't... that's what QListBoxItem::setCustomHighlighting is for. 
I'm having problems with getting the width right (QListBoxItem::width 
gives text width, not control width - I just don't have time to dig 
until tomorrow), but once I can fix that, I'll have a patch that draws 
ProcessListBoxItem and GrepListBoxItem using strictly palette colors (I 
use QColorGroup::link and QColorGroup::linkVisited, and blending of 
colors to get more *safe* colors than just QColorGroup::text).

-- 
Matthew
"Lost a planet, Obi Wan has? How embarrassing..."
  -- Yoda (Star Wars II: Attack of the Clones)