D18228: Add windowsystem plugin for KWin's qpa

graesslin created this revision.
graesslin added a reviewer: KWin.
Herald added a project: KWin.
Herald added a subscriber: kwin.
graesslin requested review of this revision.

REVISION SUMMARY
  KWindowSystem provides a plugin interface to have platform specific
  implementations. So far KWin relied on the implementation in
  KWayland-integration repository.
  
  This is something I find unsuited, for the following reasons:
  
  - any test in KWin for functionality set through the plugin would fail
  - it's not clear what's going on where
  - in worst case some code could deadlock
  - KWin shouldn't use KWindowSystem and only a small subset is allowed
  
  to be used
  
  The last point needs some further explanation. KWin internally does not
  and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
  exposing information which KWin sets. It's more than weird if KWin asks
  KWindowSystem for the state of a window it set itself. On X11 it's just
  slow, on Wayland it can result in roundtrips to KWin itself which is
  dangerous.
  
  But due to using Plasma components we have a few areas where we use
  KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
  direction, blur and background contrast. This we want to support and
  need to support. Other API elements we do not want, like for examples
  the available windows. KWin internal windows either have direct access
  to KWin or a scripting interface exposed providing (limited) access -
  there is just no need to have this in KWindowSystem.
  
  To make it more clear what KWin supports as API of KWindowSystem for
  internal windows this change implements a stripped down version of the
  kwayland-integration plugin. The main difference is that it does not use
  KWayland at all, but a QWindow internal side channel.
  
  To support this EffectWindow provides an accessor for internalWindow and
  the three already mentioned effects are adjusted to read from the
  internal QWindow and it's dynamic properties.
  
  This change is a first step for a further refactoring. I plan to split
  the internal window out of ShellClient into a dedicated class. I think
  there are nowadays too many special cases. If it moves out there is the
  question whether we really want to use Wayland for the internal windows
  or whether this is just historic ballast (after all we used to use
  qwayland for that in the beginning).
  
  As the change could introduce regressions I'm targetting 5.16.

TEST PLAN
  new test case for window type, manual testing using Alt+Tab
  for the effects integration. Sliding popups, blur and contrast worked fine.

REPOSITORY
  R108 KWin

BRANCH
  windowsystem-plugin

REVISION DETAIL
  https://phabricator.kde.org/D18228

AFFECTED FILES
  autotests/integration/internal_window.cpp
  autotests/integration/shell_client_test.cpp
  autotests/test_window_paint_data.cpp
  effects.cpp
  effects.h
  effects/backgroundcontrast/contrast.cpp
  effects/backgroundcontrast/contrast.h
  effects/blur/blur.cpp
  effects/blur/blur.h
  effects/slidingpopups/slidingpopups.cpp
  effects/slidingpopups/slidingpopups.h
  libkwineffects/kwineffects.h
  plugins/CMakeLists.txt
  plugins/windowsystem/CMakeLists.txt
  plugins/windowsystem/kwindowsystem.json
  plugins/windowsystem/plugin.cpp
  plugins/windowsystem/plugin.h
  plugins/windowsystem/windoweffects.cpp
  plugins/windowsystem/windoweffects.h
  plugins/windowsystem/windowsystem.cpp
  plugins/windowsystem/windowsystem.h
  shell_client.cpp

To: graesslin, #kwin
Cc: kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart