The plugin does not much. It's the most basic plugin we can have to
be loaded from kwin_x11.
Unlike the wayland platform plugins it gets installed to:
org.kde.kwin.platforms
Summary:
Source code reorganization:
The base class AbstractBackend got renamed to Platform, thus the
"backends" are "platforms" now. As they are plugins they should go
together with other KWin plugins which are nowadays in the folder
plugins.
So new location is plugins/platforms/
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1353
Summary:
It looks like something was forgotten here - there is
a completely empty body for an if statement that checks
whether the pointer is null.
So this might not be the desired way to fix this.
Should m_lastCreatedSettings be instantiated instead?
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1348
Summary:
It can be null even after updateTextTexture() if there is not text
to generate the texture from:
if (m_effectFrame->text().isEmpty())
return;
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1347
Summary:
From the rest of this method, it is obvious that m_topLevel can
be null in any part of the method - we are checking against it
being null in a few places in the method - both before and after
the affending lines.
Now, there is one place where the check is not applied, and
potentially calls ->window() on the null pointer.
p.s. If there are more places where kwin does clear_or_something(); return;
it could benefit from introducing on_scope_exit and similar tricks - see
Alexandrescu's 'Declarative control flow' presentation.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1346
Summary:
This is the first change in a refactoring series. The aim is to:
* rename AbstractBackend to Platform
* move backends/ to plugins/platforms/
* don't bind platforms to Wayland only
* provide a platform plugin for "normal" X11
* share more code between X11 and Wayland
This change moves the platform/backend from waylandServer to Application.
The init of the plugin happens directly in the Application from the
KPluginMetaData. There is no need to externally init it and set the
parent.
WaylandServer::backend() currently just delegates to
kwinApp()->platform(), the idea is to drop this method completely.
The test infrastructure is also adjusted to this change.
Test Plan: kwin_wayland still works, all tests pass
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1331
This is more a hack than an actual implementation. It just renders
all sub-surfaces after the main window got rendered. But it does not:
* use window quads (e.g. splitting not supported)
* is not combined with rendering of the main surface
* does not support previous pixmap
Still it renders, which is the main goal at the moment.
The rendering is done in a recursive way. For updating the buffer an
important change is done: the buffer is copied into a new QImage on each
change and the differences are no longer painted. This is due to damage
region in a sub-surface tree being basically unknown.
This change introduces a tree for WindowPixmap. A WindowPixmap can
have a parent WindowPixmap and children. Each child represents a
SubSurface and references the buffer of that SubSurface.
The tree of WindowPixmaps is updated each time updateBuffer is called.
If there are new SubSurfaces new WindowPixmaps are created, for removed
SubSurfaces the old WindowPixmap gets removed. Also the ordering is
updated to reflect the current state.
This is currently rather expensive and should be changed to only rebuild
the tree if it actually changed.
Searching for "animation speed" now points to the Compositing KCM, where
the animation speed setting is, instead of the Destkop Effects KCM,
where it was before.
Same for compositing, OpenGL, XRender and video settings
BUG: 361436
FIXED-IN: 5.7
Differential Revision: https://phabricator.kde.org/D1326
On build.kde.org we cannot use the breeze cursor theme. Instead we have
DMZ-White (debian package dmz-cursor-theme).
This change adjusts the PointerInput test to enforce DMZ-White and uses
SizeAllCursor instead of OpenHandCursor as that one seems to be missing
in that theme.
Hopefully with these changes the test starts to pass on build.kde.org.
Summary: Replaces the custom logic to switch between the three modes by tabs.
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: mart, plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1271
Summary: Replaces the custom logic to switch between the three modes by tabs.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1271
Summary: Inspired by xev a new tool which prints out all input events.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1264
Summary:
This reverts commit 14d1fdf63f.
The zoom effect is definitely the wrong way, it's broken (can be
triggered without moving the mouse, expands windows outside of their
allotted area (looks like broken sizing/placement), isn't animated so
feels very choppy, isn't using well-known highlight semantics), the
result is that it feels unnatural and jarring. To be honest, when I
looked at it, I was looking for a bug in the code, e.g. margins not
being taken into account. It didn't come up in me that this could be
wanted behavior, until I read the code.
As to the original commit message: The highlight is useless for this
case, as any window can be dragged or activated, highlighted or not.
What *could* work is to somehow intensify the colors, but that again
would have to be animated, and play well with the ongoing desktop-zoom
animation, the mouse pointer location changes relative to the window, so
it's really complex to get right. I thought of this for a while, I don't
think the complexity that has to be implemented is worth the benefit,
because, what does highlighted really mean here? "window is under the
mouse" isn't a useful metric, as we don't know if the user is changing
desktops or rearranging windows, and "window under mouse" changes
depending on the zoom level, "window can be dragged or activated" also
isn't a useful metric, as I can do that with any window, anyway.
Test Plan: Tested with patch applied, desktopgrid windows don't jump around anymore.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1209
Summary:
This reverts commit 14d1fdf63f.
The zoom effect is definitely the wrong way, it's broken (can be
triggered without moving the mouse, expands windows outside of their
allotted area (looks like broken sizing/placement), isn't animated so
feels very choppy, isn't using well-known highlight semantics), the
result is that it feels unnatural and jarring. To be honest, when I
looked at it, I was looking for a bug in the code, e.g. margins not
being taken into account. It didn't come up in me that this could be
wanted behavior, until I read the code.
As to the original commit message: The highlight is useless for this
case, as any window can be dragged or activated, highlighted or not.
What *could* work is to somehow intensify the colors, but that again
would have to be animated, and play well with the ongoing desktop-zoom
animation, the mouse pointer location changes relative to the window, so
it's really complex to get right. I thought of this for a while, I don't
think the complexity that has to be implemented is worth the benefit,
because, what does highlighted really mean here? "window is under the
mouse" isn't a useful metric, as we don't know if the user is changing
desktops or rearranging windows, and "window under mouse" changes
depending on the zoom level, "window can be dragged or activated" also
isn't a useful metric, as I can do that with any window, anyway.
Test Plan: Tested with patch applied, desktopgrid windows don't jump around anymore.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1209
Summary:
While developing support for sub-surfaces it became obvious that there
is a need for visualizing the tree of sub-surfaces.
The surface-tree is a new mode added in the debug console. There are now
two buttons to switch between the default window tree and the surface
tree.
The surface tree is a little bit more basic than the windows tree. The
type of window (whether x11, wayland or internal) is ignored. All windows
build up the top level with the sub surfaces as children.
Each surface is represented by some basic information about it:
* Client (binary path and pid)
* internal surface id
If the surface has a shared memory buffer mapped a scaled down version
is used as the window decoration role.
The model gets reset whenever the tree changes in some way as it's
rather complex to track correctly and well, it's just a debug console.
Currently the tree is not really functional yet as KWin doesn't announce
support for sub-compositor protocol, which is also the reason for lack of
autotests for the model. Will be added once sub-compositor works
properly.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1205
using stack adresses makes it possible (even tough not frequent)
for two animations (onle just killed, one just created) to have
the same id, causing scripts to be potentially really confused.
this replaces the id with a global counter, and the
"flying tooltips" bug is gone.
REVIEW:127276
BUG:360068
CCBUG:352254
Summary:
Before we were able to render Xwayland windows through the Wayland buffer
we used a xcb-shm to map the window data in the QPainter compositor.
As we don't use that any more and QPainter is not available for X11
anyway we can just drop the code.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1193
Summary:
A user shouldn't be able to manually move/resize a desktop window or
a panel. So far this wasn't ensured.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1155
Summary:
This changes splits up the monster file containing different types used
in the DRM backend into separate files per class:
- drm_backend.{h,cpp}
- drm_buffer.{h,cpp}
- drm_inputeventfilter.{h,cpp}
- drm_output.{h,cpp}
- drm_pointer.h
No actual code changes other than build fixes.
Clean up headers in the split files.
Test Plan: Builds with GBM enabled
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1168
The dialog only had a "Close" button but the text was only transfered in accepted()
Also fix the position of the QDialogButtonBox which is swapped and so the buttons appear at the top.
BUG: 360521
FIXED-IN: 5.6.1
Differential Revision: https://phabricator.kde.org/D1173
Summary:
The idea behind the debugging console is to have a feature comparable
to xprop and xwininfo just for Wayland. We cannot have command line
utils as that violates the security restrictions, thus it needs to be
exposed directly in KWin.
The debugging console is invoked through DBus:
qdbus org.kde.KWin /KWin showDebugConsole
This opens a window with a tree view. The DebugConsoleModel which is
used by the tree view groups all windows into four categories:
* x11 clients (that is Workspace::clientList() and Workspace::desktopList())
* x11 unmanaged (Workspace::unmanagedList())
* wayland shell clients (WaylandServer::clients())
* wayland internal clients (KWin's own QWindows - WaylandServer::internalClients())
Each window is a child to one of the four categories. Each window itself
has all it's QProperties exposed as children.
This allows to properly inspect KWin's internal knowledge for windows and
should make it easier to investigate problems. E.g. what's a window's
geometry, what's it's window type and so on.
The debugging console is intended as a developer tool and not expected to
be used by users. That's why it's invokation is rather hidden. Due to
the fact that it's internal to KWin it results in:
* no window decoration
* stealing keyboard focus
* no way to resize, close, move from KWin side
* rendered above all other windows
There is a dedicated close button to get rid of it again. While the
console is shown it's hardly possible to interact with the system in
a normal way anymore. This is something which might be improved in
future.
At the moment the model is able to update when windows are added/removed,
but not yet when a property changes. Due to the lack of interaction with
the existing system, that's not a high priority at the moment, but can
be added in future.
Reviewers: #plasma
Differential Revision: https://phabricator.kde.org/D1146
