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:
parent
85777aaac2
commit
79f4168fd6
1 changed files with 6 additions and 3 deletions
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue