Summary:
So far KWin used the window title provided from the window directly
without any sanitizing. This could result in broken window decorations
if the title included line breaks. Those were passed to the decoration
and depending on the way how the decoration renders the title, it could
result in visual breakage.
Having line breaks in a window title doesn't make sense. Given that KWin
now simplifies the title when copying it to it's own structure. This
also ensures that the title passed to e.g. task manager does not have
any line breaks on Wayland.
BUG: 323798
FIXED-IN: 5.8.4
Test Plan: Opened the web page in a nested KWin, properly rendered now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3215
Summary:
This change ensures that the DebugConsole does not have a minimize
button.
BUG: 372000
FIXED-IN: 5.8.4
Reviewers: #kwin, #plasma_on_wayland, broulik
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3244
Summary:
KWindowSystem provides a KDE specific property for the desktop file
name. This allows KWin to take the icon from the desktop file. The
advantage from the desktop file is that KWin normally gets higher
resolution icons than provided through the xproperty based icons used
previously. If the desktop file does not provide an icon name, KWin
falls back to the previous implementation.
As on Wayland the icon is taken from the desktop file name already the
code for X11 and Wayland is merged in AbstractClient. Also to the
PlasmaWindowInterface the appId is taken from the new desktop file
instead of the resourceName. Due to that for Xwayland windows where KWin
knows the desktop file name it can be passed to PlasmaWindowInterface.
This allows e.g. the task manager to better map the windows to
applications and provide better icons. Also it means that icons do not
need to be passed as bitmap data to the clients.
Test Plan:
Verified that icon is taking from desktop file if provided and
from X property if not provided and that Wayland windows still have icon.
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3177
Summary:
On X11 one needs to force activate a panel to pass it focus. This change
implements something similar for Wayland but a little bit more stateful
by using a request on the PlasmaShellSurface. If set KWin will activate
the panel.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3037
Summary:
This change implements auto-hide support for Wayland panels. To properly
test the screenedgeshowtest is reworked to support both X11 and Wayland
windows.
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3080
Summary:
On Wayland the QtExtendedSurface is used to pass the path to the color
scheme using the generic window property. To support this ShellClient
installs an event filter on the extended surface and listens for dynamic
property change events.
As the color scheme is KDE specific anyway it is not a problem that a Qt
specific interface is being used. For other toolkits just passing the
name to KDE's color scheme isn't sufficient anyway. If at some point we
find a way to support this for e.g. GTK+ we would need to come up with a
dedicated interface.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3047
Summary:
For X windows KWin uses the generic X icon if no icon is found. Thus
KWin should use the generic Wayland icon if no icon is found for a
Wayland client.
With this change applications with incorrect desktop file name at least
get a generic icon instead of no icon.
Test Plan: Started Qt assistant on Wayland and it had icon.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3023
Summary:
This implements the hideClient for ShellClient which was previously
not implmented. Also autotest for same is added.
Test Plan: ran autotest
Reviewers: graesslin, #plasma
Reviewed By: graesslin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3022
Summary:
This change ports ScreenEdges to operate on AbstractClient instead of
Client. For this AbstractClient gained a new pure virtual method
showOnScreenEdge which is also implemented in ShellClient.
In ShellClient the functionality is bound for the case windows can
cover a panel. If triggered the panel gets raised again.
The auto hiding panel, though, is not yet implemented. For that the
protocol needs to be adjusted to give a hint to the compositor when to
hide and hint back to the panel when it was shown. This needs a change
in KWayland and thus is not 5.8 material.
Test Plan: See added test case
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2793
Summary:
The PanelBehavior was incorrectly mapped to hasStrut resulting in too
many modes creating a strut for the panel.
CCBUG: 368499
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2788
Summary:
A fullscreen ShellClient still had a decoration which was caused by
a combination of several bugs:
* when going to/from fullscreen the decoration was not update
* noBorder did not return true for a fullscreen window
* wl_shell emits fullscreen changed and maximized changed
Comparing to X11 Client both is done. So ShellClient needs to do the
same. This ensures that the correct geometry is requested when going
to fullscreen.
BUG: 366764
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2751
Summary:
The call to update the layer was performed before adjusting to
fullscreen. Thus the layer didn't get updated at all as it still
evaluated to "not fullscreen".
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2758
Summary:
A not shown window may accept focus (e.g. when minimized). Given that
the condition was wrong and broke when making minimized windows not
shown.
This change takes the idea of not passing focus to a closing or unmapped
window directly into acceptsFocus. Which also means that this condition
now works for xdg_shell windows.
BUG: 368673
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2745
Summary:
The restore geometry gets initially set to 0/0xsize before the placement
is done. When going into updateClientArea and then afterwards into
AbstractClient::checkWorkspacePosition the geometry restory is used for
calculating the new position. This results in windows getting moved to
0/0 when e.g. plugging in a new screen or a panel changes, etc.
This change ensures that the restore geometry is set correctly after the
first placement.
BUG: 366696
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2627
Summary:
So far this connect was only in ShellClient, but it's needed for all
Toplevels. Also when a XWayland window has it's surface size changed,
the pixmap needs to be discarded. Otherwise KWin might hit an assert
in AbstractEGLTexture due to the buffer having a different size than
the texture had previously.
Test Plan:
Firefox, click download on bugreports.qt.io used to trigger
this for me. With this change no longer able to reproduce.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2583
Summary:
This allows Client to use the Wayland-specific implementation if there
is no icon geometry set through the X11 way. That way Xwayland windows
have an icon geometry even if Plasma is using Wayland and setting the
icon geometry in the Wayland way. Which is expected as Plasma is
ignorant about the windowing system a PlasmaWindow uses.
In order to move the code from ShellClient to AbstractClient
WaylandServer gained a new findAbstractClient(Surface*) method which
is just like findClient(Surface*) with the difference that it returns
an AbstractClient instead of a ShellClient*.
Test Plan:
minimized/unminimized an X client on Wayland, verified
animation is correct (though broken in general for minimize)
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2530
This fixes a regression found in TestSceneQPainter for restarting the
Compositor. The internal clients were never added to the Scene.
We cannot just call setupCompositing because there is a phase during
startup where setupCompositing already passes but the Compositor is not
yet fully initialized. Thus it could happen that it's called twice which
makes the Scene assert.
To solve that setupCompositing and finishCompositing are now overriden
in ShellClient and track whether they successfully called
setupCompositing.
Summary:
We need to call Workspace::clientHidden when minimizing. Otherwise
Workspace doesn't update the active client and the now minimized
window is still active.
BUG: 366634
Test Plan:
Test case works now and also tested in nested setup that
active window changes.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2410
Summary:
Plasmashell's desktop windows are RGBA which forces the compositor to
perform blending and render the background. That is absolutely pointless
as there is no window behind the desktop window it could blend to. All it
does is destroying KWin's more optimized code path and forcing additional
rendering which will never be visible (including shader push/pop).
With this change KWin forces desktop windows (both X11 and Wayland) to
be considered as opaque by setting the depth to 24. Thus blending is
disabled and the background is not rendered.
Test Plan:
Verified with apitrace that KWin goes in the opaque rendering
path for desktop windows.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2382
ShellClient::doSetActive calls into focusToNull to deactivate active
windows on X11. But this should only be done when activating a
ShellClient. When deactivating a ShellClient the focusToNull can
result in an activated X-client to lose activation.
Thus this change ensures that focusToNull is only performed for a
now active ShellClient.
Reviewed-By: bshah
Summary:
With this change KWin can create window decorations for internal windows.
Thus it's also possible to move internal windows and resize them which is
especially important for the debug console.
Reviewers: #kwin, #plasma_on_wayland, sebas
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2371
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 WaylandServer creates the XdgShellV5 interface and hooks it up
to create a ShellSurface whenever an xdg surface or xdg popup is created.
ShellClient gains some new ctors for the different variants and is
adjusted to delegate to xdg surface respectively.
With this change KWin mostly supports xdg-shell protocol. Still missing
is support for the "geometry" request which is rather difficult to
implement in KWin.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2108
Summary:
So far when a ShellClient got unmapped ready_for_painting was set to
false. That is the ShellClient was treated in the same way as a not
yet shown window. It was completely excluded from painting, a close
animation impossible.
This change makes use of the functionality available in
Client::hiddenInternal(). The window is considered as hidden, thus
still excluded from e.g. getting input events, but could be rendered
any time as we still have a previous window pixmap (if referenced).
This allows to have it considered in the rendering pass, but effects
still cannot make use of it as that state is not yet exposed to the
effects.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2083
Summary:
It's mapped to be on all desktops in order to properly have tooltips
show for the panel (which is on all desktops) instead of just on the
desktop it's created.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2032
Summary:
Sets notifications on all desktop and doesn't activate them.
Unfortunately doesn't work on Plasma yet. Seems the windows don't get
tagged properly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1930
Summary:
With the NoBorder option set the DecorationBridge won't create
decorations. Thus we get a nullptr and obviously should not call
into it. There was already a check for whether decoration is null,
so that is a rather embarrassing bug.
Test Plan: Test case added which exposes the crash
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1980
Summary:
Plasma's OSD windows were stealing focus on Wayland. We can be sure
that they should not get keyboard focus, so a check to acceptsFocus
is added.
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1927
Summary:
If the ShellSurface gets destroyed while a decoration repaint is pending,
it is possible that on tear down the decoration calls into
ShellClient::caption. This used to call into ShellSurfaceInterface::title
which accesses a d-ptr which is already destroyed at that point.
This change caches the caption instead of delegating to ShellSurface,
just like almost everything else caches. Thus the tear down cannot access
invalid memory.
Once we can depend on Frameworks 5.24, we should also make sure to
connect to the new Resource::unbound signal to be able to handle tear
down prior to the object being completely deleted.
Test Plan:
Unfortunately no test case as this depends on phase-of-moon
aligning of destruction of the interfaces
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1913
Summary:
When managing a new decorated ShellClient we observed that the window
gets placed with a wrong geometry and on next damage event expands into
a strutted area.
The main reason for this behavior is that the window geometry did not
get updated when creating the decoration. With this change the geometry
gets updated, so that the placement is performed on the correct geometry.
The change itself does not yet cover all conditions. E.g. a maximized
windows which will get decorations will be incorrectly sized. This
requires further changes.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1812
Summary:
The idea is to not send multiple resize requests to a client when we
know that we might have multiple geometry changes. E.g. when going
from maximized to restored the borders change and trigger a resize in
addition to the resize from switching to restored.
The implementation is inspired by the GeometryUpdateBlocker.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1808
Summary:
This ensures that we don't send a size request with the borders still
added.
Test Plan:
Verified that a maximized window is properly sized and
doesn't have empty borders
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1807
Summary:
This ensures that resizing a panel updates the client area. On X11 there
is an event when the struts change, but on Wayland the struts are implied
from window type (panel) and the panel behavior, so we need to trigger it
manually.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1811
This is an update to c95ddb7102 and
implements the emit of maximized changed in deocration like on Client.
Overall the code looks like it should be merge better together with
Client.
Reviewed-By: kbroulik
Summary:
So far destroyWindowManagementInterface was only called when the
ShellClient got unmapped. But it's possible (although not recommended)
to just destroy the Surface without prior unmapping. In that case the
PlasmaWindow got leaked.
This change addresses this problem by always calling
destroyWindowManagementInterface from ShellClient::destroyClient.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1762
Summary:
If a PlasmaShellSurface is a Desktop, a Panel or an OSD it implies
that the window is on all desktop. So let's set it like that.
Test Plan: Auto test added and also confirmed by manual testing
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1747
Summary:
We don't want external processes to know anything about the lock screen
windows. Especially we don't want them to be able to request close on
them.
Thus better never show thus windows to them.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1760
Summary:
For some windows we don't want to create a PlasmaWindow. Not all
ShellClients are something the outside world should see. This change
introduces the first restrictions:
* KWin internal windows are hidden
* transients not accepting focus are hidden
The latter case doesn't work though if the Surface is mapped prior
to creating the shell surface. In such a situation it's racy as KWin
handles the create surface request before we get the setTransient
request. This is difficult to handle as we do want to react quickly.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1759
Summary:
The idea is to have KWin provide a virtual keyboard. To support this
KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
QPA plugin loads it.
KWin has a new class VirtualKeyboard which acts as the focus object and
the "proxy" for input methods. The QPA plugin ensures that this is the
focusObject, so that all input method related events are sent to this
class. From there it will be possible to delegate to other applications
through the Wayland interfaces.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1638
KWayland was changed: the ShellSurfaceInterface does no longer get
destroyed when the parent SurfaceInterface gets destroyed. For the
wl_shell_surface there is no dtor request in the interface so the
resource sticks around and also the ShellClient is kept.
This change ensures that the ShellClient also gets destroyed when
the Surface is destroyed. This should fix some broken tests.
Summary:
Most likely the window is in the process of getting destroyed. In that
case the following destroy of the Surface is also going to destroy the
decoration.
This was causing an interesting effect with the QQuickRenderControl used
by Aurorae. When getting destroyed it ensures that all posted events get
processed. This includes the destroy of the Surface which entered
ShellClient::destroyClient which again destroyed the decoration. In other
words a recursive destroy which ended with wonderful crashers due to
double deletions.
If the window is not unmapped this might still cause problems: more
testing needed.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1641
Summary:
Toplevel::window() is the actual X11 window. This makes it difficult
to use as the generic identifier for both X11 and Wayland. The Wayland
ShellClient already had a windowId() which is now added to Toplevel as
a virtual method. On X11 (Toplevel default) it returns the window().
The method window() now returns XCB_WINDOW_NONE for classes without
the Toplevel::m_client, such as ShellClient. Thus it allows to properly
check whether we are on Wayland or X11.
The code is adjusted to use windowId where a generic id is needed and
to properly check whether the window is valid before using it where
a window() is used.
This also fixes at least one additional unknown issue in
Workspace::setActiveClient
where the windowId of a Wayland client was passed to X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1527
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.
This change introduces a mechanism for internal windows to be rendered
to a QOpenGLFramebufferObject to be composited using the texture bound
to the FBO. This is useful for in-process rendering (e.g. QtQuick) and
at the same time bypassing the windowing system.
The OpenGL context of the QOpenGLFramebufferObject needs to be sharing
with the compositing OpenGL context.
For the appId we use:
* wl_shell windowClass for Wayland clients
* resourceName from window class for X11 clients
This is implemented by sharing the window class implementation in
Toplevel.
CCMAIL: hein@kde.org
