1. 26 Aug, 2020 1 commit
  2. 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
  3. 05 Aug, 2020 1 commit
  4. 23 Jul, 2020 1 commit
  5. 03 Jun, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [scene] Introduce helpers for mapping between different coordinate spaces · 9e797cf9
      Vlad Zahorodnii authored
      We currently deal with three distinct coordinate spaces - the window
      pixmap coordinate space, the window coordinate space, and the buffer
      pixel coordinate space.
      
      This change introduces a couple of helper methods to make it easier
      to map points from the window pixmap space to the other two spaces.
      
      The main motivation behind the new helpers is to break the direct
      relationship between the surface-local coordinates and buffer pixel
      coordinates for wayland surfaces.
      9e797cf9
  6. 04 May, 2020 1 commit
  7. 30 Apr, 2020 1 commit
  8. 02 Apr, 2020 1 commit
    • Aleix Pol Gonzalez's avatar
      Make it possible to have a separate cursor for the tablet · 6abd23ed
      Aleix Pol Gonzalez authored
      Summary:
      As is KWin only had 1 Cursor which was a singleton. This made it impossible for
      us to properly implement the tablet (as in drawing tablets) support and show where
      we're drawing.
      This patch makes it possible to have different Cursors in KWin, it makes all the
      current code still follow the mouse but the tablet can still render a cursor.
      
      Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
      
      Reviewers: #kwin, cblack, davidedmundson
      
      Reviewed By: #kwin, cblack, davidedmundson
      
      Subscribers: davidedmundson, cblack, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D28155
      6abd23ed
  9. 14 Mar, 2020 1 commit
  10. 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
  11. 23 Jan, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Use less Toplevel::isClient() · 4d161bec
      Vlad Zahorodnii authored
      Summary:
      Prefer qobject_cast<> over Toplevel::isClient() because it's more type
      safer and makes code a bit more readable.
      
      Hopefully, one day we will be able to get rid of isClient() altogether.
      
      Test Plan: Compiles.
      
      Reviewers: #kwin
      
      Subscribers: kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D26541
      4d161bec
  12. 27 Nov, 2019 2 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 d...
      9d4a3259
    • 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
  13. 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
  14. 30 Sep, 2019 1 commit
  15. 27 Sep, 2019 1 commit
    • David Edmundson's avatar
      [libkwineffects] Introduce API to easily show a QtQuick scene in an effect · 40b0296d
      David Edmundson authored
      Summary:
      EffectQuickView/Scene is a convenient class to render a QtQuick
      scenegraph into an effect.
      
      Current methods (such as present windows) involve creating an underlying
      platform window which is expensive, causes a headache to filter out
      again in the rest of the code, and only works as an overlay.
      
      The new class exposes things more natively to an effect where we don't
      mess with real windows, we can perform the painting anywhere in the view
      and we don't have issues with hiding/closing.
      
      QtQuick has both software and hardware accelerated modes, and kwin also
      has 3 render backends. Every combination is supported.
      
      * When used in OpenGL mode for both, we render into an FBO export the
      texture ID then it's up to the effect to render that into a scene.
      
      * When using software QtQuick rendering we blit into an image, upload
      that into a KWinGLTexture which serves as an abstraction layer and
      render that into the scene.
      
      * When using GL for QtQuick and XRender/QPainter in kwin everything is
      rendered into the internal FBO, blit and exported as an image.
      
      * When using software rendering for both an image gets passed directly.
      
      Mouse and keyboard events can be forwarded, only if the effect
      intercepts them.
      
      The class is meant to be generic enough that we can remove all the
      QtQuick code from Aurorae.
      
      The intention is also to replace EffectFrameImpl using this backend and
      we can kill all of the EffectFrame code throughout the scenes.
      
      The close button in present windows will also be ported to this,
      simplifiying that code base.
      
      Classes that handle the rendering and handling QML are intentionally
      split so that in the future we can have a declarative effects API create
      overlays from within the same context. Similar to how one can
      instantiate windows from a typical QML scene.
      
      Notes:
      I don't like how I pass the kwin GL context from the backends into the
      effect, but I need something that works with the library separation. It
      also currently has wayland problem if I create a QOpenGLContext before
      the QPA is set up with a scene - but I don't have anything better?
      
      I know for the EffectFrame we need an API to push things through the
      effects stack to handle blur/invert etc. Will deal with that when we
      port the EffectFrame.
      
      Test Plan: Used in an effect
      
      Reviewers: #kwin, zzag
      
      Reviewed By: #kwin, zzag
      
      Subscribers: zzag, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24215
      40b0296d
  16. 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
  17. 23 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Port QPA away from Wayland · bebe8120
      Vlad Zahorodnii authored
      Summary:
      So far wayland was used by internal clients to submit raster buffers
      and position themselves on the screen. While we didn't have issues with
      submitting raster buffers, there were some problems with positioning
      task switchers. Mostly, because we had effectively two paths that may
      alter geometry.
      
      A better approach to deal with internal clients is to let our QPA use
      kwin core api directly. This way we can eliminate unnecessary roundtrips
      as well make geometry handling much easier and comprehensible.
      
      The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
      style use platform-specific APIs to set and unset shadows. We need to
      add shadows API to KWindowSystem. Even though some internal clients lack
      drop-shadows at the moment, I don't consider it to be a blocker. We can
      add shadows back later on.
      
      CCBUG: 386304
      
      Reviewers: #kwin, davidedmundson, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T9600
      
      Differential Revision: https://phabricator.kde.org/D22810
      bebe8120
  18. 19 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Use nullptr everywhere · 62a7db70
      Vlad Zahorodnii authored
      Summary:
      Because KWin is a very old project, we use three kinds of null pointer
      literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
      nullptr keyword.
      
      This change converts all usages of 0 and NULL literal to nullptr. Even
      though it breaks git history, we need to do it in order to have consistent
      code as well to ease code reviews (it's very tempting for some people to
      add unrelated changes to their patches, e.g. converting NULL to nullptr).
      
      Test Plan: Compiles.
      
      Reviewers: #kwin, davidedmundson, romangg
      
      Reviewed By: #kwin, davidedmundson, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D23618
      62a7db70
  19. 09 Jul, 2019 1 commit
  20. 07 Jun, 2018 1 commit
    • Vlad Zahorodnii's avatar
      [scenes/qpainter] Draw decoration shadows · 2d01ba64
      Vlad Zahorodnii authored
      Summary:
      QPainter doesn't render decoration shadows. It renders only
      shadows provided through ShadowInterface.
      
      With this change, painting of shadows is done in similar way OpenGL backend is
      currently doing.
      
      Before
      
      {F5734867, layout=center, size=full}
      
      After
      
      {F5734870, layout=center, size=full}
      
      Depends on D10811 (dummy decoration with shadows in autotests)
      
      Test Plan:
      * start kwin with QPainter backend enabled:
      
      ```
      KWIN_COMPOSE=Q kwin_wayland --xwayland --windowed
      ```
      
      * open konsole and kate:
      
      ```
      DISPLAY=:1 konsole
      DISPLAY=:1 kate
      ```
      
      Reviewers: #kwin, graesslin, davidedmundson
      
      Reviewed By: davidedmundson
      
      Subscribers: abetts, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D10943
      2d01ba64
  21. 01 Nov, 2017 1 commit
    • David Edmundson's avatar
      Render GL Window decorations at the correct scale · fc887ab9
      David Edmundson authored
      Summary:
      Under wayland we support high DPI putting by putting a separation
      between the logical co-ordinate system and the resolution of rendered
      assets.
      
      When a window is on a high DPI screen, we should render at the higher
      resolution.
      
      Like the window scaling this handles any combination of a 2x scaled
      decoration being rendered on a 1x screen or vice versa.
      
      ---
      This patch is a bit different from the other scaling stuff. We have to
      generate the quads *before* we have an updated texture with the new
      scale. This means the scale isn't attached to the buffer like elsewhere.
      
      That's why I added a property in TopLevel so there's still one canonical
      source and things can't get out of sync.
      
      BUG: 384765
      
      Test Plan:
      Crystal clear breeze and oxygen decos on my @2x display
      Drag windows to attached @1x display, things still look OK when across 2
      screens
      Changing the scale of a screen updated the decos instantly
      
      Reviewers: #plasma, graesslin
      
      Reviewed By: #plasma, gr...
      fc887ab9
  22. 30 Oct, 2017 1 commit
    • David Edmundson's avatar
      Scaled decorations in QPainter mode · 7e6721ec
      David Edmundson authored
      Summary:
      Under wayland we support high DPI putting by putting a separation
      between the logical co-ordinate system and the resolution of rendered
      assets.
      
      I didn't include window decorations in the previous wayland scaling
      patchset. They were drawn them at a standard resolution, which is
      implicitly scaled up.
      
      This uses the Qt scaling, meaning oxygen and breeze (and others) get
      perfect high DPI support with zero client changes.
      
      Like the window scaling this handles any combination of a 2x scaled
      decoration being rendered on a 1x screen or vice versa.
      
      CCBUG: 384765
      
      Test Plan:
      export KWIN_COMPOSE=Q
      Had two screens of different scales
      It was the right size on both (as before)
      Was super-sharp on the fancy screen
      
      Reviewers: #plasma, hetzenecker, graesslin
      
      Reviewed By: #plasma, graesslin
      
      Subscribers: ngraham, graesslin, plasma-devel, kwin, #kwin
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D8504
      7e6721ec
  23. 01 Sep, 2017 2 commits
    • Martin Flöser's avatar
      Move QPainter compositor into plugin · 535b1079
      Martin Flöser authored
      This change is similar to D7232 and moves the scene_qpainter into a
      dedicated plugin. Compared to the XRender case it's more complicated as
      the platform plugins need to implement a platform specific backend.
      
      The base implementation for this part used to be in scene_qpainter. As
      the idea is to completly move it away from KWin core it would be point
      less to still have the backend definition in KWin core, but it cannot
      be in the scene plugin as otherwise all platforms need to link the
      plugin.
      
      To solve this a new platformsupport subdirectory is added which contains
      the scene platform backend as a static library. For the OpenGL scene such
      a static library will also be required.
      
      Test Plan: SceneQPainter test still passes, nested compositor still works
      
      Reviewers: #kwin, #plasma
      
      Subscribers: plasma-devel
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D7259
      535b1079
    • Martin Flöser's avatar
      Provide a virtual Scene::qpainterRenderBuffer() -> QImage* method · c398db3c
      Martin Flöser authored
      Needed by testing of QPainter scene to access the back buffer. Exposed
      as a virtual method in Scene, so that the test does not have to cast to
      SceneQPainter.
      c398db3c
  24. 09 Aug, 2017 1 commit
    • Martin Flöser's avatar
      Add virtual Scene::scenePainter method · ad4a3107
      Martin Flöser authored
      Summary:
      So far EffectsHandlerImpl directly accessed SceneQPainter::painter
      through a dynamic cast. If in future the QPainter based compositor should
      be moved into a plugin we cannot access it through a dynamic cast.
      
      To solve this problem the painter method is moved into Scene as
      a virtual method returning a sane default value.
      
      Reviewers: #kwin, #plasma
      
      Subscribers: plasma-devel
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D7214
      ad4a3107
  25. 02 Aug, 2017 1 commit
  26. 29 Mar, 2017 2 commits
  27. 14 Sep, 2016 1 commit
    • Martin Flöser's avatar
      Make WindowPixmap::isValid virtual and override in concrete implementation · 0bb1f2e7
      Martin Flöser authored
      Summary:
      If a buffer gets destroyed the texture created from it is still valid.
      In such a situation the OpenGLWindowPixmap should return true for isValid
      and not false as it did. Similar in QPainter compositor the pixmap is
      valid if there is an image copied from the buffer.
      
      This change ensures that for example minimizing an XWayland window
      still has a texture during the minimize animation.
      
      BUG: 368440
      
      Test Plan:
      Minimize animation plays for X windows and minimized windows
      are shown in present windows.
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2724
      0bb1f2e7
  28. 23 Aug, 2016 1 commit
  29. 01 Jul, 2016 1 commit
    • Martin Flöser's avatar
      [autotests] Add a new test case which can verify the rendering of QPainter Scene · 055e2b3b
      Martin Flöser authored
      Summary:
      The idea behind this autotest is inspired by bug 356328 which produced
      incorrect rendering results. Also it's inspired by openQA which performs
      image reference comparisons.
      
      This test case tries to go further. It creates reference images which
      must match the rendering result exactly. So far the test case verifies
      the start condition - kwin started and one frame is rendered with default
      cursor in the middle of the screen. And it verifies the moving of the
      cursor without any windows shown. Whenever the cursor moves a repaint
      should be triggered and the old and new area should be properly
      repainted.
      
      To support this the test needs some minor changes in KWin:
      * Scene provides a frameRendered signal - needed for waiting on frame
      * Scene and SceneQPainter are exported
      * SceneQPainter provides access to it's Backend, so that we get to the
       backbuffer
      * ScriptedEffectLoader is exported for getting a list of all scripted
       effects - (we don't want fade to manipulate the rendering)
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2046
      055e2b3b
  30. 29 Jun, 2016 3 commits
    • Martin Flöser's avatar
      Paint the software cursor directly in SceneQPainter · 758d41d6
      Martin Flöser authored
      Summary:
      No need to delegate the painting of the software cursor into the backend.
      The core has enough information to perform the rendering itself.
      
      This change means less code duplication and all platforms which might use
      a software cursor in QPainter compositor gain support for it without any
      further adjustments.
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2028
      758d41d6
    • Martin Flöser's avatar
      Render cursor in multi-screen setup in QPainter Compositor · 23fb02cc
      Martin Flöser authored
      Summary:
      The call to render the cursor was missing in the multi-screen code path
      of the QPainter Compositor.
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2027
      23fb02cc
    • Martin Flöser's avatar
      Properly clip the damage region and windows in SceneQPainter · fd19db0f
      Martin Flöser authored
      Summary:
      On the framebuffer backend the software rendered cursor was creating
      rendering artifacts due to incorrect clipping. This change ensures that
      in a single screen setup the clipping is performed correctly. For multi
      screen a similar change might be required, but we currently don't have
      any a way to test that as framebuffer only supports one screen and other
      (visual) platforms don't support the software cursor.
      
      CCBUG: 356328
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2024
      fd19db0f
  31. 15 Apr, 2016 1 commit