When using Yakuake 2.9.8 with KDE 2.6.5, there is a strange visual problem when opening Yakuake using my hotkey. I personally use my KDE panel at the top of my screen. When Yakuake is opened it blocks the view of the KDE panel as it comes down. This visual nuisance only happens when KDE desktop effects are enabled. Once Yakuake has completed the drop-down process, it properly snaps underneath the KDE panel as it should. When disabling KDE desktop effects, the Yakuake terminal begins the drop-down process from the bottom of the panel, therefore not exhibiting the odd behavior. This is what I expect Yakuake to do in all cases, regardless of the KDE desktop effects setting. I apologize for the high-level description for I do not know anything about KDE or Yakuake internals to begin to understand where the problem may be. Let me know if you need more information. Thank you for your time.
Thanks, that's one of the best-written bug reports I've had for a while. I appreciate that kind of effort. As a better workaround to disabling desktop effects, for now you can go into the Yakuake config dialog (see the menu hiding behind the middle of the three buttons in the lower-right corner of the default skin) and disable the "Ask the window manager to perform the animation" checkbox roughly in the middle of the first dialog page. I'll investigate, but I'm afraid there's a very good chance that this won't be fixable from within Yakuake, and not without a new version of KDE. It may in fact not get fixed at all if the kwin maintainers don't agree. To explain, if the conditions are such that Yakuake asks kwin (the KDE window manager) to perform the animation for it - KDE is new enough, kwin has the slide effect loaded, Yakuake is configured to request its use - to perform the animation on its behalf, kwin code runs that slides the window from the top edge into its final position - and thus above any panel between the top edge and that final position. The old animation strategy works dramatically different, by technically showing the window directly in its final position and then progressively adjusting its clip mask (while moving the title bar widget along the lower edge of the clip mask to fake the illusion of movement), and thus doesn't suffer from this problem. One fix I can think of would be to try and force the window to be below the panel window for the duration of the animation, so the slide occurs over and not under the panel - however I'm not certain the slide effect supports z-ordering, and it might also be tricky from a timing POV (since Yakuake technically doesn't actually know its window is sliding around, so the only thing to do would be to change the window hints after the same amount of miliseconds it tells the slide effect to use for the animation duration, and hope there's no other latencies in the system). The other fix, much more involved and requiring changes to kwin, would be for the slide effect to expose an API that allows Yakuake to set a clip edge or an origin coordinate from which to slide in rather than just telling it to use the top edge. I've CC'd kwin maintainer Martin Gräßlin for his input.
From KWin side I consider the behavior to be absolutely correct and I don't think it is worth the effort to add a hack to support the desired behavior especially given that the default Plasma setup does not feature a top panel and there is an acceptable workaround to receive the desired behavior.
I would like to thank you both on your input and quick turnaround on your responses. I agree that the workaround is acceptable and I am completely satisfied with the result. Perhaps it is just enough to have this documented somewhere if it does not already exist. That said, I consider this case closed from my point of view. Thank you for hard work and the quality software. I find Yakuake and KDE very useful on a daily basis.
Thanks Martin, Brian. I'll keep this open for now as I've yet to try playing with forcing the window below the panel while it's animating.
I cannot reproduce this in: Yakuake 3.0.2 KDE Frameworks 5.30.0 Qt 5.8.0 (built against 5.7.1) The xcb windowing system Is this still valid?
This was fixed a while ago, thankfully.