Compute correct visible rect for client-side decorated clients

Summary:
Frame and buffer geometry don't have strict order. Either one of them can
be inside the other one, so we must take that into account when computing
visible bounds of the client including drop-shadows. We also have to take
sub-surfaces into account when determining the visible rect, however it's
out of scope for this patch.

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Maniphest Tasks: T10867

Differential Revision: https://phabricator.kde.org/D24458
This commit is contained in:
Vlad Zahorodnii 2019-09-30 11:30:04 +03:00
parent 85777aaac2
commit 79f4168fd6

View file

@ -145,11 +145,14 @@ void Toplevel::disownDataPassedToDeleted()
QRect Toplevel::visibleRect() const
{
QRect r = decorationRect();
// There's no strict order between frame geometry and buffer geometry.
QRect rect = frameGeometry() | bufferGeometry();
if (shadow() && !shadow()->shadowRegion().isEmpty()) {
r |= shadow()->shadowRegion().boundingRect();
rect |= shadow()->shadowRegion().boundingRect().translated(pos());
}
return r.translated(frameGeometry().topLeft());
return rect;
}
Xcb::Property Toplevel::fetchWmClientLeader() const