| davidedmundson | |
| graesslin |
| Plasma |
update m_visibleRectBeforeGeometryUpdate when the padding
change signal gets emitted: aurorae updates its shadow
and postentially shadow size asynchronously after repainting.
that would make the first addRepaintDuringGeometryUpdates
when the winow is moved *for the first time* have a wrong
m_visibleRectBeforeGeometryUpdate that doesn't take into
account the shadow, leaving some leftover shadow on screen
BUG:377670
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
| abstract_client.cpp | ||
|---|---|---|
| 88–90 | why are you putting that into a lambda? | |
| abstract_client.cpp | ||
|---|---|---|
| 88–90 | it's not a slot | |
I'm not sure whether this is the right solution. This yells side-effect and potential breakage in other areas to me.
Also I don't like the idea of having decoration specific workarounds in the core.
| abstract_client.cpp | ||
|---|---|---|
| 88–90 | so what? you can connect to any method | |
So if I understand correctly on the paddingChanged we do not need to repaint, you are only interested in the update of the m_visibleRectBeforeGeometryUpdate? In that case I suggest to update it whenever the shadow changes.
yes.
so just update that property in a lambda without the actual call to addRepaintDuringGeometryUpdates? (and addLayerRepaint)
well, this shows that m_visibleRectBeforeGeometryUpdate can become wrong if the window sets a shadow on itself without actually resizing the window geometry (it becomes evident in aurorae because it renders asyncronously and the shadow can be set only after the rendering is actually done)
so i think guarding against it should be a good thing, regardless of aurorae
would be better in my opinion. That would make it more clear what happens and is also more correct. After all the idea of the variable is to include the geometry including the shadow and it doesn't get updated when the shadow changes.