Pixel-bug - KComboBox / KlineEdit / Oxygen style ?

[Matthew Woehlke]

Rafael Fernández López wrote:
> Something I have been always looking at when using KDE apps but that never 
> tried to fix because I have no idea where the bug can be is the next 
> screenshot:
> 
> http://media.ereslibre.es/2008/12/pixel-bug.png
> 
> You can appreciate the same problem on all KDE combo boxes. I wonder who's 
> doing something wrong here.
> 
> Ideas ?

Yes. Ask TT (again) to let us paint widgets in the following manner:

- Style (optionally) does painting
- Widget does painting
- Style (optionally) does painting
- Style (optionally) supplies a mask; the results of the above are 
blended with the mask, and the result of that is finally drawn onto the 
parent. (The default mask is just a 100% opaque rectangle of the 
widget's size.)

If we had this, we could do proper view painting. (And styles could 
correctly define widgets with rounded corners.)

As it is, we have to take control of a few edge pixels (meaning we 
impose a background color on the edge of views). Views that try to paint 
the background their own way will clash. Worse, views with a non-default 
background color (autoFillBackground, which is sometimes needed) will 
spill out the edges of our rounded views. We then paint glows a few 
extra pixels into the area we allow the widget to "own", since to do 
otherwise would make the margins unacceptably large. Then we hope views 
either consistently overpaint those (which still looks ugly), or don't 
paint the inside at all. In especially bad cases, a widget 
*inconsistently* overpaints the extra pixels, and you get glitches like 
this.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft, electricity, network connectivity. For a secure system pick 
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)