Version: (using KDE 4.0.3) Installed from: SuSE RPMs OS: Linux I have been using openSUSE Build Service compiled KDE 4.0.3 for sometime now. I face this problem regularly when working with YAST and openoffice. The panel, and indeed the entire desktop including widgets flicker (turn black or invisible intermittently) as long as the particular applications (in my case Yast and openoffice) keeps running. As soon as these applications are closed the panel and the desktop return to their normal self after being allowed to redraw (eg: by moving mouse over the panel, by resizing or moving widgets). The behaviour is independent of number of widgets loaded or what the widgets are, and happens with the default plasma-theme as well as with aya and slim-glow (problem seems to be theme independent), and I have not tried any other plasma-theme. This problem does not occur with gnome (or other gtk) applications. Thus firefox, banshee, etc all run without reproducing this bug.
Created attachment 24539 [details] Picture explaining flicker of panel At the bottom of the snapshot is the panel with the problem occurring with open-office running.
not a plasma bug. upstream: x.org, x.org driver, etc. wish we could do more about this, but beyond letting upstream know about these kinds of problems, there isn't much more i can do.
This problem has existed for me from the beginning (4.0 betas) through kde-nightly builds, specifically when running wine apps. That is a long time. Even if it's not a plasma bug, it's still a huge KDE problem, in my opinion, unless it is confined to us 'unlucky' 7600GT owners, which very well might be the case.
> it's still a huge KDE problem that's like saying a bug in the linux kernel is a KDE problem. or a bug in samba is a KDE problem. or a problem on slashdot.org is a KDE problem. you may use all of them with KDE, but it's out of our hands to fix other than to report upstream.
see also bug #157017
Is there an upstream bug report for this? i have been searching, but have not yet found one.
I'm seeing this regularly on a KDE machine that is currently running a NoMachine client window to another remote computer. > that's like saying a bug in the linux kernel is a KDE problem. or a bug in samba is a KDE problem. or a problem on slashdot.org is a KDE problem. Not entirely. While I agree that KDE cannot "fix" this if it is indeed an xorg problem (short of going the extra mile and submitting a patch, but even then it's up to xorg to accept the patch), saying there's nothing KDE can do about it isn't true. When working with 3rd party libraries, one always has the option (and often the duty) to work around flaws in external libraries, especially when there's little expectation of the 3rd party fixing the problem. I'm not intimately familiar with how the interaction between the KDE and xorg causes this flickering to occur, but there's no indication in this bug that any level of effort has been put into exploring possible ways to work around this and/or whether working around it is better than waiting for xorg to fix (or just not fixing at all). I'm not saying nobody at KDE has done anything about this (just what I see in this bug), but if some investigation into possible ways to work around this has been done, please leave comments. If no such investigation has taken place, then it reflects poorly on the determination to make KDE 4 a well polished desktop environment. It's often little issues like these that drive away users. All this aside, this is just a cosmetic issue and doesn't seem to affect functionality. Either way, I'm still a happy KDE user. :)