On Wayland, the move resize geometry and the frame geometry are
completely out of sync.
This change synchronizes emitting of the clientStepUserMovedResized
signal to the move resize geometry changes.
It simplifies code of InternalClient and XdgSurfaceClient, and makes
adding support for other shell surface protocols easier as there's less
boilerplate stuff that you would need to take care of.
With internal clients and xdg-shell clients, geometry updates occur in
asynchronous fashion when interactively resizing the window.
As is, performInteractiveMoveResize() will call resize() if the move
resize geometry is different from the current frame geometry. This can
result in kwin sending excessive configure events.
With this change, kwin will send less configure events during
interactive resize.
They are used only by InternalClient. AbstractClient doesn't need to
handle the destruction of DecorationBridge because its lifetime matches
kwin's lifetime.
Currently, if a window switches between SSD and CSD, it is possible to
encounter a "corrupted" state where the server-side decoration is wrapped
around the window while it still has the client-side decoration.
The xdg-decoration protocol fixes this problem by saying that decoration
updates are bound to xdg_surface configure events.
At the moment, kwin sort of applies decoration updates immediately. With
this change, decoration updates will be done according to the spec.
If the compositor wants to create a decoration, it will send a configure
event and apply the decoration when the configure event is acked by the
client. In order to send the configure event with a good window geometry
size, kwin will create the decoration to query the border size but not
assign it to the client yet. As is, KDecoration api doesn't make
querying the border size ahead of time easy. The decoration plugin can
assign arbitrary border sizes to windows as it pleases it. We could change
that, but it effectively means starting KDecoration3 and setting existing
window deco ecosystem around kwin on fire the second time, that's off the
table.
If the compositor wants to remove the decoration, it will send a
configure event. When the configure event is acked and the surface is
committed, the window decoration will be destroyed.
Sync'ing decoration updates to configure events ensures that we cannot
end up with having both client-side and server-side decoration. It also
helps us to fix a bunch of geometry related issues caused by creating
and destroying the decoration without any surface buffer attached yet.
BUG: 445259
move() and resize() functions are not convenience helpers around the
moveResize() function. They communicate what kwin wants to see after the
corresponding change is applied. It's needed to make asynchronous
geometry updates work.
This change replaces a moveResize() during XdgToplevelClient
initialization with explicit move() and resize() function calls instead,
so it's more clear what the expected end result is.
Currently, the wayland server updates the server side decoration mode,
which is counter-intuitive, because it doesn't cache the last preferred mode.
With ServerSideDecorationInterface::preferredMode(), it can be simpler.
If a window wants to be initially shown in fullscreen mode, it will
issue an xdg_toplevel.set_fullscreen request before the first surface
commit.
If a window wants to be shown in fullscreen mode and there hasn't been
any first surface commit, kwin will cache the request and apply
fullscreen mode when checking window rules in the initialize() function.
On the other hand, window rules are disabled for plasma surfaces. The
motivation behind that was to forbid user from messing with plasma's
surfaces (this change was suggested during redesign of xdg-shell
implementation).
As it turns out, there are cases where plasma may ask to show a window
in fullscreen mode, which also has a plasma surface installed, e.g.
fullscreen application dashboard.
In order to fix the dashboard, this change allows window rules to be
applied to xdg-toplevel windows that also have plasma surfaces installed.
As is, xdg-toplevel surfaces and plasma surfaces are very different in
nature. Adding more quirks to handle plasma surfaces in
XdgToplevelClient is not worth the effort and there are better
alternatives, e.g. layer-shell.
Like top level clients, apply plasmashell roles to popups as well (limiting them, don't allow dock or desktop roles in poups as they don't make sense)
This makes possible to recognize plasma tooltips as tooltips, treating them in a way closer to X, and makes morphingpopups work on wayland
This ensures that the window will have correct geometry if a maximized
window changes preferred decoration mode. X11Client does something
similar, see X11Client::updateShape().
In hindsight, perhaps, AbstractClient::{create,destroy}Decoration() must
preserve the old frame geometry, but it's not clear how to do that
because it requires decoration updates to be truly async, otherwise
there will be ugly flickering.
Currently, AbstractClient::geometryRestore() is abused to put windows
back on their original screen. It makes window placement more complex
and it breaks restoring initially maximized windows.
Conceptually, a configure event inherits its parent's state and adds
some of its own. This allows the compositor to skip intermediate
configure events in ack_configure handler and jump to the last one.
Currently, the only field that XdgSurfaceConfigure objects need to
inherit is flags. The geometry info and window states are filled in by
role commit implementations to their latest values.
XdgSurfaceConfigure::flags indicates if the configure event moves the
window. This flag is important to resolve conflicts between geometry
updates initiated by the user and the ones that are made in response to
acknowledged configure events, e.g. after maximizing the window, etc.
(effectively, if the user moves a window, kwin will cancel scheduled
moves in configure events)
If configure flags are not inherited, we can end up with the following
case:
* configure event A (flags: {position})
* configure event B (flags: {})
If the client acknowledges configure event B, kwin will skip configure
event A, and thus it won't move the window to the right place. This is
the root cause of fullscreen mode misbehaving with apps such as google
chrome.
The check for this rule was missing on window initialization,
so on Wayland it wasn't being applied until something would
trigger the check again.
BUG: 429171
FIXED-IN: 5.22.90
Originally, there was ShellClient class that was the predecessor to
WaylandClient subclasses. If the main surface is unmapped, the
corresponding instance of ShellClient would be kept around. That had
been changed with the introduction of XdgToplevelClient and
XdgPopupClient.
Since ShellClient had been kept alive even if the corresponding surface
were unmapped, it did make sense to setup window management integration
when the surface is mapped.
However, this also means that plasma will not know about initially
minimized windows.
Since unmapped windows are handled differently now, we can setup window
management after the client performs the initial commit. If the main
surface is unmapped, the XdgToplevelClient object will be destroyed and
with it, the window management integration.
Due to the screen edges test not being an integration test, it's very
hard to change output related code in libkwin. screens.cpp needs to have
a few ifdefs to successfully compile.
This change rewrites the screen edges test as an integration test in
order to allow us using other components of kwin in screens.cpp and
screenedge.cpp without ifdef guards.
It's not a one-to-one port.
Active output is a window management concept. It indicates what output
new windows have to be placed on if they have no output hint. So
Workspace seems to be a better place for it than the Screens class, which
is obsolete.
This is a little helper that can be very convenient with our transition
from int-based screen ids to AbstractOutput.
As is, the main issue with int screen ids is that they are extremely
dynamic.
With AbstractOutput being used more heavily, it makes sense to have
something like Screens::number() in the Platform class. As is, the steps
to get an output for a given point are awkward - first, get the screen
id, then use the screen id to get the output.
The new overloads take the client (as context) and the desired screen id
or a point and return the client area.
The main motivation behind this change is to make the transition to the
new virtual desktop model where a window can be on several desktops less
painful.
This ports relevant apis in WindowRules to the VirtualDesktop class.
If the client has no desktop rule, the desktop list that has been passed
to the checkDesktops() function will be returned.
If the client has a desktop window rule, the checkDesktop() function
will return a list with a single VirtualDesktop object or none if the
window is forced to be on all virtual desktops.
The main motivation behind this change is to reduce the number of usages
of int-based virtual desktop apis. int-based desktop ids are highly
unreliable. For example, if a new virtual desktop is inserted in the
middle or removed in the middle, the desktop ids will change. This makes
working with virtual desktops code more challenging due to its behavior.
This is not an issue with VirtualDesktop objects.
toplevel.h is included in many places. Changing virtualdesktops.h may
trigger rebuild of all kwin.
With this change, only cpp files that use virtualdesktops.h will need to
be recompiled.
This ensures that surface role objects can be still accessed when either
XdgToplevelClient or XdgPopupClient is destroyed. As far as I know, it
doesn't cause any problems right now, but this makes resource destruction
handling consistent, we tend to perform cleanup in aboutToBeDestroyed
signal slots.
The main motivation behind the split is to simplify client buffer code
and allow adding new features easier, for example referencing the shm
pool when a shm buffer is destroyed, or monitoring for readable linux
dmabuf file descriptors, etc.
Also, a referenced ClientBuffer cannot be destroyed, unlike the old
BufferInterface.
If the client had created an xdg-toplevel-decoration and has called the
set_mode() request with csd before the initial configure event is sent,
we still need to send an xdg-toplevel-decoration configure event with
csd mode.
Window management features were written with synchronous geometry
updates in mind. Currently, this poses a big problem on Wayland because
geometry updates are done in asynchronous fashion there.
At the moment, geometry is updated in a so called pseudo-asynchronous
fashion, meaning that the frame geometry will be reset to the old value
once geometry updates are unblocked. The main drawback of this approach
is that it is too error prone, the data flow is hard to comprehend, etc.
It is worth noting that there is already a machinery to perform async
geometry which is used during interactive move/resize operations.
This change extends the move/resize geometry usage beyond interactive
move/resize to make asynchronous geometry updates less error prone and
easier to comprehend.
With the proposed solution, all geometry updates must be done on the
move/resize geometry first. After that, the new geometry is passed on to
the Client-specific implementation of moveResizeInternal().
To be more specific, the frameGeometry() returns the current frame
geometry, it is primarily useful only to the scene. If you want to move
or resize a window, you need to use moveResizeGeometry() because it
corresponds to the last requested frame geometry.
It is worth noting that the moveResizeGeometry() returns the desired
bounding geometry. The client may commit the xdg_toplevel surface with a
slightly smaller window geometry, for example to enforce a specific
aspect ratio. The client is not allowed to resize beyond the size as
indicated in moveResizeGeometry().
The data flow is very simple: moveResize() updates the move/resize
geometry and calls the client-specific implementation of the
moveResizeInternal() method. Based on whether a configure event is
needed, moveResizeInternal() will update the frameGeometry() either
immediately or after the client commits a new buffer.
Unfortunately, both the compositor and xdg-shell clients try to update
the window geometry. It means that it's possible to have conflicts
between the two. With this change, the compositor's move resize geometry
will be synced only if there are no pending configure events, meaning
that the user doesn't try to resize the window.
This is to improve code readability and make it easier to differentiate
between methods that are used during interactive move-resize and normal
move-resize methods in the future.
We need to emit the clientFinishUserMovedResized signal to notify
effects such as translucency that the interactive move-resize is
finished. Otherwise, the set() animation won't be cancelled and the
window will get stuck frozen.
BUG: 409376
This reverts commit 110182b213.
The reverted commit has introduced a regression where interactively
moved windows jump back to their old position. This needs some time for
proper investigation. Due to beta rolling out quite soon, it will be
better to revert the change.
Rather than have an error prone way to detect whether a configure event
has good position information, handle the case where the plasma shell
surface has a position hint explicitly.
When the maximize mode changes from MaximizeFull to either
MaximizeHorizontal or MaximizeVertical, (max_mode & MaximizeFull) will
evaluate to true because MaximizeFull is defined as bitwise OR between
MaximizeHorizontal and MaximizeVertical.
Currently, the fullscreen state is update synchronously, but it needs to
be done in asynchronous fashion.
This change removes some tests as they don't add any value, testFullscreen()
covers them all.
