PATCH: don't tinker with the palette or use hard-coded colors in grepview part (was: Visual glitches in ProcessWidget)

[Matthew Woehlke]

Matthew Woehlke wrote:
> 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).

Since I haven't heard anything else, I'm posting a patch to fix these 
issues. It leverages link colors and some color blending to continue to 
have the same set of distinct colors without the need to use hard-coded, 
out-of-scheme colors. It also drops the palette tinkering and instead 
uses custom drawing to alter the selection background color. Can this 
just be applied or should I open a few bugs for tracking purposes as well?

Note that any subclasses of ProcessListBoxItem need to be updated to do 
the same drawing, or the 'selected' drawing will be lost. Optimally this 
should probably be fixed by providing a paintBackground() method in 
ProcessListBoxItem that shall ("shall" = prescriptive) be called by 
paint() in derived classes. This is a trivial change; I can make 
additional patches if someone wants to point out classes that are affected?

-- 
Matthew
"Braaaaaaaaiins!" -- Zombies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdev-no-hard-colors.patch
Type: text/x-patch
Size: 4966 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20061204/7cb23907/attachment.patch>