Summary:
This brings some more checks from Client to ShellClient. Thus the
states are better adjusted.
Unfortunately the X11 implementation is also slightly adjusted, so could
create regressions in worst case.
BUG: 368393
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3507
Summary:
When moving windows we don't want to snap against not visible windows
like auto-hidden panels.
BUG: 365892
FIXED-IN: 5.8.4
Test Plan: So far only auto-test, manual test will follow.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3225
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
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).
