It calls move(calculateGravitation(true)); move(calculateGravitation(false)); what does nothing. What it *should* do is to perform "calculateGravitation(true)" with the *old* borders and calculateGravitation(false) with the *new* borders (alternatively calculate and move by the diff, but that's a micro-optimizing detail) => This requires either an API change do Decoration (to eg. pass the old borders with the signal) or to cache the borders in the core (and update them on borders changed) Reproducible: Always
passing old borders with the signal would be kind of strange. What could be done if we want to go from kdecoration API is to emit a signal aboutToChangeBorders, which allows interested parties to cache the values. Not sure whether this would help in this case.
sending old/new on changed is actually not /that/ uncommon, see eg. notably itemviews (on col/row/section changes) Using two signals would defy the geometry update blocker (thus cause judder/flicker) - about to change could only be used to cache the present values -> dead end (it would be really stupid to update a cache to the old value right before the change is signalled and grab through current values all the time) So, while pot. interesting in general, I don't think that would be helpful here - no.
Thomas can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
I stopped using KDE ~5 years ago and also haven't really looked at the kwin code ever since then (this wasn't a user bug, I was heavily involved in kwin development) I would suggest to check whether those code fragments still exist.
Setting back to reported for investigation.
(In reply to Thomas Lübking from comment #4) > I stopped using KDE ~5 years ago and also haven't really looked at the kwin > code ever since then (this wasn't a user bug, I was heavily involved in kwin > development) > > I would suggest to check whether those code fragments still exist. We still have it. As for this bug, we could either pass the old borders as a signal arg or cache the last frame border extents in the bordersChanged() slot.
by cache, I mean connect(decoration, &Decoration::bordersChanged, this, [this] { move(calculateGravity(true, m_cachedBorders)); // undo move(calculateGravity(false, decoration()->borders()); // redo m_cachedBorders = decoration()->borders(); });