A small aesthetic nitpick: I use the Slide desktop switching effect. When I put an app (Konsoler, Okular, ...) in full screen mode and switch to/from the desktop containing the application, the panel is still visible for the duration of the effect. Not until the effect has completed is the panel hidden underneath the full screen application again. I'm not sure this is something that can be helped in KWin, so forgive me if it's not and I'll file a bug against the correct product. Reproducible: Always Steps to Reproduce: 1. Enable the Slide desktop switching effect under System Settings -> Desktop Effect -> General. 2. Start an application in fullscreen mode (Okular, Konsole, ...). 3. Switch to or from the desktop with the full screen application. Actual Results: For the duration of the effect, I can see the panel on top of the full screen application. Expected Results: The panel should be hidden even for the duration of the effect. Another thing I noticed is that bringing out KRunner with Alt+F2 also brings out the panel on top of the full screen app, which I think is wrong. But I guess that has nothing to do with KWin?
Given the age of the duplicate bug, there's probably not much one can do about it. *** This bug has been marked as a duplicate of bug 171454 ***
Actually this one's a bit different. The root cause is that the fullscreen window is only on the fullscreen layer as long as it has the focus. The moment KRunner is invoked, it looses the "active fullscreen" condition (and drops from that layer) -> That's actually not a bug. For the animated desktop changes, it's in some sort of flowing state. With changing the desktop the fullscreen window either gains or looses focus - this is (probably) only notable if you've a(n active) fullscreen window on both VDs, so that the panel briefly appears during the animation (because at the point of switching, *no* window is active, thus not on the FS layer either) Since we cannot make two windows active at the same time, the effect would have to predict the "was" and "will be" active windows and (in case they're fullscreen) elevate them.
Hi, Sorry for the dupe, I did search but must have missed it. @Thomas: Regarding the KRunner issue: Thanks for explaining the mechanics, I now understand why it happens and that it's not a bug in a technical sense. I still consider it a bug from a behavioral point of view though: Why should the panel appear when I'm only requesting KRunner? As for the problem I reported here: I can see it happening even with a single full screen application on one desktop -- as the desktop transitions into view I can see the panel on top of the application. When the animation is finished (desktop fully in view) the panel disappears. This happens on both transition to and from the desktop with the full screen application. Again, I'm not going to comment on the technical side of things. I think I understand the problems of getting this fixed, especially in the case of switching from one desktop + full screen app to another desktop + full screen app. But I still maintain that from an aesthetic/usability point of view, it's a bug. But the original bug report probably suffices so lets leave this one RESOLVED + DUPLICATE?
I should clarify: When I say it happens on both transition to and from the desktop containing the full screen application, what I mean is that: * On transition _to_ the desktop with the full screen application: The panel is visible until the desktop is fully in view (full screen app gains focus). * On transition _from_ the desktop: The panel abruptly appears when animation starts, and remains visible for the duration of the animation, until the desktop is completely out of view (full screen app loses focus).
(In reply to Elvis Stansvik from comment #3) > I still consider it a bug from a behavioral point of view though: Why should > the panel appear when I'm only requesting KRunner? NETWM spec. ------------------------ Stacking order To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom: - windows of type _NET_WM_TYPE_DESKTOP - windows having state _NET_WM_STATE_BELOW - windows not belonging in any other layer - windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and - - - windows having state _NET_WM_STATE_ABOVE - focused windows having state _NET_WM_STATE_FULLSCREEN ------------------------ As you can see, it's recommended to only have active FS windows above panels (and there's been a bug report when this didn't really work ;-) The idea is that when withdrawing the focus from the fullscreen window, you "break" the special fullscreen condition and return to normal desktop interaction. Deviating from this implies several issues: ---------------------- a) active windows (your krunner) would have to go on top of the stack, even above docks and (notably) keepabove windows b) autohiding panels: even w/ the above, a panel does not get "active", so it would never raise above the FS window, even if explicitly triggered c) random multiscreen issues (when on screen has a FS window and the other a normal desktop - this is however mostly due to the NETWM's unawareness of multiscreen setups) d) probably more i currently don't think of ;-) If we'd change this in general, we'd get bugreports for sure. If krunner was dock typed, we could probably reasonably treat it differently, but apparently it changes the window type with every release :-( (@Martin: krunner seems to be a normal window again, so prepare for bug #299655 to cook up once more in the near future)
@Thomas: Thanks for digging this out. I think understand the problems involved, and the relation to the condition in the NETWM spec, that it pertains to " _focused_ windows having state _NET_WM_STATE_FULLSCREEN". I know developers love general solutions. However, with this bug report I was merely pointing out that in this specific scenario, it looks strange/glitchy when it happens, not that there should be general changes to how stacking order is handled. Perhaps there's some compromise solution that could be made while still sticking to the spec? Can't think of one straight away though... Again, thanks for the input and explanations.