This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.
With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend
The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland
This change introduces a mechanism for internal windows to be rendered
to a QOpenGLFramebufferObject to be composited using the texture bound
to the FBO. This is useful for in-process rendering (e.g. QtQuick) and
at the same time bypassing the windowing system.
The OpenGL context of the QOpenGLFramebufferObject needs to be sharing
with the compositing OpenGL context.
In an own QPA plugin we want to make the OpenGL context sharing with
our compositing context and bypass the windowing system for OpenGL
windows. In order to achieve this we need a surfaceless context.
The AbstractBackend now forwards whether such a context can be created on
the EGLDisplay used by the Compositor.
Allows to interact with the Registry for the internal connection in
other parts of KWin and makes it possible to create more than just the
ShmPool for this Registry.
With this change libinput is less noisy and only prints errors to stderr.
In addition one could install a dedicated log handler and forward to
qCDebug and friends.
I don't understand why, but this fixes the TestXcbWrapper::testTransientFor().
Failing code fragment in question:
Window transientWindow(createWindow());
transientWindow.changeProperty(XCB_ATOM_WM_TRANSIENT_FOR, XCB_ATOM_WINDOW, 32, 1, &m_testWindow);
// let's get another transient object
TransientFor realTransient(transientWindow);
QVERIFY(realTransient.getTransientFor(&compareWindow));
QCOMPARE(compareWindow, (xcb_window_t)m_testWindow);
the QCOMPARE failed with one compareWindow being 0. It looks like the
cast from Xcb::Window to xcb_window_t in the changeProperty failed.
REVIEW: 124864
* Need to pass modifiers to Client::keyPressEvent
* Need to check whether move/resize ended before updating position,
otherwise it keeps stuck in move/resize after ending
not everytime the current screen changes.
a) that pollutes the geometry when the tabbox is invoked
b) it's insufficient for "Active Screen follows mouse" (the default)
c) less overhead (ok: "on multiscreen")
BUG: 337790
CCBUG: 341531
FIXED-IN: 5.4
REVIEW: 124814
the (old) button effect windows used to be unreferenced
with the re-invocation of the effect. because we stopped
deleting/recreating the window, this approach failed and
the effect window was never deleted.
Unreferencing the window at proper occasion (see new hide
location) coked up - guess what - the exact same "texture is
junk" issue as for the QtQuick close button in present windows...
So we resort to the exact same stupid "hide by moving" solution
as we have there.
BUG: 348577
FIXED-IN: 5.4
REVIEW: 124136
1. if a client has oversize, ensure to keep the titlebar in
sight
2. if a maximized client *almost* covers the entire maximization
area, users can easily be trapped to click into the missing
pixels, thus the client below.
Therfore the clients is then stuffed into one corner, with
preference to the titlebar edge and the screen area (ie.
*away* from panels and towards actual screen borders because
of fitt's law)
BUG: 349935
REVIEW: 124286
FIXED-IN: 5.4
Let's rather not build the plugin if we don't have the dependency
then building it without OpenGL support. Simplifies the code a bit
and makes the backend overall more useful and goes along with e.g.
the Wayland one which has EGL also as a hard dependency for the
plugin.
REVIEW: 124697
The option NoPlugin allows to disable window decoration plugins. It
used to exist with the old decoration library but got unfortunately
lost during the switch.
This change brings back the option and also allows runtime changes
of the option.
REVIEW: 124708
Without the componentDisplayName the shortcut dialog takes the name of
the application e.g. Systemsettings or "KDE Control Module", but we want
it to be KWin.
REVIEW: 124706
The build option wasn't used for 5.x at all and in this way doesn't make
any sense nowadays. We want to have a converged desktop which also means
that the window manager should be able to switch to a different form
factor with a full feature set (plug in external screen to smartphone and
it should be full desktop). A trimmed down KWin with compiled out
functionality cannot do that. Also the need for trimmed down KWin becomes
less and less important given the improved hardware we target nowadays.
This change got triggered by the announcement to close down the Plasma
Active mailinglist [1], which shows that having a build option called
Plasma Active is no longer needed.
[1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343
REVIEW: 124694
It doesn't make much sense any more as we do no longer link EGL since the
switch to epoxy. And epoxy pulls it in at runtime if needed.
Even more on Wayland it's just plain stupid to have EGL disabled. So
removing the option just simplifies our code base without any
disadvantages.
REVIEW: 124695
