GitLab's annual major release is around the corner. Along with a lot of new and exciting features, there will be a few breaking changes. Learn more here.

  1. 22 Sep, 2020 2 commits
    • Roman Gilg's avatar
      refactor: add frameGeometryChanged basic implementation · 5499b166
      Roman Gilg authored
      Earlier this year in KWin the frameGeometryChanged signal was added. The
      current client code is not yet refactored to make full use of that concept but
      we can create a basic implementation short-term.
      5499b166
    • Vlad Zahorodnii's avatar
      fix: partially revert a0c4a8e766a2160 · 30f89a71
      Vlad Zahorodnii authored
      Unfortunately, a0c4a8e766a2160213838daf6f71c7ae6c3705df has a major bug
      where clients that track focus events may get confused by focusToNull().
      
      One such a notable example is Dota 2. It tracks the focus events to
      minimize itself after the keyboard focus has been lost as well stop
      playing music while it's in background. So, when we call focusToNull(),
      Dota 2 will receive a corresponding FocusOut event and ask the window
      manager to minimize it. It doesn't really matter that the FocusOut
      event is going to be followed by a FocusIn event because when a window
      is minimized, kwin will activate the next one in the focus chain.
      
      Since those issues can't be fixed from the window manager's side, this
      patch partially reverts a0c4a leaving only the autotest.
      
      BUG: 424223
      FIXED-IN: 5.19.4
      30f89a71
  2. 21 Sep, 2020 3 commits
    • Vlad Zahorodnii's avatar
      fix(space): force FocusIn events for already focused windows · 21728f27
      Vlad Zahorodnii authored
      Depending on the current focus stealing prevention level, it's possible
      for kwin to call XSetInputFocus() on a window that already has the input
      focus. In which case, we won't receive the corresponding FocusIn event
      and the client will remain inactive from kwin's perspective even though
      it isn't.
      
      In order to work around this issue, we can move the input focus to the
      null window. By doing so, it's guaranteed that we're going to receive
      the matching FocusIn event for the client.
      
      This commit indirectly fixes a bug where fullscreen games are displayed
      below panels.
      21728f27
    • Vlad Zahorodnii's avatar
      fix: hold a passive grab on buttons only when needed · 62f2220b
      Vlad Zahorodnii authored
      Due to a bug in the XI2 protocol, clients have to reset scroll valuators
      on XI_Enter because the scroll valuators might have changed while the
      pointer was elsewhere. The XI_Enter event is usually sent when an input
      device enters the window, but it can also be generated by a passive grab.
      
      If an XI_Enter event has been generated by a passive grab, the client
      should not reset scroll valuators. Unfortunately, there is no any
      reliable way for the client to determine if an XI_Enter event has been
      sent in response to a deactivated passive grab. A correct fix for the
      scroll issues in GTK apps would involve changes in the XI2 protocol.
      
      As a work around, we can hold a passive grab only if the current mouse
      wheel action is either "Activate and scroll" or "Activate, raise, and
      scroll."
      
      BUG: 394772
      FIXED-IN: 5.19.3
      62f2220b
    • Alain Knaff's avatar
      fix: send a valid timestamp on X11 in TakeFocus messages · db81769c
      Alain Knaff authored
      Kwin sends out undated WM_TAKE_FOCUS client messages. Gtk based
      applications such as Firefox react to these by handing focus to one of
      their subwindows using XSetInputFocus(), and pass on the null time field
      that they received in the client message to XSetInputFocus().
      
      If for whatever reason the application (firefox) is slow to process the
      event, it might issue that XSetInputFocus() message at a time when it
      has already lost focus to the next application. This results in Firefox
      stealing back the focus from the next application. Normally, such an
      occurrence would not happen, as the server could tell by the time field
      that the message is stale.
      
      Until 2016 (e73e331f) kwin *used* to
      send a valid timestamp, but this got deliberately broken to appease some
      Java Applications which were "extremely picky" and would refuse focus.
      
      This was based on the assumption that no other toolkit used the
      timestamp from take focus events which is now proven to be false.
      
      ICCCM document states:
      
      Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may
      receive  a ClientMessage event from the window manager (as described in
      section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid
      timestamp (i.e. not CurrentTime ) in its data[1] field."
      
      BUG: 421068
      db81769c
  3. 15 May, 2020 1 commit
  4. 04 May, 2020 2 commits
  5. 13 Feb, 2020 2 commits
    • Roman Gilg's avatar
      feat(xwl): support resolution change emulation · 7f443f28
      Roman Gilg authored
      This patch adds functionality to make use of recent XWayland patches for
      emulating RandR resolution changes through the Wayland wp_viewporter protocol
      extension.
      
      For that a specific window property must be read and the emulated size sent via
      X11 protocol to the respective client window.
      
      This patch is WIP because I noticed structural problems that we have with the
      current XWayland code. For one KWin is creating one too many parent windows to
      work together with the new XWayland code.
      
      Tested with patches to XWayland currently being reviewed and the games
      supertux2 and supertuxkart.
      7f443f28
    • Vlad Zahorodnii's avatar
      fix(scene): resize X11 windows without visual artifacts · f26546fb
      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
      f26546fb
  6. 29 Jan, 2020 3 commits
  7. 21 Jan, 2020 2 commits
  8. 04 Dec, 2019 3 commits
  9. 03 Dec, 2019 2 commits
  10. 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
  11. 27 Nov, 2019 4 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
      [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 b...
      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
      [wayland] Implement window geometry more properly · 9f7a856d
      Vlad Zahorodnii authored
      Summary:
      So far the window geometry from xdg-shell wasn't implemented as it should
      be. A toplevel must have two geometries assigned to it - frame and buffer.
      The frame geometry describes bounds of the client excluding server-side
      and client-side drop-shadows. The buffer geometry specifies rectangle on
      the screen occupied by the main surface.
      
      State and geometry handling in XdgShellClient is still a bit broken. This
      change doesn't intend to fix that, it must be done in another patch asap.
      
      Test Plan: New tests pass.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: davidedmundson, romangg, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T10867
      
      Differential Revision: https://phabricator.kde.org/D24455
      9f7a856d
  12. 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
  13. 29 Sep, 2019 1 commit
  14. 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
  15. 24 Sep, 2019 2 commits
  16. 20 Sep, 2019 1 commit
  17. 19 Sep, 2019 2 commits
    • Vlad Zahorodnii's avatar
      Don't initialize QFlags<T> with nullptr · b8a6fd7c
      Vlad Zahorodnii authored
      Summary: This looks very odd.
      
      Test Plan: Compiles.
      
      Reviewers: #kwin, romangg
      
      Reviewed By: #kwin, romangg
      
      Subscribers: apol, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24086
      b8a6fd7c
    • 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
  18. 14 Sep, 2019 2 commits
    • Vlad Zahorodnii's avatar
      Don't initialize QFlags<T> with 0 value · 726e6c15
      Vlad Zahorodnii authored
      Summary:
      clang-tidy has a check that converts all usages of null pointer literals
      to nullptr keyword. However, there's a small issue related to QFlags<T>.
      
      Apparently, QFlags<T> has a constructor that takes a pointer and if you
      pass 0 to it, clang-tidy will replace 0 with nullptr, e.g.
      
          NET::States(0) -> NET::States(nullptr)
      
      Even though passing nullptr is totally correct, it looks very weird.
      
      Test Plan: Complies.
      
      Reviewers: #kwin, gladhorn
      
      Reviewed By: #kwin, gladhorn
      
      Subscribers: gladhorn, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D23948
      726e6c15
    • Frederik Gladhorn's avatar
      Remove disabled TabGroup feature · b64e67ce
      Frederik Gladhorn authored
      Summary:
      This has been commented out since 2014, I doubt it will come back.
      This is a big amount of code, maintenance will be easier without it.
      
      Reviewers: #kwin, zzag
      
      Reviewed By: #kwin, zzag
      
      Subscribers: romangg, graesslin, kwin
      
      Tags: #kwin, #documentation
      
      Differential Revision: https://phabricator.kde.org/D23069
      b64e67ce
  19. 07 Sep, 2019 1 commit
  20. 31 Aug, 2019 3 commits