Build system changes can be potentially breaking and so must be reviewed
prior to commit. In addition, there is no explanation for this change.
Simon, you might want to submit your patches to Phabricator for review
prior to landing them.
CCMAIL: sdepiets@gmail.com
This reverts commit 4f4f3295f2.
A recent change [1] led to Qt5PlatformSupport.pc not being installed
anymore. Pkg-config was only used for finding the paths, and the actual
include flags and library names were hardcoded in KWin's
FindQt5PlatformSupport.cmake anyway, so let's just focus on finding
Qt5Gui, the module which provides this Qt5PlatformSupport library, and
work from there.
Thanks to Hrvoje Senjan (shumski) for pointing me towards the upstream
Gerrit change.
[1] https://codereview.qt-project.org/140954/
REVIEW: 126234
The one contains a set of paths which might be the reason why e.g on the
CI the include dir cannot be constructed. Let's see what will happen....
CCBUG: 351776
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
