Same here, especially Konqueror and amaroK are affected for me. Just the same setup as Chris: Gentoo and nVidia card - it doesn't matter which version of the proprietary drivers I use, I tested releases of 6xxx, 7xxx and 8xxx. At the moment I'm on Xorg 6.9 rc2, but it was just the same with 6.8

I forgot to mention it before: When the window has become transparent, moving it causes it to take the proper opacity for moving windows, but it just gets "inactive" again after the move.

Anyway I have to admit that, in fact, closer observation reveals that the opacity values of both amaroK and Konqueror keep sinking percent by percent as I check them again and again. Inactive windows for me are set to 50%, and that's what the opacity was at the beginning, but now it has dropped to 40% and stopped there. Maybe this is a different bug, but it only occurs with windows that are affected by our main bug here. I don't use the value 40 for any settings, so it must be direct consequence of the bug.

Another interesting observation: As I have an affected Konqueror window open here, I can open dozens of Konqueror instances: None of them is affected. This is with "Minimize Memory Usage" turned to "Always", if it matters at all.

I've "Minimize Memory Usage" turned to "For File browsing only" as recommended - so that's of no importance I think.

I found something else.
in Control Center/KDE Components/KDE Performance, I had set "Maximum number of instances kept preloaded" to 1 (I think that's the default).

Now I set this to 0, restarted KDE, and the Konqueror transparency problem is gone. Funny. Because the Amarok problem is still there.
So maybe that could be a hint to narrow down the problem.

I can confirm this :) It doesn't even need a restart of anything but Konqueror itself.

is amarok restored (i.e. started automatically with KDE)

Yes, but makes no difference. Kgpg, Kmixer, Kopete... as well, they make no problems.

But know what's funny?
Try the following steps:
1. shut all konqueror windows and amarok.
2. tell control center to preload no konqueror, klick apply, no kde restart.
3. start konqueror, drag it. no problem.
4. start amarok, drag it. no problem.

but now:
5. shut all konquerors and amarok.
6. tell contol center to preload 1 konqueror, klick apply, no kde restart.
7. start konqueror, drag it: error as described.
8. start amarok, drag it: same in green.

so you can switch the bug on and off with the preloaded konquerors?
As Frank said: its only the FIRST konqueror started that is affected.

AND: if you tell control center to preload *2* instances of konqueror, and "always try to have at least one preloaded instance", the TWO FIRST konquerors started are affected.

So it definitely has to do with the konqueror preloads.
Does amarok maybe use parts of the preloaded konqueror??

amaroK is affected for me even if Konqueror is not preloaded, but look at this:
1. start amaroK, move it around as you like: not affected.
2. minimize to tray and restore again.
3. moving the window triggers the bug now.

Ha! That way KGpg, aKregator and probably some other similar applications are affected as well. Curiously, KMail isn't... It must handle minimizing to tray differently.

BTW, I just noticed nobody has mentioned it yet: This bug is all but new... I think it was already around when kompmgr was introduced in official KDE. (3.4.0?) So don't just concentrate on changes made since the last release :)

You're right, I can confirm #8 and #9 (Kgpg...)
And I was wrong with the preloads. I still have the problem with preload instances = 0...

Christian: Are you really sure you had the bug with Konsole and KMail? I just can't remember it happening to me and especially Konsole doesn't fit into the picture (not having a tray icon) :/

Thomas: Is there anything else we can do to help you get this bug fixed?

I can't reproduce it with konsole and kmail, so let's put that in the "I remembered wrong"-drawer.


1. I can reproduce it with:
KMix, KWalletManager,  KGet, KGpg, Amarok, Kscd, Kopete, and even with Skype.
And, of course, with konqueror, if preloaded.

2. Another small hint: start any of these programs - they firstly jump into the system tray.Klick on the system tray icon. Window approaches, move it: NO BUG! Then close the Window (with the "X") -> Window vanishes into kicker again. Klick icon again, and move the Window: NOW the bug is there.
So maybe it doesn't have anything to do with programs that can be minimized to the kicker, but with the attributes the windows get if they are "started", I mean activated by the system tray icon.

3. the bug can also be triggered by resizing that window, not only my moving it.

Created attachment 13976 [details]
screenshot of active false translucent window

And something else. (maybe related, but maybe a different bug?):

1. settings in Control Center/.../Translucency/Opacity:
[ ] active windows    (100%)
[X] inactive windows  40%
[ ] moving windows    (56%)

2. start any (? I tried konqeror, konsole, kate)
3. klick many times on the representing bar at the kicker window list, so that the window gets minimized, back to normal, minimized, back to normal.
I did it approx. 10x, and in 3-4 cases the window is translucent  when ACTIVE. I can move it, it stays translucent.
the "[ ] active windows" checkbox doesn't change anything there.
Minimize it and click again on the bottom bar - it's opaque, back to normal.
Strange behaviour...
look at the screenshot, taken from an unnormal transparent window: the window property shows 100%, but the window IS translucent!

Can anyone confirm that?

Not me, that works here just how it is supposed to.

I think it's a different bug... and, as I found out, dependent on the effect "fade-in windows (inclusive popups)" - with this option on I have the problem, without, I haven't.
Seems like the translucency sticks in a half-shaded state when fading in...
But let's forget it for now.

I think Bug #102391 is a duplicate of this one here. Can anyone change that?

is this fixed in version 3.5.1?

No, unfortunately it's not.

I confirm Comment #2; here's a test case which produces a bug every time on my KDE 3.5.1:
1. Have "Use translucency/shadows" turned on and working;
2. Open some application's window;
3. Set the window's opacity to something other than 100% (Either by right-clicking on title bar or by setting proper options in "Window Behavior -> Translucency"
4. Now, every time you right-click on the window's titlebar will decrease that window's opacity by 1, until it reaches value divisible by 20.

By "right-clicking" I actually mean opening the "Operations Menu" as set in "Window Behavior -> Titlebar Actions".
Ither settings form Translucency tab (inactive opacity, shadows, fade-in, etc.) don't affect the bug. Also, it doesn't matter if the window is focused or not, as long as it is non-100% opaque during right-clicking.

can anyone say if this is fixed in 3.5-2?

Doesn't seem to be fixed from where I'm standing :(

damn!  guess we'll have to wait till kde 4.

or KDE 5...   ;-)

Back to the issue of the decreasing opacity (Frank Roscher told us)

my settings: only window borders are transparent, active & dragging 70%, inactive 50% translucent. No fading.

Take ANY window (e.g. konsole, not only the affected we said as before).
Right-click on the title bar, or open the window menu with the icon. Move the Mouse above "opacity" and look at the given value, e.g. 70%.
Repeat that step, or just click a few times on the title bar with the right mouse button.

With each click the opacity decreases by 1!


Can we do anything to help?

consider kompmgr to have been a toy.
i guess the future will have to be upon xgl/egl (just to include ATI, opengl has some furthor advances as long as X seems to be not extended and especially if egl should manage to move the whole pixmap processing chain into the vram - xgl really sucks on this)

the current way was also never meant to be the composite use for KDE4 (but kcompmgr was?!) and taking a look at compiz, the xgl development process and gnome, i guess there won't be a modular system where you can stick composite managers and window managers and other composite using apps (e.g. komposé) together, but we'll have a plugin featured windowmanager (just like compiz) - at best with a compatible plugin interface (but that's upon lubos)
as xrender1.3 (from xorg cvs, maybe 7.x) doesn't work with the renderaccel here and the future of this whole stuff is by far limited, i very much lost interest in putting effort into the kompmgr+kwin solution. so either s.e. will have to do if wanted or this will never be fixed (so, sorry... :-(  )

for the moment, me plans to sit back on this topic, wait and see and start work again as soon as i can see where we're going (i guess/hope for egl as probably opengl will especially now have much more support by the GPU vendors, so i'm working on my openGL knowledge :) and then help on kwin4/plasma - if anyone want's me to ;)

Now that sounds better... ;-)
I didn't know that - but if compmgr isn't the system which KDE4 bases on, then forget about the improvements.

Thanks for the answer.
So maybe mark the bug as WONTFIX, just for the sake of completeness ;-)  ?

Chris

I agree with Comment #27.

*** Bug 119382 has been marked as a duplicate of this bug. ***

*** Bug 123306 has been marked as a duplicate of this bug. ***