Summary:
It's only needed by the standalone x11 variant. This allows us to
simplify the creation of the OpenGLBackend: it's created by the
platform plugin - we don't need custom complex logic.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1392
Summary:
Mostly meant for multi-screen setups: we don't want that a strut set on
a window on screen 0 results in screen 1 completely being excluded. Even
if that's strictly seen a client bug, it's better to just ignore the
strut from KWin's side.
The sanity check is implemented in Client::adjustedClientArea.
From a pure standard point of view this change is a EWMH violation and
thus can cause regressions: struts by clients no longer working.
A test case for struts is added, including some invalid combinations
whose strut is ignored with this change.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1386
Summary:
KWin needs the plugin id of the breeze decoration plugin. Instead
of hard coding that it's now resolved through an optional dependency.
If the optional dependency is not available, the default is adjusted
to aurorae/plastik.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1344
By moving XRandrScreens the creation of screens gets simplified a lot
as there is no need to have windowing system specific init code. It all
just goes through the platform.
This also marks the point where the first X11 specific code is removed
from kwin_wayland.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1355
kwin_x11 now also loads a platform plugin and initializes it.
It doesn't do much except loading it and init it. Though it's also
set up to continue startup only when screens are queried.
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
