Summary:
The checks in Client::adjustedClientArea were a little bit too
agressive, excluding also valid setups.
This change addresses the regression by keeping the actual intended
improvements in place.
The check in Client::adjustedClientArea is now only done for the
special case of desktopArea == area. This ensures that a strut excluding
a complete screen won't affect the overall workarea.
In addition new checks are introduced in Workspace::updateClientArea.
When calculating the new sareas a check is performed whether the
intersection with the adjustedClientArea would result in the sarea
becoming empty (thus a screen being completely removed). If that's the
case the geometry is ignored to not exclude a complete screen.
Interestingly I should have noticed that something with the logic is
odd. As the test case had two commented geometries which we now get.
BUG: 363804
Reviewers: #plasma, apol, lbeltrame
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1744
Summary:
The implementation was broken as it transformed the QRects into QRegions,
subtracted the geometries and took the bounding rect again. In several
setups this could result in the strut getting ignored.
This change improves the calculation of the struts by creating a QMargin
which describes the area which needs to be subtracted from a screen rect.
The QMargin is only adjusted for the edge the window borders. We can
assume that a window with a strut needs to border a screen on Wayland.
With this change we are also able to support panels between screens.
On Wayland a panel placed on the right of a left screen affects the
maximization area of the left screen, but does not affect the overall
workarea.
CCBUG: 167852
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1803
Summary:
Mostly meant for multi-screen setups: we don't want that a strut set on
a window on screen 0 results in screen 1 completely being excluded. Even
if that's strictly seen a client bug, it's better to just ignore the
strut from KWin's side.
The sanity check is implemented in Client::adjustedClientArea.
From a pure standard point of view this change is a EWMH violation and
thus can cause regressions: struts by clients no longer working.
A test case for struts is added, including some invalid combinations
whose strut is ignored with this change.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1386
If a decorated ShellClient is still around after Workspace got destroyed
this method is still invoked and can lead to a crash. As we have a
workspace initing test there already it makes sense to combine it with
a workspace being down check.
This includes the methods:
* decoration()
* decoration() const
* isDecorated() const
In addition new protected methods are added to destroy the Decoration
and to set it.
Usage of m_decoration in Client code is adjusted.
Sync related code is split out into dedicated virtual methods so that
Client can provide the X11 specific implementation. General handling,
though is completely in AbstractClient.
The implementation calls a virtual doStartMoveResize() which allows
Client to do it's X11 specific tasks (creating moveResizeWindow, grabbing
input).
The base implementation is no longer virtual.
Includes moving the m_cursor and Qt::CursorShape cursor() method to
AbstractClient. In addition AbstractClient now emits a signal whenever
the shape changes allowing Client to react on it (update the low level
cursor) and also hopefully the Wayland Backends to react to it, so that
we have the cursor.
Implementation goes to AbstractClient, method is no longer virtual.
The X11 specific code is moved to a new virtual protected doMove
method implemented in Client.
Method added so that we can call into TabGroup::updateStates from code
in AbstractClient. Default implementation does nothing, implementation
in Client performs the actuall call.
As a first case added to Client::move in order to be able to move the
implementation to AbstractClient.
The usage was always to trigger repaints on the old and the new
visibleRect. And store the new visibleRect as the future old one.
This is now encapsulated in a dedicated method called
addRepaintDuringGeometryUpdates().
Change required to get methods using TabSynchronizer moved to
AbstractClient. Unfortunately we need to cast to Client when calling
updateStates. It's save as if it's not a Client we
a) don't have a tabGroup in the first place
b) the check if (main == only) will hit and the method returns
The changeMaximize method is added as a pure virtual protected method
to AbstractClient. This replaces the previous pure virtual maximize
method. Which is now directly implemented in AbstractClient (reusing
the implementation previously in Client).
* skip all overhead on unrestricted moveResizes
* the titlebar is not guaranteed to be the top border (anymore)
* don't block vertical resize when resizing on a top corner
* reduce QRegion operations by knowledge about the degenerated titlebarregion (rect)
* rename int (sic!) "titleArea" to "requiredPixels"
REVIEW: 125428
Bhushan Shah
Martin Gräßlin
Thomas Lübking