If there's only one configure event that changes the position of the
window and it gets acknowledged but no buffer is attached yet, and a new
configure is sent, then the ConfigurePosition flag won't be inherited
by the new configure event and the window will be misplaced.
In order to fix that, this change makes XdgSurfaceClient pop the last
acknowledged configure event from the m_configureEvents list only when
it's about to be applied for sure.
BUG: 448856
Historically, noBorder() was used for two things:
* as a substitute for AbstractClient::isDecorated()
* to determine whether the AbstractClient should have a decoration
With async decoration updates refactoring, a few things around
noBorder() have changed, which exposed an existing bug in the handling
of borderless maximized windows.
It's possible to have a case where an initially maximized window makes
an xdg_toplevel.set_maximized request before the initial commit, but
creates the decoration object after the initial commit.
Since XdgToplevelClient::userCanSetNoBorder() would return false when
maximize() is called in XdgToplevelClient::initialize(), m_userNoBorder
won't be updated and therefore the window can end up having a server
side decoration.
Previously, it wasn't the case because kwin would do nothing if the
decoration is installed and its preferred mode changes after the initial
commit but before the surface is mapped. With async decoration fixes,
kwin would react as expected, which unfortunately has exposed the bug.
The root cause of the problem is the fact that noBorder() is overloaded,
which makes it error-prone.
This patch changes how the noBorder property is treated. Now, it only
indicates whether the compositor wants the window to have no borders. If
noBorder() is true, it means that the compositor doesn't want the window
to have a server-side decoration; on the other hand, if noBorder() is
false, it doesn't imply that the window should have a decoration.
BUG: 448740
geometryRestore() is no longer updated after mapping the window, so
setQuickTileMode() has to update geometryRestore() explicitly to the
correct value.
With this change, geometryRestore() will be updated as follows:
* if the window is tiled, geometryRestore() is valid, nothing to do
* the window has been dragged to the top edge, set geometryRestore() to
the geometry that the window had when starting move
* otherwise, use the current move resize geometry
dontInteractiveMoveResize() was added to workaround kwin sending bad
configure events when double clicking mpv to make it fullscreen.
With async geometry updates fixed, dontInteractiveMoveResize() can be
finally removed.
Another reason to remove dontInteractiveMoveResize() is that it can make
kwin crash with a debug build. For example, if you enable resizing
maximized windows in breeze decoration settings and resize a maximized
window, kwin would eventually crash in
the AbstractClient::handleInteractiveMoveResize() function because neither
isInteractiveMove() nor isInteractiveResize() return true.
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.
It's not practical, regular users don't care about window geometry. One
could argue that it can be useful for creating window rules, but window
rules kcm pulls relevant properties from kwin.
If needed, one can reimplement this feature as a QtQuick script that creates
an overlay window positioned above the window that is being interactively
moved or resized.
Same as real hardware wl_keyboard, key should be sent before modifier
change. For example, Left Ctrl press and release should produce
key events in the order of Control_L and Control+Control_L.
Observed in kdevelop, that isEnabled() could be false when switching
between different tabs with Ctrl+Tab. But Qt may still call show()
if you click on the texteditor widget. This leads to isEnabled == false but
setActive(true) is called. This causes kdevelop in a usable state because
keyboard grab will be created and no key event will reach application
because isEnabled == false. Under normal circumstances, key will reach
widget first and triggers another text_input_v2 enable to make input
method work properly.
text-input-v3 does not have preedit styling, instead, it can only
specify the range of cursor. Try to keep track of any
highlight/selection style range and combine them together. If it matches
the cursor position, use it as the cursor range.
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
The output management test checks the implementation of output
management capabilities in the virtual backend, which is not helpful.
This change replaces it with a more useful test that verifies how
windows are placed after an output change.
TestXdgShellClientRules implicitly assumes that the kwinrc config is
referenced only by the RuleBook object.
However, after changing the default placement policy in the
WaylandTestApplication, that's no longer the case. The kwinApp() object
now also holds a reference to the main config file. Because of that,
previous window rules leak to next tests, which breaks them.
In order to address that issue, this change makes TestXdgShellClientRules
open a separate config and wipe it clean after each test run. Not great,
but there doesn't seem to be other way around with current KSharedConfig
api.
It's more common to see the parent object being the last argument in Qt
and this way you won't need to specify nullptr parent explicitly if the
xdg-popup or the xdg-toplevel surface doesn't need to be configured
implicitly, which makes tests slightly easier to read.
Effect loading is already tested using integration tests, for example
the maximize test verifies that the maximize effect is loaded _and_ it
actually does something useful when a window is maximized or restored,
testScriptedEffectLoader only verifies that the effect is loaded, which
is less helpful than what integration tests provide us.
But perhaps the main problem with these tests is that they require us
building a mockverse around them. This litters code with ifdef
preprocessor directives and makes changing such code a living nightmare.
Another problem with these two tests is that they cannot use OpenGL
because it means mocking OpenGL, which we obviously not going to do.
With integration tests, it's not a problem.
The bottom line is that unit tests can be useful but they make life
notoriously difficult when it comes to testing components that depend on
other components.
Currently, kwin expects that the xdg-decoration is installed before the
initial commit. However, decoration tests do that after the initial
commit, which makes testMaximizeAndChangeDecorationModeAfterInitialCommit()
silently pass.
On a second look, it seems that the xdg-decoration spec is okay with the
xdg-decoration being created after the first commit (as long as it's
done before the surface is mapped). This needs to be fixed separately.
CCBUG: 445259
If the preferred decoration mode changes after the initial commit but
before the surface is mapped, there's a chance that kwin can send a bad
configure event, it's been the case in the past. Add a test to prevent
such cases go unnoticed.
If the decoration is destroyed before the window is mapped, kwin can
respond with a configure event that has 0x0 size. New tests check that
problematic case.
BUG: 444962
Ever since the effects were changed to static, each test of the
integration tests includes all the effects. The result of this is that
when doing a debug build each test is now 60MiB or more. With the amount
of tests, this results in ~8 GiB of diskspace used just for KWin's
binary output directory, which is rather excessive.
Since the tests all share a common framework library, we can change that
library to a shared library and that way avoid linking all the effects
into each test.
Most of this is shuffling around some link libraries in the integration
test CMakeLists, however, I needed to export the Xwayland class as it is
used by one of the tests but wasn't exported.
EffectQuickScene is not used strictly by effects, aurorae decorations
use it too to render window decorations.
This change renames the EffectQuickView/Scene to
OffscreenQuickView/Scene to clear up the naming scheme.
Since binary effects are installed in their own directory, checking
service type is redundant. Also, KPluginMetaData::serviceTypes() has
been deprecated.
Task: https://phabricator.kde.org/T14483
The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
The main idea behind the render backend is to decouple low level bits
from scenes. The end goal is to make the render backend provide render
targets where the scene can render.
Design-wise, such a split is more flexible than the current state, for
example we could start experimenting with using qtquick (assuming that
the legacy scene is properly encapsulated) or creating multiple scenes,
for example for each output layer, etc.
So far, the RenderBackend class only contains one getter, more stuff will
be moved from the Scene as it makes sense.
This improves file organization in kwin by putting backends in a single
directory.
It also makes easier to discover kwin's low level components for new
contributors because the plugins directory may come as the last place to
look for. When one hears "plugin", the first thing that comes to mind is
regular plugins, not low level backends.
The main motivation behind this change is to prepare input abstractions
for virtual input devices so the wl_seat can properly advertise caps or
the cursor getting properly mapped/unmapped when a fake pointer is
added/removed on a system without a hardware mouse connected.
With this, there are three abstractions - InputDevice, InputBackend, and
InputRedirection.
An InputDevice represents an input device such as a mouse, a keyboard, a
tablet, etc. The InputBackend class notifies the InputRedirection about
(dis-)connected devices. The InputRedirection manages the input devices.
Such design allows to unify the event flow for real and virtual input
devices.
There can be several input backends active. For example, the libinput
backend and an input backend that provides virtual input devices, e.g.
libeis or org_kde_kwin_fake_input.
The screen count can be retrieved by checking the number of items in the
EffectHandler.screens property.
The replacement for the numberScreensChanged signal are the screenAdded
and the screenRemoved signals.
The main motivation behind this change is to clean up the screens api
and reduce the number of usages of the Screens class.
The main motivation behind this change is to prepare kwin for importing
kwayland-server code in libkwin.
As is, builtin effects are linked with libkwin. Some builtin effects
have wayland specific code. If we move wayland stuff in libkwin, there's
going to be a circular dependency between kwin4_effect_builtins and
libkwin targets.
This change intends to break that dependency by linking builtin effects
to kwin executable.
The main issue with that is that EffectLoader would need to discover the
effects indirectly. QStaticPlugin is used for that purpose.
Besides breaking the cyclic dependency, it makes builtin effects use the
same plugin infrastructure in libkwineffects that external effects use.
Metadata in src/effects/effect_builtins.cpp was converted in a list of
python dictionaries, which was fed to a python script that generated
main.cpp and metadata.json files.
With the LEDs enum being defined in kwinglobals.h, wayland_server.h
won't need to include keyboard_input.h, which is good for compilation
times and wayland_server.h will drag less stuff, e.g. QtWidgets (input.h
includes QAction)
The English word "pack" is not really the correct word for these
actions, and does not succeed in communicating what they will do. Since
the actions simply move the active window as far as it will go in the
specified direction, the actions can be renamed to say that instead.
Also rename the action names in the code to match their new UI text for
clarity.
This change merges the two OpenGL backends into one making the current
default of GLCore the overall default. It becomes the first context to
try to create. If it fails, it will automatically fall back to the
(previous) OpenGL 2 backend.
Reasoning: the differentiation of OpenGL 2 and 3 is a very technical one
and hard to understand for users. It is not obvious which one is better
or should be used. This results in many user discussions like "Which
backend to use?"
Back when the OpenGL 3 backend was introduced the dedicated feature made
sense. It was a new code base using new driver features. Nowadays the
code base in KWin is robust and mature and so are the drivers. A driver
advertising support for OpenGL 3 will support OpenGL 3. We don't have to
plan for driver breakage in this area any more.
Also our code evolved through the context attribute builder which gives
us the possibility to more easily fall back in case we cannot create the
context. Thus the need to select the backend is not so important as it
used to be when the feature got introduced.
If a user still wants to force OpenGL2, it is still possible by setting
the appropriate environment variables like MESA_GL_VERSION_OVERRIDE.
This change brings the improvement that the backend selection is now
completely removed from the compositing KCM.
FAIL! : TestXdgShellClientRules::testSizeApply() 'surfaceConfigureRequestedSpy->wait(10)' returned FALSE. ()
Loc: [/home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.15/autotests/integration/xdgshellclient_rules_test.cpp(731)]
If CI is moderately loaded, 10ms may not be enough. I don't remember why
10ms timeout was added.
Currently, testXdgWindowReactive() is a bit flaky because the parent
window and the popup window are created together. The popup can be
configured again if its global position changes after the parent window
has been placed.
In order to stabilize the test, create the parent window, then the popup
window.
Startup code in plasmashell was changed so xsetroot is not called
anymore, which is sort of fine.
Unfortunately (or not?), it exposed a bug in kwin. Cursor::x11Cursor()
only works in the standalone X11 session.
On Wayland, Cursor::x11Cursor() will return XCB_NONE which results in
seeing cross cursor when there should be arrow cursor.
This change moves xcb_cursor_t look up code from X11Cursor to the base
Cursor class. In hindsight, I would like to introduce a window manager
class where the xcb cursor and other x11 specific code can be moved in
the future for better encapsulation of platform-specific code.
CCBUG: 442539
The current code set m_pasteProcess to null, before running the cleanup
function which tells the process to quit.
Which is why it always hung the CI. This patch addresses it in a way
that cleans up helpers even if we abort the test early.
With a "Surface" type in kwin, KWayland::Client::Surface without fully
specified namespace will conflict with kwin's Surface type.
In some way, it also improves readability as it's clear where Surface
comes from.
Port the RuleSettings and KCM to store and use a list of virtual desktop
UUIDs, instead of the previous x11 positional id, continuing the work on
This allows to set a rule with several desktops on Wayland.
On X11 it has no visible change for the user, but internally it uses the
more modern concept, helping to simplify the related code.
The relevant key on kwinrulesrc changes from `desktop` to `desktops`.
A kconf_update script handles the migration.
This lays down some groundwork for realtime gestures in Wayland,
so that gestures that are 1:1 with user motion on a touchpad are
now possible to implement.
Due to earlier commits, this is mostly just glue code to make a
convenient API.
Gestures implemented with this API are four-finger gestures, to
avoid conflicting with apps that may use two or three-finger
gestures.
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 effect is meant to be as a replacement for the present windows and
the desktop grid effect. It is written using QML.
So far, this effect implements only the basic features of the present
windows effect. Desktop management features will be added later.
CCBUG: 295775
CCBUG: 303438
This patch has one behavioral change - raiseOrLowerClient() will not
work if the client is not on the current virtual desktop.
However, raiseOrLowerClient() can be called only in two cases:
* user triggers the raise or lower shortcut for the active client. Since
the active client is on the current virtual desktop, it's not an issue
* an x11 window restacks itself. It makes no sense if an x11 window
restacks itself while it's inactive or not on current virtual desktop.
Also, the Opposite restack mode is rarely used, some window managers
don't even bother implementing it. So, having such a constraint should
not be a problem.
The main reason for not allowing raiseOrLowerClient() for windows that
are not on the current virtual desktop is that a window can be on
multiple virtual desktops. If a window is on A and B virtual desktops,
the only logical option is to toggle stacking position if the window is
on the current desktop. It's the only viable option as kwin does not
maintain per virtual desktop stacking order.
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.
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.
Since we adapted inputmethod to support methods like ibus, the input
method can be active but not have a visible panel.
This includes an extra property that will indicate us if the panel is
visible at any time. This will allow us to properly render the virtual
keyboard hide button in Plasma Mobile (or wherever we need it).
So far calling setActive(true) would issue a deactivation then another
activation. This sometimes makes maliit crash and we can achieve the
same result just by just issuing a reset.
It's unused and the advantages of keeping it are outweighed by the
disadvantages - the returned value is dependant on the window type.
If you need to draw a drop-shadow that matches the shape of the window
or something along that line, render the window into an offscreen
texture and sample the alpha channel in a fragment shader.
The looking glass effect creates an opengl texture at load time without
a current context, which aborts the test.
The test should be converted into an integration test. Mocking the GL
library is simply not feasible and not worth the trouble. :/
It is error-prone to have multiple sources for the same data. If the
base implementation (Compositor::compositing()) changes, other helpers
can get out of sync.
At the moment, the test depends on the implicit client connection flush
in BufferInterface::unref(). It will be highly desirable if that connection
flush is gone as it allows us batching wayland events better. It also
allows us remove a system call from a hot path.
At the moment, we handle window quads inefficiently. Window quads from
all items are merged into a single list just to be broken up again.
This change removes window quads from libkwineffects. This allows us to
handle window quads efficiently. Furthermore, we could optimize methods
such as WindowVertex::left() and so on. KWin spends reasonable amount
of time in those methods when many windows have to be composited.
It's a necessary prerequisite for making wl_surface painting code role
agnostic.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
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
The order in which Xwayland surfaces are associated with X11 windows is
undefined, meaning that we cannot assume that a newly created X11 window
won't have a surface associated with it already.
On X11, the lockscreen greeter is an override-redirect window so the
scale and the glide effect ignore it.
On Wayland, the lockscreen greeter is a regular window so both effects
try to animate it upon the screen being unlocked, which looks bad.
This reduces the number of usages of xStackingOrder(), which simplifies
the reasoning about when it can be marked as dirty.
Since internal windows are now in the regular stack, InternalWindowTest
can use stackingOrder().
As for X11ClientTest, there's no specific reason why it uses the x stack
instead of the regular one.
We need to make sure that the information from
toplevelConfigureRequestedSpy is in place to be used, otherwise we get
an empty size and it doesn't work.
We were expecting a tooltip to be closed when clicking its
transientParent, but it's explicitly not something we are after. We
close popups when we click either other clients or the actual client on
the decoration.
This change makes it so we end up clicking another window instead of the
parent one that is unrelated.
When debugging modifier_only_shortcut_test in _waylandonly mode I saw
that it was failing, among other things, because some aspects were not
initialised.
This changes every test we have to run the new
Test::initWaylandWorkspace() that calls waylandServer()->initWorkspace()
but also makes sure that WaylandServer::initialized is emitted before we
proceed.
Starting with 48c3376927e5e9c13377bf3cfc8b0c411783e7f3 in kglobalaccel,
KGlobalAccel won't work in desktop environments other than Plasma.
We need to set XDG_CURRENT_DESKTOP=KDE to ensure that global shortcuts
still work.
