Linking builtin effects against KCMs is really awkward. This change
decouples builtin effects from KCMs that use EffectsModel.
In order to discover builtin effects, metadata files are installed in
kwin's data dir, which will be subsequently read by EffectsModel.
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.
As is, libkwineffects doesn't use any specific apis in kwayland-server,
it simply "forwards" wayland display and surfaces from libkwin. Given
that, there is no need to link libkwineffects with kwayland-server. If
an effect needs to access wayland specific stuff, it can link explicitly
against kwayland-server.
The main motivation behind this change is to further loosen up
dependencies between various kwin components and kwayland-server so the
latter can be moved back to kwin.
Before attempting to create scenes, kwin will redirect windows but if
the opengl scene can't be created, it won't unredirect windows, which
seems to cause issues on aarch64.
BUG: 443953
API-wise it's odd to require absolute position with relative pointer
moves.
This cleans up some of InputRedirection code by making it simply forward
pointer input events from input devices to the pointer input device
handler, which knows better what to do with the delta value.
The pointer input device handler will compute the absolute position based
on the specified delta value, but it could also do something else, e.g.
not move the pointer at all if it's locked, etc.
When geometry updates are blocked, the output doesn't get updated. This
breaks Workspace::clientArea() overload that takes only the window.
Previously, clientArea() would look up the output where the window is
every time it's called, so the fact that the screen id or AbstractOutput
is unsynchronized with the frame geometry was irrelevant.
This change restores the old behavior as 5.23 is affected by the
output() being out of sync with the frameGeometry(). Specifically, when
kwin starts managing an X11 window, it will block geometry updates,
setup the window, e.g. make it fullscreen, and unblock geometry updates.
Since Workspace::clientArea(clientArea, Toplevel) uses the output(),
X11Client::setFullScreen() will most likely put the X11 window at a
wrong output if it's called inside X11Client::manage().
BUG: 443787
AbstractEglBackend includes option.h, which includes main.h, which
includes QApplication. Since SceneOpenGLBackend doesn't link against
Qt::Widgets, kwin fails to build on Gentoo, but not on other distros
for some reason...
Abstract clients tolerate passing the shaded window geometry to
moveResize().
But the main issue with applyWindowRules() is that it uses the current
frame geometry even though it calls moveResize(). It's not a big deal
but it's error prone.
This change ports applyWindowRules() to the move resize geometry, which
makes code more straightforward and ensures that kwin uses right
geometry type with moveResize().
X11Client tolerates passing shaded geometry to moveResize() and in many
cases kwin already does that.
Another issue is that this doesn't align well with new async geometry
handling abstractions. pos() can't be used because it corresponds to the
current frame position.
We can safely pass the last move resize geometry. It simplifies code a
bit and makes sure that everything works as expected with the move
resize geometry.
Currently, adjustedSize() does two things - it computes and constrains
the natural size of the window.
In many places where adjustedSize() is used, the natural size doesn't
need to be constrained and in some it's actually undesired because
AbstractClient::constrainClientSize() doesn't allow the client size to
be 0x0, which can happen when dealing with a client that has no buffer
committed yet.
This change replaces adjustedSize() with implicitSize(), which simply
calculates the natural frame size based on the current client size.
If the frame size needs to be constrained, for example during
interactive move-resize, use constrainFrameSize() or if you need to
constrain the client size - constrainClientSize().
Trying to reconstrain the geometry after applying rules is unnecessary
because if the geometry is forced using a rule, resizeWithChecks()
should not change it; if the window is maximized or has entered fullscreen
mode, window gravity is irrelevant. If the window is shaded, this
resizeWithChecks() is not needed.
This change simplifies AbstractClient::applyWindowRules(), which allows
to split adjustedSize() to further simplify geometry handling.
Prefer hiding/showing the panel (i.e. the window) when not a touch event
than stopping to make the inputmethod active.
This way we remain compatible with non-virtualkeyboard inputmethods.
The bounding rect of an item is in the item-local coordinate space. If
the item is moved, its bounding rect won't change, but the parent's
bounding rect, may change.
BUG: 443756
AbstractClient::constrainClientSize() forces the minimum client size of
1x1.
If AbstractClient::adjustedSize() is called before the XdgToplevelClient
is mapped, it will return 1x1 rather than 0x0 as expected, which will
confuse
QSize s = adjustedSize();
if (s != size() && s.isValid())
resizeWithChecks(s);
in AbstractClient::applyWindowRules(). Since 1x1 is different from 0x0,
the xdg-toplevel surface is going to be resized to 1x1.
BUG: 443705
Whether relative pointers are supported doesn't depend on the input
backend. This change moves the instantiation of the extension to the
WaylandServer class to make code more consistent.
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)
Currently, cpp source files are included partially in effect sub-folders
and src/effects/CMakeLists.txt, which is really confusing and hard to
follow.
With this change, effect targets will be defined in their own subfolders.
This makes build files more straightforward.
Effect sub-targets are eventually merged into a monolithic
kwin4_effect_builtins target.
Another reason for modularizing builtin effects is that no two effects
can generate moc files with the same name atm even though they are in
different sub-folders. This can be potentially useful in the future, e.g.
making effects static plugins in order to decouple builtin effects from
libkwin (every effect subfolder would need a main.cpp or plugin.cpp file,
which will include the associated moc file).
The GLTexture class is forward declared and the ShowFpsEffect class has
a QScopedPointer<GLTexture> field. We either need to include the
kwinglutils.h header file or add a destructor that does nothing and
define it in the cpp file, where kwinglutils.h is included.
At the moment we'll be setting the YInverted setting, but in practice
that won't have any effect as it only changes the render matrix and
we'll end up streaming inverted textures.
This change addresses it by rendering it into another texture first to
resolve this situation and then download that new texture instead.
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.
With lv3:ralt_alt ("Right Alt never chooses 3rd level") option set, we
get more layouts from libxkbcommon than it was configured, see:
https://github.com/xkbcommon/libxkbcommon/issues/262
It might be correct lib's behavior, still.
The extra layouts are redundant, so we strip them out from usual usage.
BUG: 440027
