Summary:
In preparation to support xdg-shell we need to make sure that ShellClient
does not assume m_shellSurface to not be null.
Everything that can be done through the surface() is resolved through
surface(). All accesses to m_shellSurface are nullptr checked.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1441
Summary:
Preparation for also supporting XdgShell. There will be different
ctors for ShellSurface and XdgShell, but most code needs to be shared.
Thus a dedicated init method is needed.
There is some restructuring in the init. All code depending on
ShellSurface being set is grouped and in an if block.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1440
Summary:
A user shouldn't be able to manually move/resize a desktop window or
a panel. So far this wasn't ensured.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1155
The damage event of the Surface does not consider the offset through
the server side decoration. Due to that we need to have a different
repaint and damage area. As Toplevel::addDamage(QRegion) is only used
in the Wayland case the repaint adjustment is removed from the generic
implementation and moved into the specific implementations. While it
wouldn't hurt to have the repaint adjustment in Toplevel, it would
trigger a repaint of an unchanged area.
For Client I'm not sure whether it's correct without considering the
clientPos. My testing shows it's working, but that might also just be
do to Xwayland using OpenGL buffers. Needs further testing.
This is a complementary commit to 4c7450a1f6:
After Workspace gets destroyed it's possible that ShellClient's are still
around. Their tear down should not crash due to calling into Workspace.
If a ShellClient supports the ServerSideDecoration interface we can
create a server decoration for it. For that updateDecoration is added
as a pure virtual method in AbstractClient and a more-or-less code copy
from Client is added to ShellClient.
Geometry handling is adjusted to consider the window decoration offsets.
We announce support for it and depending on whether we have a plugin
or not set the default mode to Server or None.
When a decoration interface is created it gets installed on the
ShellClient. But there it isn't properly used yet as we don't have
support for decorations in ShellClient yet.
This describes an additional offset for the client content. On X11
our client content position matches with the window - the window
decoration is part of the overall content coordinate system.
On Wayland the content is an own texture starting at 0/0. Thus a
mapping to texture coordinates will be required when server side
decorations are provided. The new information is used in the scene's
to adjust the rendering and generating of quads.
Replacement for calls to info->input() which is only valid for the Client
sub class, but not for ShellClient.
In ShellClient the implementation is swapped with wantsInput() and
wantsInput() has a new implementation which properly delegates to rules()
just like Client does.
This allows to check if specific ShellClient is from LockScreen or not,
as well as this adds method to verify if ShellClient is from input
method like maliit.
Now that KWin knows about which window is from Screenlocker it can apply
various security restrictions like no other window then greeter is on
top of it.
Reviewed-By: Martin Gräßlin
make the minimize effect work by reading taskGeometry
from plasmawindowmanagement and returning as iconGeometry()
there is one task geometry per panel window, iconGeometry()
will return the geometry associated to the nearest panel
from the window
REVIEW:125873
allow to minimize some kind of windows, all those that don't
have a plasmashell surface and those that have and have Normal
as role (to be sure to not minimize panel, desktop, etc)
REVIEW:125842
Similar to X11 world: we send a sync request on each size change and
block till we get the next damage with the proper size.
Testing seems to show a very smooth resize experience. We automatically
sync to the resize speed of the client.
Maybe we need a timeout in case the client isn't able to resize to the
requested size.
Don't emit both geometryShapeChanged and geometryChanged: the one
is set up to call the other.
Also adjust tests because maximize changes triggers too many geometry
changed signals.
So far only moving through useractions menu is possible and only through
cursor control (mouse events are lost).
A basic first autotest is added to validate the moving of Windows.
During tearing down the WaylandServer it's possible that ShellClients
are getting unmapped. For them make sure that they don't call into
the no longer existing Workspace.
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.
If the size is the same it's basically just a window movement. That's
nothing we need to roundtrip to the client, but can adjust the geometry
change directly.
The quick tiling test is adjusted to test this together with
sendToScreen. Each window is also sent to the next screen to verify the
state doesn't change and geometry is updated.
Note: the flag for quick maximization seems to get lost in this setup.
This is needed to properly restore to a valid geometry after quick
maximizing. Note: this is not yet perfect, actually it should be done
after initial placing, which means we do need a manage method like
Client.
The autotest for quick tiling is extended to cover maximize changes
and cover this case.
In Client existing method is marked as override, in ShellClient a new
override is added which delegates to requestGeometry. Existing method
is renamed to doSetGeometry and all internal calls delegat to it.
Needs better merging with the implementation of Client.
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).
If the surface indicates that it doesn't want keyboard focus we shouldn't
give it keyboard focus.
This was a problem with Kate's autocompletion tool tip windows.
REVIEW: 125553
So far we delegated to ShellSurfaceInterface, but it's possible that
we call into isFullscreen when the ShellSurfaceInterface is already
destroyed.
Note: the functionality needs to be slightly reworked. The fullscreen
state should change once we get a buffer for fullscreen, not when the
client requests it. This is a general pattern which is wrong also for
maximized, etc.
Whenever we set a transient we must register it with the parent and
remove it again. Also if a parent gets destroyed we must inform the
transients.
This fixes a crash in Deleted::copyToDeleted when connecting the main
clients. The crash condition was hit if the parent got destroyed
before the transient.
Reviewed-By: Marco Martin
Merges together the code from ShellClient and Client and removes the
starting differences. Long term it's better to have only one
implementation to prevent diversions in the implementation.
As it doesn't match exactly protected virtual methods are called
which allow more specific implementations for a certain aspect of the
layer resolving.
A transient ShellClient has an offset position to the parent surface.
Use this to position the ShellClient properly.
This fixes the random placement of menus.
