Version: (using KDE 4.2.2) OS: Linux Installed from: Fedora RPMs When using the plastik window decoration, for very small windows some parts of the decoration are simply not painted. The window in the screenshot has been minimized and restored.
Created attachment 33693 [details] screenshot illustrating the artifact
still happens on KDE-4.2.90
still here, now in 4.4.1 Overall 4.4 feels a lot more buggy, than 4.3 was :/
mmm. isn't the statement "Overall 4.4 feels a lot more buggy, than 4.3 was" somewhat disconnected with this bug report, since your comment #2 explicitly state that the same issue was there for kde 4.2.90 (and I assume kde4.3) ? Feel free to post as many reports as there are new buggy things in kde4.4 ... As for the bug itself, can you - reproduce with other deco ? - reproduce with/without compositing ? (here I cannot reproduce with compositing on. I do have some artifacts with compositing off, but not the kind of artifacts you show in the screenshots, and finally, cannot reproduce with e.g. oxygen.)
the bug is there. it's the closebutton. it occasionally paints pixmap garbage (what can end up being transparent) and the reason is: QLinearGradient outlineGradient(0, 0, 0, r.height()); ... QLinearGradient surfaceGradient(0, 0, 0, r.height()); what got broken since the indirect deco painting (misses an XPutImage, i don't know why) when there're more buttons, the image is being put with the second and implicitly "fixes" the close button (if the area has a pending repaint, pending like on the server, not the deco painting redirection) the only solution i know is to ensure the gradient is cached in a pixmap and 2 painting passes one the one that triggers the caching.
still in 4.4.80
still in 4.5.2 + qt-4.7
Plastik has been re-implemented in 4.10 on top of Aurorae. Because of that I expect this bug to be fixed, if not it's not a bug in Plastik but a general one in Aurorae.