Version: (using KDE KDE 3.3.92) Installed from: Unlisted Binary Package Composite extension: enabled Translucency & Shadows: enabled Opacity for Active windows = 100% (A%) Opacity for Inactive windows = 50% (I%) Howto: 1. Switch to Desktop 1. Start KWrite (fullscreen). Write something. 2. Switch to Desktop 2. Start KWrite (fullscreen). Write something. 3. Switch to Desktop 3. Start KCalc. Don't touch it. 4. Switch to Desktop 2. KWrite should be A% opaque (correct) 5. Switch to Desktop 1. This KWrite is I% opaque, even if it has focus (you can type anything in it) - don't touch it though in this test (bug!!!) 6. Switch to Desktop 3. KCalc is now I% opaque... hmm.. the bug!!! again 7. Switch to Desktop 2. This KWrite is A% opaque.. as it should 8. Switch to Desktop 3. KCalc is as still I% opaque. Move it to become A% opaque. 9. Switch to Desktop 1. The KWrite which was I% opaque shows up all right now. Reproductability: always Annoying: yes, when you use fullscreen apps on different desktops on a regular base I believe it has something to do with how the application grabs focus. KCalc does not explicitly grab focus (focus on a window component), I THINK (not sure though). Note that when you do the above test, you should not switch back and forth between the browser window and the testing desktops. 10x
can't reproduce. does it only work with kwrite/kcalc or can it be anything else? how do you start those apps (kicker starter, alt+f2, startmenu?)?
I always have a Firefox Window opened on one desktop and Kontact on another. This is the situation I have. I gave the example above because: 1. I have an extra kicker bar with a KWrite shortcut in it. 2. I have KCalc binded to a KBD key (multimedia keyboard).\ 3. I switch desktops by clicking on the panel (I haven't tested the exact desktop numbers as above, but I guess this is irelevant) These allowed me to test without adding extra interference (just moving the mouse). Some extra focusing settings which might be relevant: Policy: click to focus Click raise active window: checked Also, that fullscreen setting for KWrite might have something to do, but I'm not sure.
A lot shorter example: 1. start Konsole on Desktop 1 2, start Konsole on Desktop 2 3. switch to Desktop 1, Konsole is focused (you can type in it && the color of the titlebar corresponds to an active window), but opacity is set as if it was inactive. 4. switch to desktop 2 -> the 2nd Konsole still looks ok. 5. switch to desktop 1 (the konsole with incorrect opacity) & move the window (it will gain the correct opacity) 6. switch to desktop 2 -> now.. the 2nd Konsole lost it's active window opacity... The Konsoles are alone on their desktops. Strange behaviour happens also with 3 different Konsoles, each one on a different desktop. #1, #2, #3 opened in this order. I = inactive opacity, window is focused A = active opacity. Checking the opacity level in reversed order, from 3 to 1.. from 3 to 1.. and so on... would result in the following unbelievable behaviour: 3 2 1 < desktop number A I A I A I A I A I A I ... I can definitely see a pattern there. Note that Konsoles were started from a kicker app shortcut. Desktops were switched with the mouse, using the desktop previer and pager (haven't noticed this elaborate name until now). No interaction takes place with the Konsole windows (no kbd, no window moving.. no nothing), just opening them & switching desktops.
The strange this is that I can enter text/scroll in Firefox/Kontact (no matter which one happens to be shown with incorrect opacity level) without Kwin even bothering to change the opacity level.
... only moving the window fixes the Opacity Level. (sorry for so manny posts here) (& 10x for fixing http://bugs.kde.org/show_bug.cgi?id=99800)
Related to: http://bugs.kde.org/show_bug.cgi?id=99841#c2
KDE4 will include compositing support in KWin instead of Kompmgr and I don't expect this problem to be fixed for KDE3 by now, sorry. Closing.