Summary:
The only place where this method is used is testMaximize. Though that
usage is not justified. We're checking what KWayland already checks.
Test Plan: Compiles, all tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18635
Summary:
This is only relevant on Qt and when WlShell is used.
This was only the case before Qt5.10.
We will depend on Qt5.12 next release.
Static Qt builds which are that old typically wouldn't contain QtWayland
Test Plan: Compiles. Not used in tests
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18594
Summary:
Does something similar to our existing ServerDecoration, but based
around XDG Shell patterns and with a few subtle differneces.
We'll probably still need both in kwin for the forseeable future as GTK3
won't ever change from using the KDE Server Decoration.
Test Plan:
Relevant unit test. It's a bit simpler as spec states
toolkits must follow what the compositor configures if they
bind the interface.
Modified plasma-integration to remove ServerIntegration
(as Qt5.12 has native support) all my windows look and act the same.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17756
Summary:
The dialog invoked through user actions menu takes the internal uuid as
command line argument which allows to query the required information
from KWin instead of using X11.
This allows to enable the system for Wayland windows.
In order to replace the usage of ClientMachine in the rules dialog the
dbus interface is extended by a value whether the window is on the
localhost. This is exposed through a virtual method on toplevel which is
overridden in ShellClient and there always returning true.
Test Plan: Run a nested Wayland and opened the dialog on a wayland window
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17750
Summary:
Support XDGShell Positioning. This gives a client a lot more control
over where the popup will be placed as well as control over how to
handle constraints. i.e what to do if the popup doesn't fit.
trasientOffset was replaced with a method on the client as semantically
it's the role of the client to handle constraints.
Both slide and flip constraint adjustments are implemented. Resize
constraint adjustment will be handled in a future patch.
WlShell is handled by treating it as 1x1 sized anchor with slide
constraint adjustment.
Test Plan:
Manual test of a client implementing xdgpopup exists in kwayland
Extensive unit test here
Existing WlShell test passes (after D16314 which fixes the original)
XdgPopup has a new unit test suite against manually calculated values
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16325
QSize default constructor does not set width/height to 0,0 but instead
to an invalid size -1,-1. This went unnoticed as Qt5.12 corrected these
values to the intended 0,0.
Reviewed By: Roman Gilg
Summary:
Previously when updating the state we would send a configure event with
the size 0,0. This means the client chooses the size. For regular window
this works as most toolkits treat this to mean the size that we
previously requested. It's not explicit in the spec either way.
For maximised windows it's a problem, the spec clearly states that when
maximised clients must follow the size given. Telling the client to be
0,0 doesn't make sense.
By always sending our last requested size we remove any ambiguity.
Test Plan:
Ran
Maximised some windows and changed focus
WAYLAND_DEBUG showed we weren't sending a configure with 0,0
after startup
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16055
Summary:
The Scale effect and the Glide effect have to animate only ordinary
windows(i.e. the ones that are considered to be apps).
On X11, in order to distinguish ordinary windows from combo box popups,
popup menus, and other popups, those effects check whether given window
is managed.
On Wayland, there is no concept of managed/unmanaged windows.
XDG Shell protocol defines 2 surface roles:
* xdg_toplevel;
* and, xdg_popup.
The former can be used to implement typical windows, the ones that can
be minimized, maximized, etc.
The latter can be used to implement tooltips, popup menus, etc. Thus,
that's a good criteria to filter popup windows.
CCBUG: 398100
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: #kwin, graesslin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15117
Summary:
The change to make maximize mode asynchronous featured the comment
>Things are a bit complex with borders. Technically we
>shouldn't update them till we get a response, but we also need to have
>the correct geometry of the full size window in our request. For now
>they behave as before, updating when we request the change.
We call setNoBorder when we request the geometry but decoratedClient
also checks the maximise mode, in order to follow the scheme above we
need this to operate on the requested state not current state.
X is unaffected.
This fixes the borders being restored correct after maximize/restore.
Test Plan:
Chose a theme with visible borders
Maximised a window and back
They restored
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15991
Summary:
A window maximising is an async operation. We work out what size we want
the client to be, then request the client to update. The window isn't
really maximised until we get that new buffer with the new size.
This patch splits the requested, pending and current state, updating as
appropriate.
Things are a bit complex with things like borders. Technically we
shouldn't update them till we get a response, but we also need to have
the correct geometry of the full size window in our request. For now
they behave as before, updating when we request the change.
X code is untouched.
This hopefully fixes maximise animations on wayland as now we update the
geometry before emitting maximisedChanged.
Test Plan:
Maximised a window with the button and double clicking title bar.
I get only the following events on maximise/restore:
19:51:39.156 KWin::EffectsHandlerImpl::slotGeometryShapeChanged geometry
shape changed QRect(47,24 640x509) QRect(0,0 716x573)
19:51:39.157 KWin::EffectsHandlerImpl::slotClientMaximized slot client
maximised true true
19:51:40.522 KWin::EffectsHandlerImpl::slotGeometryShapeChanged geometry
shape changed QRect(0,0 716x573) QRect(47,24 640x509)
19:51:40.522 KWin::EffectsHandlerImpl::slotClientMaximized slot client
maximised false false
BUG: 382698
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15150
Summary:
When we want to change a client's size and position together we have to
request the client becomes a new size and only then move the window to
the new location.
Currently we process the new position the next time the buffer updates,
but with no guarantee that it has actually tried to resize/whatever yet.
The client could be providing a new buffer just because the contents
have changed.
XDGShell has an acked serial designed to keep everything precisely in
sync. A surface represents the last configure that was acked.
This patch tracks the pending position for each configure and applies it
accordingly.
WL_shell does not have this mechanism, so behaviour is kept the same as
before.
----
This is a pre-requisite to syncing maximisedState/isFullScreen with the
configure request.
Potentially we could remove the isWaitingForResizeSync checks when
resizing and it will still resize smoothly.
Test Plan:
Relevant unit test still passes with the client responding
Resized a window from the left edge with WLShell and XDGShellV6
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15135
Summary:
We send out too many configure requests when finishing move resize which
also triggers quick tiling. This change addresses the problem of the too
many configure requests by making the configure method check whether
geometry updates are blocked. And to make this work properly for the end
of finish move resize the complete method is wrapped in a geometry
update blocker.
BUG: 388072
FIXED-IN: 5.12.1
Test Plan:
Quick tiling test passes, both Wayland and X11 windows are
quick tiled correctly.
Reviewers: #kwin, #plasma, jgrulich
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10156
Plus test
Test Plan:
Ran kwin with menus and patched QPT
Ran test
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: graesslin, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9262
Summary:
Commit 5d9027b110 introduced a regression in TabBox by using the generic
framework inside KWin to test for same application. What I did not
consider was that the code in TabBox was "broken by design". It didn't
use the generic check as that is too strict and considers windows from
different processes as not belonging to the same application. But this
is not wanted in the case of TabBox.
On the other hand the change itself is an improvement to also support
Wayland in a better way and not have special handling situations. Thus
just reverting would not help.
Instead this change addresses the problem by extending the internal API
and to allow more adjustements. So far there was already an
"active_hack" boolean flag. This is extended to proper flags with an
additional flag to allow cross application checks.
The checks in Client which would filter out different applications check
for this flag and are skipped if set. In addition ShellClient also adds
support for this flag and compares for the desktop file name.
Thus we get in TabBox the same behavior as before with the advantage of
having a better shared code base working on both X11 and Wayland.
BUG: 386043
FIXED-IN: 5.11.4
Test Plan:
Started two kwrite processes on X11, clicked new in one of them,
used Alt+` and verified that there are three windows shown.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8661
Summary:
So far ShellClient did not support that the user can set a window to
fullscreen. This was omitted in the initial implementation as WlShell
doesn't support passing the state back to the surface.
With XdgShell this problem doesn't exist any more and we can implement
it. The implementation is mostly based on the one for Client and
adjusted for the Wayland world.
Test Plan:
New test cases and manual testing (send kate and kwrite to
fullscreen through alt+f3 menu)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8169
Summary:
In a bug report there was a reference that on multi-screen KSplash is
not placed correctly. I investigated and noticed that it is an OSD which
sets an own position. In KWin the events were processed correctly but
the position was off.
The problem is that KWin has code to correct the position of an OSD when
it's size changes. This happens also on first damage and then the window
gets incorrectly placed when the position is set. So honor that the
position is set.
Test Plan: Restarted the session, ksplash positioned correctly now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8268
Summary:
So far window rule specific functionality was only implemented in Client
and in ShellClient there was only a dummy implementation. This change
moves the client_rules member variable from Client to AbstractClient.
Areas which would not compile anymore are adjusted.
This is a first step to get window rule support for Wayland windows.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8090
Summary:
Adds XDGV6 support for the kwin side.
Popup placement support is limited to the stuff v5 had,
a simple offset, rather than the awesome new positioner.
But Qt doesn't make use of it yet either.
Also ideally we should do all the positioning before sending the first
configure, but again Qt doesn't actually do anything with that anyway.
Also integrate pinging clients
Test Plan: gtk3-demo works nicely.
Reviewers: #plasma, graesslin, mart
Reviewed By: #plasma, graesslin
Subscribers: mart, graesslin, kwin, plasma-devel, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D6591
Summary:
The implementation can now be shared, it doesn't differ anymore between
X11 (Client) and Wayland (ShellClient). So instead of code duplication a
shared implementation in AbstractClient.
Test Plan: X11 and ShellClient tests still pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7426
Summary:
Bringing another caption feature from X11 to Wayland. If we have
multiple windows with the same caption, starting from the second window
a suffix <number> is added.
E.g. if we have three windows with caption "foo", the naming is:
* foo
* foo <2>
* foo <3>
The change tries to use as much shared code between the X11 and Wayland
implementation. Unfortunately it's not possible to share completely as
the X11 implementation does X11 specific things like editing the visible
name.
By sharing the code the numbering also works cross windowing system.
That is if a window is called "foo" on X11, a new window on Wayland with
caption "foo" will get adjusted to "foo <2>" and vice versa.
The change also eliminates a duplicated signal for captionChanged in
ShellClient (found by test case).
By using the shared implementation on X11 side a bug gets fixed which
got introduced with the support of "unresponsive", this is no longer
considered and the numbering still works even if there is a window which
is unresponsive.
Test Plan: New test case and manual testing
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7425
Summary:
A surface has an API to know which screen(s) it's on, this is useful
especially for knowing the scale it should render at.
In practice Qt currently doesn't do anything with this information; but
that's set to change.
Test_helpers is changed as we need to create output objects in order for
wl_surface to map them.
Closes task T4467
Test Plan:
Attached unit test.
As mentioned above, it doesn't have any real world impact currently, so not a lot
to test.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: johanhelsing, graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Maniphest Tasks: T4467
Differential Revision: https://phabricator.kde.org/D7359
Summary:
The generation of the shortcut caption part is moved from Client to
AbstractClient. The ShellClient also has a captionSuffix and implements
the full part in caption.
Overall this needs more refactoring to support more sharing between the
two implementations. But one step at a time.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7093
Summary:
The parameter is not used anywhere in KWin. Only the default value was
used. So let's drop this.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7059
Summary:
Moves most of the implementation from Client to AbstractClient, so that
it can be used for both Client and ShellClient. Only the X11 specific
code is kept in Client.
Not yet implemented is updating the window caption.
Unfortunately the testing of this feature showed that setting a window
shortcut is not working on Wayland at all (the Qt widget doesn't properly
catch the shortcut). So this feature is currently only of erm theoretical
use.
Test Plan: Added new test case. No testing in real world as explained.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6818
Summary:
So far KWin did not properly handle popup windows. That is when a popup
surface got created and a click outside the surface happened KWin did not
send out the popupDone Wayland event.
This change makes KWin aware of whether a surface is a popup and tracks
through a new PopupInputFilter whether there are popup windows. In case
there are popups the new filter waits for mouse press events and cancels
the popups if the press does not happen on any surface belonging to the
same client. To quote the relevant section of the Wayland documentation:
The popup grab continues until the window is destroyed or a mouse
button is pressed in any other client's window. A click in any of the
client's surfaces is reported as normal, however, clicks in other
clients' surfaces will be discarded and trigger the callback.
So far the support is still incomplete. Not yet implemented are:
* support xdg_shell popup windows
* verifying whether the popup is allowed to be a popup
* cancel the popup on more global interactions like screen lock or
kwin effect
BUG: 366609
FIXED-IN: 5.10
Test Plan: Auto test and manual testing with QtWayland client
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5177
This brings back global menu support in KWin.
The DBusMenu infrastructure is different that we just read the DBus service name and
menu object path from the windows rather than passing around window IDs on DBus which
won't work on Wayland.
Differential Revision: https://phabricator.kde.org/D3089
Summary:
The OnScreenNotification gets moved during its placement. This update
of the geometry did not get synced to the QWindow's geometry as it
should.
The reason for this is the rather special implementation of
AbstractClient::move. This just modifies the geom variable and does not
call into setGeometry at all. Instead a virtual doMove method is invoked
to inform the platform specific client implementation about the move of
the window. For a "normal" ShellClient that is fine - there is nothing
to do.
This change adds an implementation of doMove in ShellClient to sync the
geometry to the internal window. This is not yet enough to fix the
geometry of the OnScreenNotification. It gets placed with a
GeometryUpdatesBlocker in place causing the doMove never to be called.
Instead setGeometry is invoked again when the geometry updates get
unblocked. So far ShellClient did not do anything in this case. This
change ensures that at least the doSetGeometry method is performed again.
Test Plan: Added test case and manual testing of OnScreenNotification
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3963
Summary:
AbstractClient gains a new pure virtual killWindow method and this gets
implemented in ShellClient.
ShellClient performs the killing by sending a term signal to the
process. This can only work if the client connected through the socket
and didn't get a socketpair fd passed. In that case the pid is KWin's
and KWin doesn't want to terminate. Thus this is special handled to
destroy the connection instead.
In case terminating the process has no effect, the connection gets
destroyed after five seconds.
The KillWindow is adjusted to operate on AbstractClient instead of
Client.
This implements T4463.
Test Plan: Killed windows and auto test
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3370
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:
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 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:
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:
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:
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
