Summary:
This adds again the workaround from 1fb2eace3f, which got temporarily
removed by 9b922f8833.
BUG: 386304
Test Plan: Manually
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21601
Summary:
All internal clients live in the x stacking order, but when such a
client is closed, it will be moved to the normal stacking order.
Given that internal clients don't specify the desired layer, they will
be moved to the normal layer, which is not really what we want because
it means that the task switcher window will be placed below docks.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21116
Summary:
The size passed to an XDG shell configure request should match the
window size of the given window, we don't want to include the size of
any shadows that may be drawn by the client.
Kwin has the same concept of geometry for both window management, input
and rendering.
In order to approach this in a way that does not risk any regressions
with kwin's current structure AbstractClient::geometry remains the
canonical source and we handle the window within that internally within
ShellClient treating the windowGeometry as a set of margins from this.
This is part of a much bigger task (T10867). This patch addresses
windows growing when starting a drag based resize.
BUG: 403376
Test Plan:
Unit test
gtk3-demo
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20937
Summary:
Currently popups get positioned once at the initial configure, to set
the correct size and again when they are mapped.
Toplevels are currently only positioned when they are mapped. This works
for all cases where the the toplevel defines its own size, but not if
the window should have an initial size set by the placement strategy or
window rules. Most notably the maximised placement strategy used on
plasma mobile.
Being out of sync and resizing later currently causes a positioning bug
when plasma mobile is used with XdgShell.
This patch repositions all top levels that don't have a position set
through the plasma interface.
Test Plan: Relevant unit test
Reviewers: #kwin, bshah
Reviewed By: bshah
Subscribers: zzag, bshah, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20241
Summary:
When resizing a window particularly from the left side, we need to
co-ordinate moving the window with when we get the resized buffer.
The code in AbstractClient::handleMoveResize checks
isWaitingForResizSync to make sure we never send more than one resize
request at a time to keep that in sync.
This makes sense on X and wl_shell_surface, but not on XDGShell where we
can track which resize events have been handled by the client.
ShellClient already keeps a stack of our pending configure requests and
handles everything appropriately, we don't need to block.
This results in a smoother dragging experience and avoids a potential
deadlock currently seen when a client may not reply to a no-op configure
request.
CCBUG: 403376
Test Plan: Async ack handling is covered by existing unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20397
Summary:
It might happen that the moving client gets closed or crashes. In that
case, we have to manually reset Workspace::movingClient, otherwise KWin
will most likely crash later on.
BUG: 405379
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19708
Summary:
When user asks KWin to show desktop, the compositor just raises every
desktop window, it doesn't attempt to minimize normal clients, etc.
Because desktop windows contain stuff like background and icons, the
compositor has to raise all clients that are somehow correlated with
desktop (e.g. panels, etc). Otherwise it would pretty weird to show only
desktop background.
Currently, not all plasmashell's clients are raised when the compositor
shows desktop because belongsToDesktop is not implemented for ShellClient.
BUG: 404801
Test Plan:
* Show desktop;
* Open Kickoff (without this patch Kickoff is not visible).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19386
Summary:
Everything on the wl_surface is double buffered.
When we create an XdgShell toplevel or popup we shouldn't treat it as
attached until it's committed to the surface.
A client should commit the surface after it's sent it's initial state of
the Xdg topLevel; minimumSize, title, app_id, etc.
By blocking sending configure events we will have flushed the correct
initial state before sending a single atomic correct event to the
client. It also adds a hook to re-evaluate rules now that all properties
are set.
Arguably this applies to WlShellSurface too, but I've left it unchanged
as it's deprecated and hard to verify real client behaviour.
Test Plan: Ran all unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18583
Summary:
We can handle the case of a null size inside
ShellClient::requestGeometry and that makes that method more robust.
With that we don't need to handle separate code paths in
the handler of RequestGeometryBlocker.
It's not an exact identical code path, but everything still works out.
If the geometry is unchanged, we'll save the positionAfterResize but
when we apply it doSetGeometry will no-op.
There's also an assumption that toggling maximised will always send a
valid size, but that's true for the current state.
Test Plan: Ran unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19331
Summary: When creating a surface and setting it as fullscreen before
attaching its buffer KWin does not know the original dimensions of the
surface and tries to use an invalid value when unsetting the fullscreen
flag. This patch fixes this by sending a configure with the size of 0,0
- which according to xdg-shell spec means that the client is requested
to set its size by itself.
Test Plan:
1. Create a fullscreen Wayland window.
2. Toggle fullscreen off.
3. KWin should send a configure event with size 0,0 instead of 1,1.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: zzag, graesslin, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16710
Summary:
placeIn did not handle the case for a popup not having had the size
already set and only being available via
m_xdgShellPopup->initialSize(). This is needed if we want to call placeIn
at the correct time, before the window is mapped.
There was also a logic bug when sliding popups. We called the
confusingly named setX thinking it would be move the popup keeping the
width the same. In practice it moves the left edge keeping the right
position the same. This wasn't an issue as the size was
discarded.
Handling the resize constraint is not yet done, but it should now be
even more trivial.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18956
Summary:
Most of the functionality which is special to internal clients is moved
from ShellClient to InternalClient. As KWin's qpa is still bound to the
Wayland protocol InternalClient inherits from ShellClient. Due to that
some aspects in ShellClient are "weird". ShellClient still detects
whether it's an internal client and uses the variable m_internal to
capture the state. This is required as we cannot use the isInternal
method. Most of m_internal usage is in init which is called from
constructor of ShellClient. Thus it's not possible to call into virtual
methods of InternalClient.
Also some of the code is duplicated and some methods are temporarily
marked as virtual.
The next step will be to remove ShmBuffer for internal windows which
should decouple the two implementations further with the long term goal
of having InternalClient inherit AbstractClient directly.
Test Plan:
Run nested KWin, triggered outline (OpenGL case) and debug console (shm case).
InternalWindow unit test still passes.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18569
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:
When we create a new Shellclient there may be a pending relevant
interface.
For every other case this is handled in WaylandServer, the class
responsible for attaching new interfaces at runtime.
The only exception is ServerSideDecorationInterface which is handled in
the ShellClient constructor.
This makes everything consistent.
No behavioural changes.
Test Plan: Ran unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18592
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.
This is something I find unsuited, for the following reasons:
* any test in KWin for functionality set through the plugin would fail
* it's not clear what's going on where
* in worst case some code could deadlock
* KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used
The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.
But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.
To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.
To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.
This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).
As the change could introduce regressions I'm targetting 5.16.
Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18228
Summary:
So far we didn't try to do high DPI on kwin internal windows, such as
the user context menu and tab bars and whatever.
Due to wayland scaling they were the correct phyiscal size but upscaled.
This patch fixes our QPA to enable Qt's high-dpi support.
BUG: 402853
Note icons are still low res. This is because the global
QGuiApplication::devicePixelRatio which is the max of all connected
screens is static for the duration of the app. QIcon uses this when
determining the DPR to use. This will require a Qt change.
Test Plan:
Ran at 2x on my normal DPI screen (as that's easier to see anything)
* User action menu is high DPI
* Window deco tooltips are still fine
* Tab switcher is high DPI
* Overlay in present windows Desktop grid are still ok
Reviewers: #kwin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18042
Summary:
The new test is similar to testToplevelOpenCloseAnimation. The
main purpose of this test is to verify that the Fading Popups effect
animates all sorts of popups, e.g. popup menus, tooltips, etc.
testAnimateUserActionsPopup is skipped for now because stuff
that animates unmapped clients is broken.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17992
Summary:
Just accessing Qt::Popup WindowFlag.
BUG: 402852
Test Plan: Not tested for the described problematic case
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17981
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:
If a parent window is minimized, then its transients have to be
minimized as well, so the minimize behavior is the same on both
X11 and Wayland.
BUG: 401950
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17570
Summary:
In shell surface, maximise mode and fullscreen are exclusive
fullscreen->toplevel should restore the state we had before maximising
Test Plan: testMaximisedToFullscreen unit test
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16921
Summary:
In the case of going from maximised to fullscreen when decorated the
geometry of the window (as far as kwin is concerned) could remain static
if we have no panels, but we still need a newly resized buffer from the
client.
When checking if we need a new buffer or to perform the geometry change
directly we need to compare the client size without borders.
Test Plan: maximizedToFullScreen unit test
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16920
Summary:
With the plasma shell protocol, a ShellClient gets its role/window type
after it's created, so the cached value of the popupWindow property in
EffectWindow can be wrong.
In addition to that, the value of the popupWindow property still can be
wrong because plasma shell surfaces don't have xdg-popup role, so we need
to check NetWM-based window type in ShellClient::isPopupWindow.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16835
Summary:
testMaximizedPassedToDeco was failing because it didn't handle async
maximization.
testBorderlessMaximizedWindow was failing because setNoBorder can modify
geometry, so we end up with a wrong restore geometry.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16755
Summary:
It should be indicating the current state of horizontal and vertical
maximisation not whether it changed or not.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16740
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:
Add a debug format for ShellClients, otherwise the output is always
empty. Also add the nospace qualifier to ShellClient's and Client's
debug output to present it correctly.
Test Plan: Manually.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15560
Summary:
Internal KWin windows might be not in sync with their PlasmaShellSurface.
This could be a problem in general, but for now atleast guard against
invalid setPosition requests.
BUG: 386304
Test Plan: Manually
Reviewers: #kwin, davidedmundson
Subscribers: davidedmundson, ngraham, graesslin, kwin
Tags: #kwin
Maniphest Tasks: T8771
Differential Revision: https://phabricator.kde.org/D13084
This reverts commit 8a2a00a4ca.
It was likely wrongly pushed before the KWayland changes, so it won't
compile.
Feel free to reinstate it once the dependent changes (KWayland) are in.
CCMAIL: bundito@gmail.com
CCMAIL: kwin@kde.org
Summary:
Adding "SkipSwitcher" to the API, following discussion in
BUG 375921
Depends on / related to D11925 and D11924
Reviewers: hein, #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, #plasma, ngraham, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11926
Summary:
Especially when a window is first mapped it might be that the appId is
not yet set. So window rule matching doesn't happen. This change
evaluates the window rules again after the appId changes, so rules for
the appId match.
Test Plan: added test case
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11268
Summary:
This allows to override the desktop file name.
CCBUG: 351055
Test Plan: Created a window rule for telegram-desktop to fix the icon
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11266
Summary:
The window rules dialog did not properly detect the wayland windows. So
I investigated what ICCCM writes about the WM_CLASS property (which is
the base for window rule matching) and checked how ShellClient maps to
it. Basically name and class was swapped and the reason for the
detection not working properly. As we don't have a proper name, the code
is adjusted to generate a name by using the executable name. This is
also what WM_CLASS should be filled with, according to ICCCM.
Test Plan: Rules dialog detects the name and class correctly
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11023
