This was deprecated in during the 5.24 development period. All KDE
consumers are ported away from it. Third parties will get meaningful
runtime messages which instruct them to register the plugins without keywords.
The create overloads which take keywords were already deprecated in KPluginFactory.
Currently, the invert effect doesn't work because it can't load its
fragment shader because builtin effects are static libs. We need
Q_INIT_RESOURCE() before reading shader code.
This modularizes builtin effects more, which makes easier to add and
remove builtin effects, as well as allows to have per effect resources.
Technically, changing the inner workings of the ShaderManager is an
API incompatible change, but ShaderManager::generateShaderFromResources()
can be used only by builtin effects so it's okay.
ShaderManager::generateShaderFromResources() had to be changed because
two resource files can't share the same prefix. Appending "_core" was
inspired by QtQuick.
We need CMAKE_INSTALL_FULL_LIBEXECDIR, otherwise `lib/x86_64-linux-gnu/libexec/kwin-applywindowdecoration`
will be the resulting path, which does not contains the cmake install prefix.
Consequently KNS would fail to find it at runtime.
BUG: 447284
FIXED-IN: 5.24.0
After finishing interactive resize, the window needs to be gravitated.
However, it won't be gravitated because isInteractiveMoveResize() will
return false.
In order to fix that, every configure event needs to carry the gravity,
that way the window can be gravitated even after leaving interactive
resize.
The gravity concept is a generic way to describe how a window must be
positioned during interactive resize. It works both when resizing the
window using a pointer or touch.
X11Client implicitly relied on the finishInteractiveMoveResize() function
to call moveResize() to synchronize the move resize geometry with the
server geometry. However, after removing that moveResize(), X11Client
got slightly broken.
A resize sync request may arrive shortly after finishing resize. In
order to properly handle it, this change makes X11Client handle late
sync requests.
It also makes handling interactive resize on x11 similar to how it's
done on wayland.
The main problem with not letting X11Client finish interactive resize
is that the Toplevel::bufferGeometry() may end up with an outdated value
and SurfacePixmapX11 will fail to create due to a mismatch between
Toplevel::bufferGeometry() and the server side geometry of the frame
window.
KWin loads glGetGraphicsResetStatus() on its own to handle ARB and EXT
extensions. After moving graphics reset handling to the RenderBackend,
kwin doesn't use its own glGetGraphicsResetStatus() function, but instead
uses the one provided by libepoxy, which panics if
glGetGraphicsResetStatus() is not in core spec. This change makes the
OpenGLBackend use kwin's glGetGraphicsResetStatus() function instead of
the one provided by libepoxy to avoid a crash.
This adds support for reading values from a "Libinput/Defaults" group in
the input config file. This allows specifying global defaults for
devices, that are preferred over the libinput defaults. Because of the
cascading mechanisms of KConfig, this then allows distributions and
hardware vendors to supply system-wide defaults for devices.
Rather than an awkward combination of template functions, function
pointers and multiple calls to almost-the-same-but-not-entirely
functions, make ConfigData itself a template and use type erasure to
store them in the config map. This makes the data object aware of its
type and allows us to specialise the reading of config values through
template specialisation. It also removes the need for multiple
constructors and setters in the ConfigData object.
As of now, we update cursor metadata only when the screen content changes, but
this results into not having smooth cursor movement. We can update only mouse
cursor location when it changes and send an empty buffer with mouse cursor
metadata so clients can have update mouse location.
If the first condition would match (for instance after moving a window),
`windowMove` would be `nullptr`, triggering the crash later.
By the looks of it, it was maybe a typo.
BUG: 445335
FIXED-IN: 5.24
CC: @nicolasfella
This provides a better fix for the header positioning bug in
the properties list sheet, instead of the previous workaround
(which wasn't enough in some situations)
Upstream bugfix (in the Kirigami component) is not advisable as
it could cause unintended consequencies in other uses/apps
See also: https://bugs.kde.org/show_bug.cgi?id=422289
BUG: 421583
FIXED-IN: 5.24
Currently KWin always uses the Options configured in kxkbrc because
QByteArray::constData() is never nullptr. This means that the system
default is ignored completely. Read ResetOldOptions to distinguish
between explicitly setting no options and using the system default.
After recent refactor changes to improve resizing of xdg-toplevel
surfaces with an aspect ratio, the resize effect got really broken. The
resize effect has always been a problem child on wayland.
Unlike X11, geometry updates are performed asynchronously on Wayland.
It's not possible to have a smooth transition after finishing
interactive resize from the resized state to the normal state, geometry
will jump from last moveResizeGeometry() to the current frameGeometry()
and when the client repaints the window, the window size will jump back
to the move resize geometry size. There are no ways to fix that without
contradicting to how the effect is advertised to work, e.g. sending
configure events behind the back. Keeping the frame geometry out of sync
with the xdg_surface window geometry size is also not the option,
geometry updates are already too complex (due to being async).
Another wayland related issue with the resize effect is that the
compositor doesn't know about aspect ratio or any other size
constraints, except min and max size. The client can provide a smaller
buffer to account for various geometry constraints. It will be confusing
to have a mismatch between resize outline and the final real geometry.
Aspect ratio or other geometry constraints won't be exposed to the
compositor, it's a common decision of many wayland devs (including KDE).
To some extent, the wayland issues can be addressed by performing content
updates, with active feedback, the mismatch between outline and the
final geometry would become less severe, but it won't be any different
than resizing without the effect.
Given the wayland issues and in part maintenance costs, this change
drops the resize effect. Note that it can be still reimplemented without
kwin core changes, but it would still suffer from the aforementioned
issues.
BUG: 443434
Currently the plugin needs to set a property in oder to be considered configurable.
In kpackage we have the concept of optional and required files, based on the existence of those
optional files we can define different behavior. For example in Plasma the applets can optionally have a config ui.
Because here we don not use The KPackage:Package class, it is simpler to check the existence of the files on disk.
In KWin we are allowed to break compat and here all first party consumers
have already been ported for quite a while.
Also the querying is very inefficient, because for every plugin where the
X-KDE-ConfigModule property is not defined all available KCMs have to be opened and
their metadata parsed.
This way we also get rid of the deprecation warning for KPluginMetaData::readStringList.
Doe to 1a0031c08a3b41458eb5bf2097b4cd6452ba3d09 we no longer require json metadata to be embedded.
Also we did not use the metadata anywhere, except for finding the correct plugin.
This way we do not need to embed json metadata in the plugins
and can consequently drop the metadata files entirely.
The resulting metadata object might still be invalid, however KCoreAddons
can handle such cases. See https://phabricator.kde.org/T15094 regarding
create better KCoreAddons API for such cases.
Not sure if this was left out on purpose as a kind of deprecation.
It would be necessary to allow port the tabbox switchers to the newer 3.0 API and use their components (such as `Workspace`)
Probably for `Plasma/5.25` now.
It's consistent with m_nextDecoration and m_requestedStates contains
both requested and "not requested" states (i.e. the ones set by kwin
without waiting for acknowledged from the client, e.g. activated).
