1. 03 Nov, 2020 1 commit
  2. 30 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Store repaint regions per individual screen · 74391e25
      Vlad Zahorodnii authored
      AnimationEffect schedules repaints in postPaintWindow() and performs
      cleanup in preScreenPaint(). With the X11-style rendering, this doesn't
      have any issues, scheduled repaints will be reset during the next
      compositing cycle.
      
      But with per screen rendering, we might hit the following case
      
          - Paint screen 0
          - Reset scheduled repaints
          - AnimationEffect::prePaintScreen(): update the timeline
          - AnimationEffect::postPaintScreen(): schedule a repaint
      
          - Paint screen 1
          - Reset scheduled repaints
          - AnimationEffect::prePaintScreen(): destroy the animation
          - AnimationEffect::postPaintScreen(): no repaint is scheduled
      
          - Return to the event loop
      
      In this scenario, the repaint region scheduled by AnimationEffect will
      be lost when compositing is performed on screen 1.
      
      There is no any other way to fix this issue but maintain repaint regions
      per each individual screen if per screen rendering is enabled.
      
      BUG: 428439
      74391e25
  3. 29 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Transform a pending repaint into a workspace repaint before destroying Deleted · 2715cbc8
      Vlad Zahorodnii authored
      The sliding popups effect schedules a repaint and then unreferences the
      deleted window. The problem with doing so is that the scheduled repaint
      will be effectively discarded because the Deleted will be destroyed once
      we are back in the event loop.
      
      This issue is most noticeable on Wayland. Not sure why. If you close
      Kickoff, you may see its flickering ghost in background.
      
      If it happens that a Deleted has a pending repaint, transform it into a
      workspace repaint to avoid discarding any scheduled repaints.
      2715cbc8
  4. 23 Oct, 2020 1 commit
  5. 17 Oct, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Adapt to input region changes in kwayland-server · 41d431de
      Vlad Zahorodnii authored
      SurfaceInterface::inputIsInfinite() has been dropped. If the surface has
      no any input region specified, SurfaceInterface::input() will return a
      region that corresponds to the rect of the surface (0, 0, width, height).
      
      While the new design is more robust, for example it's no longer possible
      to forget to check SurfaceInterface::inputIsInfinite(), it has shown some
      issues in the input stack of kwin.
      
      Currently, acceptsInput() will return false if you attempt to click the
      server-side decoration for a surface whose input region is not empty.
      
      Therefore, it's possible for an application to set an input region with
      a width and a height of 1. If user doesn't know about KSysGuard or the
      possibility of closing apps via the task manager, they won't be able to
      close such an application.
      
      Another issue is that if an application has specified an empty input
      region on purpose, user will be still able click it. With the new
      behavior of SurfaceInterface::input(), this is no longer an issue and it
      is handled properly by kwin.
      41d431de
    • Vlad Zahorodnii's avatar
      Introduce geometry conversion helpers · ba4f6b35
      Vlad Zahorodnii authored
      The new helpers are designed for the purpose of mapping points from the
      global screen coordinates to the frame-local and the surface-local coords
      ba4f6b35
  6. 29 Sep, 2020 1 commit
  7. 24 Sep, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Replace remaining usages of old connect syntax with new connect syntax · 0c266e76
      Vlad Zahorodnii authored
      This change replaces the remaining usages of the old connect syntax with
      the new connect syntax.
      
      Unfortunately, there are still places where we have to use SIGNAL() and
      SLOT() macros, for example the stuff that deals with d-bus business.
      
      Clazy was used to create this change. There were a few cases that needed
      manual intervention, the majority of those cases were about resolving
      ambiguity caused by overloaded signals.
      0c266e76
  8. 22 Sep, 2020 1 commit
  9. 21 Aug, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Use universal helper for writing toplevels to QDebug streams · 90b53f41
      Vlad Zahorodnii authored
      Toplevel::debug() is one of annoyances that you need to deal with when
      implementing a new client type. It can be tempting to just write "this"
      to the stream, but it will result in a crash.
      
      In order to make implementing new client types easier, this change
      introduces a debug stream insertion operator overload that works for all
      kinds of the Toplevel class.
      90b53f41
  10. 07 Aug, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Prettify license headers · 4ce853e8
      Vlad Zahorodnii authored
      4ce853e8
    • Vlad Zahorodnii's avatar
      Switch to SPDX license markers · 1fb9f6f1
      Vlad Zahorodnii authored
      The main advantage of SPDX license identifiers over the traditional
      license headers is that it's more difficult to overlook inappropriate
      licenses for kwin, for example GPL 3. We also don't have to copy a
      lot of boilerplate text.
      
      In order to create this change, I ran licensedigger -r -c from the
      toplevel source directory.
      1fb9f6f1
  11. 17 Jul, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Update input transformation matrix when buffer geometry changes · cf271288
      Vlad Zahorodnii authored and Vlad Zahorodnii's avatar Vlad Zahorodnii committed
      Currently, we update the input transformation matrix for the focused
      pointer surface only when the frameGeometryChanged() signal is emitted.
      However, since the input transformation matrix is computed based on the
      current position of the upper left corner of the main surface, it is
      wrong to do so because the frame geometry is a logical geometry that
      doesn't have any direct relationship with the buffer geometry, i.e. the
      rect on the screen occupied by the main surface.
      
      If the input transformation matrix gets out of sync, user may notice
      that pointer events are "shifted."
      
      This change introduces a new signal that's emitted when the input
      transformation matrix has been changed. Input related components in kwin
      can connect to it to keep a copy of the input transformation matrix in
      SeatInterface in sync. Under the hood, the new signal is just an alias
      for the bufferGeometryChanged() signal.
      cf271288
  12. 24 Jun, 2020 1 commit
  13. 18 Jun, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Introduce the client geometry in Toplevel · cc3eb54b
      Vlad Zahorodnii authored and Vlad Zahorodnii's avatar Vlad Zahorodnii committed
      In most cases, we don't need to react to client geometry changes, but in
      code that deals with server-side window decorations, we need to react to
      client geometry changes. The problem is that frame and client geometry
      updates are not correlated even though there is a connection between the
      frame geometry and the client geometry.
      
      This change introduces the client geometry in the Toplevel class in order
      to allow monitoring client geometry updates from DecoratedClientImpl.
      cc3eb54b
  14. 30 Apr, 2020 1 commit
  15. 17 Mar, 2020 1 commit
  16. 22 Feb, 2020 4 commits
    • Nicolas Fella's avatar
      Revert "[kcm/effects] Clip ListView" · 7159684c
      Nicolas Fella authored
      Bad merge
      
      This reverts commit b7130442.
      7159684c
    • Nicolas Fella's avatar
      [kcm/effects] Clip ListView · b7130442
      Nicolas Fella authored
      Summary:
      Otherwise the content overflows the frame when scrolling.
      
      QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
      
      Test Plan:
      Before:
      {F8121150}
      
      After:
      {F8121152}
      
      Reviewers: #kwin, #plasma, ngraham
      
      Reviewed By: ngraham
      
      Subscribers: ngraham, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D27558
      b7130442
    • Nicolas Fella's avatar
      Revert "[kcm/effects] Clip ListView" · cdc5ea19
      Nicolas Fella authored
      Bad merge
      
      This reverts commit 5babf52d.
      cdc5ea19
    • Nicolas Fella's avatar
      [kcm/effects] Clip ListView · 5babf52d
      Nicolas Fella authored
      Summary:
      Otherwise the content overflows the frame when scrolling.
      
      QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
      
      Test Plan:
      Before:
      {F8121150}
      
      After:
      {F8121152}
      
      Reviewers: #kwin, #plasma, ngraham
      
      Reviewed By: ngraham
      
      Subscribers: ngraham, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D27558
      5babf52d
  17. 12 Feb, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Introduce Toplevel::frameGeometryChanged signal · 15af09c7
      Vlad Zahorodnii authored
      Summary:
      Currently we have two signals that are emitted when the Toplevel's geometry
      changes - geometryShapeChanged() and geometryChanged(). The former signal
      is used primarily to invalidate cached window quads and the latter is
      sort of emitted when the frame geometry changes. But it's not that easy. We
      have a bunch of connects that link those signals together...
      
      The worst part about all of this is that the window quads cache gets
      invalidated every time a geometry update occurs, for example when user
      moves a window around on the screen.
      
      This change introduces a new signal and deprecates the existing geometryChanged
      signal. frameGeometryChanged is similar to geometryChanged except that it is
      emitted when an _actual_ geometry change has occurred.
      
      We do still emit geometryShapeChanged signal. However, in long term, we
      need to get rid of this signal or come up with something that makes sense
      and doesn't require us to waste computational resources.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: davidedmundson, romangg, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D26863
      15af09c7
  18. 03 Feb, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [x11] Fix visual artifacts during interactive resize · 56d5f3a4
      Vlad Zahorodnii authored
      Summary:
      When a window is being interactively resized, its contents may jump. The
      reason why that happens is because KWin renders partially resized client
      window. Composite extension spec says that a window will get a new pixmap
      each time it is resized or mapped. This applies to the frame window, but
      not to the client window itself. If the client window is resized,
      off-screen storage for the frame window won't be reallocated. Therefore,
      KWin may render partially resized client window if the client doesn't
      attempt to be in sync with our rendering loop. Currently, the only way
      to do that is to use extended frame counters, which are not supported by
      KWin.
      
      So, in order to fix visual artifacts during interactive resize, we need
      somehow forcefully re-allocate off-screen storage for the frame window.
      Unfortunately, Composite extension doesn't provide any request to do
      that, so the only option we have is to resize the frame window.
      
      BUG: 415839
      FIXED-IN: 5.18.0
      
      Reviewers: #kwin
      
      Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D26914
      56d5f3a4
  19. 29 Jan, 2020 1 commit
  20. 28 Jan, 2020 2 commits
  21. 04 Dec, 2019 1 commit
  22. 03 Dec, 2019 1 commit
  23. 02 Dec, 2019 2 commits
    • Vlad Zahorodnii's avatar
      Revert the fix for the texture bleeding issue · 6e000314
      Vlad Zahorodnii authored
      This reverts commit 9151bb7b.
      This reverts commit ac4dce1c.
      This reverts commit 754b72d1.
      
      In order to make the fix work, we need to redirect the client window
      instead of the frame window. However, we cannot to do that because
      Xwayland expects the toplevel window(in our case, the frame window)
      to be redirected.
      
      Another solution to the texture bleeding issue must be found.
      
      CCBUG: 257566
      CCBUG: 360549
      6e000314
    • Vlad Zahorodnii's avatar
      [x11] Name client pixmap instead of frame pixmap · 754b72d1
      Vlad Zahorodnii authored
      Summary:
      Since KDE 4.2 - 4.3 times, KWin doesn't paint window decorations on real
      X11 windows, except when compositing is turned off. This leaves us with
      a problem. The actual client contents is inside a larger texture with no
      useful pixel data around it. This and decoration texture bleeding are
      the main factors that contribute to 1px gap between the server-side
      decoration and client contents with effects such as wobbly windows, and
      zoom.
      
      Another problem with naming frame pixmap instead of client pixmap is
      that it doesn't quite go along with wayland. It only makes more difficult
      to abstract window quad generation in the scene.
      
      Since we don't actually need the frame window when compositing is on,
      there is nothing that holds us from redirecting client windows instead
      of frame windows. This will help us to fix the texture bleeding issue
      and also help us with the ongoing redesign of the scene.
      
      Test Plan: X11 clients are still composited.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: davidedmundson, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D25610
      754b72d1
  24. 27 Nov, 2019 5 commits
    • Vlad Zahorodnii's avatar
      Drop some custom list typedefs · 9d4a3259
      Vlad Zahorodnii authored
      Summary:
      Qt has its own thing where a type might also have corresponding list
      alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
      know why Qt does that, maybe for some historical reasons, but what
      matters is that we copy this pattern here in KWin. While this pattern
      might be useful with some long list types, for example
      
          QList<QWeakPointer<TabBoxClient>> TabBoxClientList
      
      in general, it causes more harm than good. For example, we've got two
      new client types, do we need corresponding list typedefs for them? If
      no, why do we have ClientList and so on?
      
      Another problem with these typedefs is that you need to include utils.h
      header in order to use them. A better way to handle such things is to
      just forward declare a client class (if that's possible) and use it
      directly with QList or QVector. This way translation units don't get
      "bloated" with utils.h stuff for no apparent reason.
      
      So, in order to make code more consistent and easier to follow, this
      change drops some of our custom typedefs. Namely ConstClientList,
      ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
      
      Test Plan: Compiles.
      
      Reviewers: #kwin
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24950
      9d4a3259
    • Vlad Zahorodnii's avatar
      [x11] Add support for _GTK_FRAME_EXTENTS · 84d75cb5
      Vlad Zahorodnii authored
      Summary:
      KDE is known for having a strong view on the client-side decorations vs
      server-side decorations issue. The main argument raised against CSD is
      that desktop will look less consistent when clients start drawing window
      decorations by themselves, which is somewhat true. It all ties to how
      well each toolkit is integrated with the desktop environment.
      
      KDE doesn't control the desktop market on Linux. Another big "player"
      is GNOME. Both KDE and GNOME have very polarized views on in which
      direction desktop should move forward. The KDE community is pushing more
      toward server-side decorations while the GNOME community is pushing
      more toward client-side decorations. Both communities have developed
      great applications and it's not rare to see a GNOME application being
      used in KDE Plasma. The only problem is that these different views are
      not left behind the curtain and our users pay the price. Resizing GTK
      clients in Plasma became practically impossible due to resize borders
      having small hit area.
      
      When a client draws its window decoration, it's more likely that it also
      draws the drop-shadow around the decoration. The compositor must know
      the extents of the shadow so things like snapping and so on work as
      expected. And here lies the problem... While the xdg-shell protocol has
      a way to specify such things, the NetWM spec doesn't have anything like
      that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
      it is that it's a proprietary atom, which is specific only to GTK apps.
      
      Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
      anything like that would require major changes in how we think about
      geometry.
      
      Recent xdg-shell window geometry patches adjusted geometry abstractions
      in kwin to such a degree that it's very easy to add support for client
      side decorated clients on X11. We just have to make sure that the
      X11Client class provides correct buffer geometry and frame geometry when
      the gtk frame extents are set.
      
      Even though the X11 code is feature frozen, I still think it's worth
      to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
      issues. Also, because KWin/Wayland is unfortunately far from becoming
      default, it will help us with testing some implementation bits of the
      window geometry from xdg-shell.
      
      BUG: 390550
      FIXED-IN: 5.18.0
      
      Test Plan:
      Things like quick tiling, maximizing, tiling scripts and so on work as
      expected with GTK clients.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: cblack, trmdi, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24660
      84d75cb5
    • Vlad Zahorodnii's avatar
      Adjust scene for client-side decorated clients · fb2d4c11
      Vlad Zahorodnii authored
      Summary:
      Currently our Scene is quite naive about geometry. It assumes that the
      window frame wraps the attached buffer/client. While this is true for X11
      clients, such geometry model is not suitable for client-side decorated
      clients, in our case for xdg-shell clients that set window geometry
      other than the bounding rectangle of the main surface.
      
      In general, the proposed solution doesn't make any concrete assumptions
      about the order between frame and buffer geometry, however we may still
      need to reconsider the design of Scene once it starts to generate quads
      for sub-surfaces.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: davidedmundson, romangg, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T10867
      
      Differential Revision: https://phabricator.kde.org/D24462
      fb2d4c11
    • Vlad Zahorodnii's avatar
      Schedule correct damage and repaints region in addDamageFull for csd clients · 0394f581
      Vlad Zahorodnii authored
      Summary:
      The damage region is in surface-local coordinates, while the repaints
      region is in frame-local coordinates, i.e. relative to the top-left
      corner of the frame geometry.
      
      Reviewers: #kwin, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T10867
      
      Differential Revision: https://phabricator.kde.org/D24460
      0394f581
    • Vlad Zahorodnii's avatar
      Compute correct visible rect for client-side decorated clients · 79f4168f
      Vlad Zahorodnii authored
      Summary:
      Frame and buffer geometry don't have strict order. Either one of them can
      be inside the other one, so we must take that into account when computing
      visible bounds of the client including drop-shadows. We also have to take
      sub-surfaces into account when determining the visible rect, however it's
      out of scope for this patch.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T10867
      
      Differential Revision: https://phabricator.kde.org/D24458
      79f4168f
  25. 02 Oct, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Rename geometry property to frameGeometry · 7d4471eb
      Vlad Zahorodnii authored
      Summary:
      In order to properly implement xdg_surface.set_window_geometry we need
      two kinds of geometry - frame and buffer. The frame geometry specifies
      visible bounds of the client on the screen, excluding client-side drop
      shadows. The buffer geometry specifies rectangle on the screen that the
      attached buffer or x11 pixmap occupies on the screen.
      
      This change renames the geometry property to frameGeometry in order to
      reflect the new meaning assigned to it as well to make it easier to
      differentiate between frame geometry and buffer geometry in the future.
      
      Reviewers: #kwin
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24334
      7d4471eb
  26. 29 Sep, 2019 3 commits
  27. 25 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Rename Client to X11Client · ffcbe24e
      Vlad Zahorodnii authored
      Summary:
      Currently each managed X11 client is represented with an instance of
      Client class, however the name of that class is very generic and the
      only reason why it's called that way is because historically kwin
      was created as an x11 window manager, so "Client" was a sensible choice.
      
      With introduction of wayland support, things had changed and therefore
      Client needs to be renamed to X11Client in order to better reflect what
      that class stands for.
      
      Renaming of Client to X11Client was agreed upon during the last KWin
      sprint.
      
      Test Plan: Compiles, the test suite is still green.
      
      Reviewers: #kwin, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, davidedmundson, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24184
      ffcbe24e