1. 27 Jan, 2019 2 commits
    • Martin Flöser's avatar
      Add windowsystem plugin for KWin's qpa · 02a05610
      Martin Flöser authored
      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.
      
      Reviewers: #kwin
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D18228
      02a05610
    • Bhushan Shah's avatar
      remove superfluous code · ef510b4e
      Bhushan Shah authored
      Summary:
      For some reason this lines are duplicated twice, (possibly due to merge
      conflict resolution?), clean it up.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D18348
      ef510b4e
  2. 25 Jan, 2019 7 commits
  3. 24 Jan, 2019 7 commits
  4. 22 Jan, 2019 1 commit
  5. 21 Jan, 2019 6 commits
  6. 20 Jan, 2019 3 commits
  7. 18 Jan, 2019 9 commits
  8. 17 Jan, 2019 5 commits