With Plasma 5 a change regarding auto-hiding panels was introduced. The complete interaction was moved from Plasma to KWin. This was an idea which we had in mind for a long time. The main idea is to have only one process to reserve the interaction with the screen edges (which is needed to show the panel when hidden) and to prevent conflicts there. Also it allowed to have only one place for providing the hint that there is the panel.
On an implementation level that uses an x11-property protocol between KWin and Plasma to indicate when the panel should be hidden. KWin then does the interaction to hide it and to show on screen edge activation.
Unfortunately from a visual perspective this created a regression. In Plasma 4 the auto-hiding panel was animated with our Sliding-Popups effect, but in Plasma 5 this doesn’t work any more. The reason for that is that our effect system can only animate when a window gets mapped and unmapped. With the new protocol the window doesn’t get unmapped when hidden and not mapped when shown, so our effects are not able to react on it. Technically our Client object is kept instead of being released on unmapped.
Thanks to Wayland this will be working again starting with Plasma 5.8. For Wayland windows KWin keeps the object around when a window gets unmapped and uses the same object when it gets shown again. KWin keeps more state for Wayland windows than for X11 windows. But this also means that our animations are not working for Wayland windows. Last week I addressed this and extended the internal effects API to also support hiding/showing again of Wayland windows. As the effects API does not differentiate between Wayland and X11 windows this change also enables the auto-hiding panel animation. All that was needed was emitting two signals at the right place.
Here Wayland shows another strength: not only does it help to bring features to X11 it also allows us to automate the testing. With a pure X11 system we would have had a hard time to properly auto-test this. But for Wayland we have a nice isolated integration test-framework which allowed to add a test-case for auto-hiding panels.
sorry for the off-topic comment but I seem to understand there is better screen edge support in Plasma 5? If so, would it become possible again to configure a screen corner to disable screen saver?
thanks
The screen edge infrastructure works by triggering an action when the mouse cursor touches the edge. To disable the lock screen would require something completely different. The action should be performed until the mouse leaves it. That is something very different and cannot be supported with the existing infrastructure. I don’t see a chance for a large change in the infrastructure to support this very rare use case. (We had it broken for several years without a user reporting it).
thanks for explaining.
I believe the use case is not rare as a lot of users watch youtube using a web browser and don’t want the screen saver to turn on/screen to lock in the meanwhile. I myself have been completely disabling screen locking or any screen saving for years now but in all other cases (=not watching videos) this behavior is unwanted. I guess most users do the same.
There are inhibition APIs and browsers should use them
Btw, that pops up an interesting question: shouldn’t a compositor themselves detect fullscreen windows? If I understand it right, for fullscreen windows, compositor have disabled some passes, thus increasing performance and demanding less energy. So it would be a nice performance trick, because the real world is always like this: a user tends to do something wrong or/and silly. The screensaver fix would be just a nice side effect.
The detection to me seems to be quite simple: every time a window being resized, check if its width and height match the screen ones, and (un)set fullscreen mark.
Make sure that screensaver disabled for fullscreen windows, and that you’re watching youtube in HTML5. There’s a long standing bug in Adobe Flash Player that it never notifies WM that it ran into full-screen, and Adobe devs probably buried the app long time before the rest of the world did :?. HTML5 player doesn’t have that problem.
I was wondering… You speak more and more to merge things that were in Plasma in Kwin. It would mean that Kwin is slowly more than a windows manager and that another windows manager would not be able to load Plasma correctly in the future, that Kwin and Plasma are tightly working together.
But is it an issue? Just out of curiosity…
No not really as we do everything through protocols. Any wm interested could implement them