1. 18 Oct, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Restore old behavior of Workspace::clientArea(clientOpt, Toplevel) · 29588812
      Vlad Zahorodnii authored
      When geometry updates are blocked, the output doesn't get updated. This
      breaks Workspace::clientArea() overload that takes only the window.
      Previously, clientArea() would look up the output where the window is
      every time it's called, so the fact that the screen id or AbstractOutput
      is unsynchronized with the frame geometry was irrelevant.
      This change restores the old behavior as 5.23 is affected by the
      output() being out of sync with the frameGeometry(). Specifically, when
      kwin starts managing an X11 window, it will block geometry updates,
      setup the window, e.g. make it fullscreen, and unblock geometry updates.
      Since Workspace::clientArea(clientArea, Toplevel) uses the output(),
      X11Client::setFullScreen() will most likely put the X11 window at a
      wrong output if it's called inside X11Client::manage().
      BUG: 443787
      (cherry picked from commit 6d5fc9fd)
  2. 05 Oct, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Clear should_get_focus in Workspace::focusToNull() · fba3f1e7
      Vlad Zahorodnii authored
      On X11, there are four input models. With some input models, it's okay
      if the window manager calls XSetInputFocus(), with others, the wm has to
      ask the client to make a XSetInputFocus() request.
      If kwin wants a client to take input focus, kwin will add the client
      to the should_get_focus list, which contains all the windows that
      are about to get input focus. Clients are popped from the list upon
      receiving FOCUS_IN events.
      A client will be added to the should_get_focus list even if kwin thinks
      that the client already has input focus because communication between
      the wm and xorg is async, anything can happen with input focus in meanwhile.
      On the other hand, the wm may sometimes focus the null window if no
      window should contain the input focus. The issue is that the
      should_get_focus list is not cleaned up in that case, which can lead to
      Workspace::mostRecentlyActivatedClient() returning wrong client and
      possibly other async related issues.
      We don't have such madness on Wayland as the compositor is in charge of
      handling input focus.
      This change makes Workspace::focusToNull() clear the should_get_focus,
      which is reasonable. We need to deactivate "in-flight" focus requests.
      This also fixes the bug where fullscreen Wayland windows don't go above
      docks and panels due to Workspace::mostRecentlyActivatedClient() returning
      bad client.
      BUG: 439405
      BUG: 395919
      (cherry picked from commit e6c77a1d)
  3. 04 Oct, 2021 1 commit
  4. 01 Oct, 2021 1 commit
  5. 06 Sep, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Move ownership of Shadow to Toplevel · 935fa6a9
      Vlad Zahorodnii authored
      This decouples the management of Shadow from the scene window and allows
      multiple items share the same Shadow.
      Currently, kwin has a single scene graph, but it makes sense to create a
      scene graph per output as they could have different layers, etc. This
      would also allow QtQuick share more textures with kwin, which is worth
      doing for optimization purposes in the future.
  6. 31 Aug, 2021 3 commits
  7. 30 Aug, 2021 3 commits
  8. 29 Aug, 2021 6 commits
  9. 27 Aug, 2021 3 commits
    • Vlad Zahorodnii's avatar
      Allow passing Toplevel to Workspace::clientArea() · 5a1b98d1
      Vlad Zahorodnii authored
      This allows us to re-use the same code path for alive and deleted
    • Vlad Zahorodnii's avatar
      Introduce Platform::outputAt() · d228829a
      Vlad Zahorodnii authored
      With AbstractOutput being used more heavily, it makes sense to have
      something like Screens::number() in the Platform class. As is, the steps
      to get an output for a given point are awkward - first, get the screen
      id, then use the screen id to get the output.
    • Vlad Zahorodnii's avatar
      effects: Wire EffectsHandler::screenGeometryChanged() to Screens::geometryChanged() · 894ed68f
      Vlad Zahorodnii authored
      Currently, the EffectsHandler has two signals that are emitted when the
      combined geometry of all outputs change - virtualScreenGeometryChanged()
      and screenGeometryChanged(). Having two signals is most likely a
      historical artifact.
      This change untangles the screenGeometryChanged() signal from the
      Workspace and makes it the same as the virtualScreenGeometryChanged()
  10. 25 Aug, 2021 5 commits
  11. 19 Aug, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Add Workspace::clientArea() that take no desktop · d5c25189
      Vlad Zahorodnii authored
      The new overloads take the client (as context) and the desired screen id
      or a point and return the client area.
      The main motivation behind this change is to make the transition to the
      new virtual desktop model where a window can be on several desktops less
  12. 18 Aug, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Simplify Workspace::sendClientToDesktop() · 1fbd99b5
      Vlad Zahorodnii authored
      This allows changing the type of desk to QVector<VirtualDesktop *>.
      Based on the dont_activate flag, Workspace::sendClientToDesktop() will
      try to focus the window if it's moved to the current virtual desktop.
      In order to implement that, it needs to know whether the window has been
      on the current desktop. c->isOnDesktop(desk) is a much sophisticated way
      to do that.
  13. 17 Aug, 2021 4 commits
    • Vlad Zahorodnii's avatar
      Consider only windows on current desktop when snapping them · 9962a9fe
      Vlad Zahorodnii authored
      If a window is on several desktops, AbstractClient::desktop() will
      return the id of the last desktop.
      For example, if a window is on virtual desktops A and B, the desktop()
      function will return the id of desktop B. This can be the culprit for
      bugs such as window snapping not working as expected when moving a
      window on virtual desktop A, e.g.
      - moved window is on desktops A, and C. desktop() returns the id of C
      - snap candidate (l) is on desktops A, and B. desktop() returns the id
        of B
      Even though the snap candidate window and the moved window are both on
      the same desktop (A), the moved window won't be snapped because the
      desktop() function returns garbage values.
      To fix that, the workspace needs to check whether the window is on the
      current desktop.
      For what it's worth, that's also how the workspace handles windows being
      on multiple activities.
    • Vlad Zahorodnii's avatar
      Port FocusChain to VirtualDesktop · 7c8d9c5b
      Vlad Zahorodnii authored
    • Vlad Zahorodnii's avatar
    • Vlad Zahorodnii's avatar
      Port Workspace::topClientOnDesktop() to VirtualDesktop · b75f0899
      Vlad Zahorodnii authored
      This patch has one behavioral change - raiseOrLowerClient() will not
      work if the client is not on the current virtual desktop.
      However, raiseOrLowerClient() can be called only in two cases:
      * user triggers the raise or lower shortcut for the active client. Since
        the active client is on the current virtual desktop, it's not an issue
      * an x11 window restacks itself. It makes no sense if an x11 window
        restacks itself while it's inactive or not on current virtual desktop.
        Also, the Opposite restack mode is rarely used, some window managers
        don't even bother implementing it. So, having such a constraint should
        not be a problem.
      The main reason for not allowing raiseOrLowerClient() for windows that
      are not on the current virtual desktop is that a window can be on
      multiple virtual desktops. If a window is on A and B virtual desktops,
      the only logical option is to toggle stacking position if the window is
      on the current desktop. It's the only viable option as kwin does not
      maintain per virtual desktop stacking order.
  14. 16 Aug, 2021 2 commits
  15. 22 Jun, 2021 2 commits
    • Vlad Zahorodnii's avatar
      Remove Toplevel::compositing() and Workspace::compositing() · c61085dc
      Vlad Zahorodnii authored
      It is error-prone to have multiple sources for the same data. If the
      base implementation (Compositor::compositing()) changes, other helpers
      can get out of sync.
    • Vlad Zahorodnii's avatar
      x11: Properly detect compositing status · d74e81bd
      Vlad Zahorodnii authored
      When finishing compositing, Workspace::compositing() will return true,
      but it will be preferred if it returns false instead so kwin can properly
      update x11 window visibility status, etc.
      Instead of checking whether the compositor has a scene, check the status
      of the compositor. It will not be "On" during teardown.
  16. 09 Jun, 2021 2 commits
    • Vlad Zahorodnii's avatar
      Remove OpenGL2Compositing enum · a0669002
      Vlad Zahorodnii authored
      OpenGLCompositing and OpenGL2Compositing enums mean de-facto the same
      thing, it's confusing to have them both.
    • Vlad Zahorodnii's avatar
      Remove Xrender backend · 811beb94
      Vlad Zahorodnii authored
      The Xrender backend was added at the time when OpenGL drivers were not
      particularly stable. Nowadays though, it's a totally different situation.
      The OpenGL render backend has been the default one for many years. It's
      quite stable, and it allows implementing many advanced features that
      other render backends don't.
      Many features are not tested with it during the development cycle; the
      only time when it is noticed is when changes in other parts of kwin break
      the build in the xrender backend. Effectively, the xrender backend is
      unmaintained nowadays.
      Given that the xrender backend is effectively unmaintained and our focus
      being shifted towards wayland, this change drops the xrender backend in
      favor of the opengl backend.
      Besides being de-facto unmaintained, another issue is that QtQuick does
      not support and most likely will never support the Xrender API. This
      poses a problem as we want thumbnail items to be natively integrated in
      the qtquick scene graph.
  17. 08 Jun, 2021 1 commit
  18. 25 May, 2021 1 commit
  19. 24 May, 2021 1 commit