When a window's geometry is changed, geometryChange in Js scripts may be called with wrong "intermediate" value. With intermediate value, I mean some value that is between old and new geometry, but neither one of it. Example: geometry change from (5,10 100x200) -> (15,20 300x400) creates 2 geometryChange calls, instead of just one: old geom new geom (5,10, 100x200) -> (14,19, 100x200) (14,19 100x200) -> (15,20 300x400) I have tested it with morphingpopups effect, where this bug breaks the animation and popups jumps from/to wrong position (plasma-framework ToolTip is also partly to blame, but fixing it is not enough). This also happens with normal tooltips from QtWidgets apps, and I think is easier to test there than with Plasma tooltips (happen only sometimes). Reproducible: Always Steps to Reproduce: 1. Open system settings -> open some category (eg. Desktop Behavior) 2. Hover help button in top toolbar (near the All settings button, so it gets animated) 3. Mouse over the All settings button to trigger animation It may not work for you, as it probably depends on exact size of the tooltips. So if this doesn't trigger the bug, hopefully you'll find different widgets that does trigger it. Actual Results: two geometryChange calls Expected Results: single geometryChange call
I'd say the window simply moves first, then resizes (and somehow adjusts its position) - we receive two configure events and forward them to scripting (since the config events should be the only occasion to emit geometryShapeChanged for unmanaged windows) Since those are unmanaged windows (at least regular tooltips are), KWin does not cause the geometry change. => smoothing this has to happen in client code (effect script) - we cannot just stash random signals on a global scope (though ideally clients would just configure themselves once), resp. try to compress them. However, why would this fail on the morphing effect? Afaiu it should animate the big transition and then (in doubt retarget) the big resize, yesno? PS, stupid question: by "tooltips from QtWidgets apps" you're not referring to the completely broken tooltips in dolphin which usually are far too tiny on mapping and then most of the time "forget" to adjust their size?
(In reply to Thomas Lübking from comment #1) > I'd say the window simply moves first, then resizes (and somehow adjusts its > position) - we receive two configure events and forward them to scripting > (since the config events should be the only occasion to emit > geometryShapeChanged for unmanaged windows) > > Since those are unmanaged windows (at least regular tooltips are), KWin does > not cause the geometry change. > Ok, I'll see when and why is the geometryShapeChanged emitted. This signal is also emitted when no geometry actually changes (window.geometry == oldGeometry). > => smoothing this has to happen in client code (effect script) - we cannot > just stash random signals on a global scope (though ideally clients would > just configure themselves once), resp. try to compress them. > Indeed, I thought that the geometry change came from KWin, as the Plasma tooltip QWindow emits only one geometry change event (but yeah, that doesn't mean it does exactly the same thing in xcb code). > > However, why would this fail on the morphing effect? > Afaiu it should animate the big transition and then (in doubt retarget) the > big resize, yesno? > Because it ignores animation when there is a too big/small difference in position/size of tooltips to be animated, so it usually just picks one of the two geometry changes. > PS, stupid question: by "tooltips from QtWidgets apps" you're not referring > to the completely broken tooltips in dolphin which usually are far too tiny > on mapping and then most of the time "forget" to adjust their size? I mean normal tooltips with just text in it, nothing fancy. I experience the described behavior sometimes with Plasma QML tooltips, but certainly not with QtWidgets tooltips.
It's emitted from configureNotifyEvent and windowEvent, so nothing wrong in KWin. Sorry for the noise.