Pixel-bug - KComboBox / KlineEdit / Oxygen style ?

[Thomas Lübking]

Am Friday 12 December 2008 schrieb 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.)
qt::QFocusFrame? (in this case)

in the meantime you could simply check on lineedit painting, whether the 
widget (iff) has no outline (looks like you ignore this option hint in 
PE_FrameLineEdit) and is parented by a combo- or spinbox and in case drop 
painting.
in doubt, you could use the lineedit's palette to paint the combo/spinbox

but in general, yes. i would be cool to /alphachannel/ the widget's content 
(you can set a bitmask...) painting, but /NOT/ the style one (so you can drop 
nasty hacks with overlay widgets)

> paint the inside at all. In especially bad cases, a widget
> *inconsistently* overpaints the extra pixels, and you get glitches like
nope, in this case it's usually actually the style, painting the glitch
(PE_PanelLineEdit, LineEdit::Panel in kstyle case) afair, the lineedit on 
combos etc. is by def. /not/ autofilled (as lineedits are usually never)


Thomas