1. 21 May, 2015 7 commits
  2. 20 May, 2015 8 commits
  3. 19 May, 2015 11 commits
  4. 18 May, 2015 10 commits
    • Martin Flöser's avatar
      [wayland] ShellClient can reference an internal QWindow · 7d152991
      Martin Flöser authored
      If the ShellClient got created for a Qt internal window, we try to
      find the QWindow and if we get one, we use the geometry directly as
      it got set by KWin in the first place.
      Also a windowId() is added to ShellClient which can be used by the
      effect system to find an EffectWindow. If it's an internal QWindow
      we just use that window id. For other clients we still need some
      smart solution.
    • Martin Flöser's avatar
      [wayland] Reuse position when size of a ShellClient changes · 31cc2628
      Martin Flöser authored
      Means the window is not always reset to (0,0) when the size changes.
    • Martin Flöser's avatar
      [wayland] Flush QtWaylands wl_display and KWin's wayland server when processing events · 74ae2f50
      Martin Flöser authored
      QtWayland and mesa might dead lock KWin if we start rendering a QWindow
      before Qt/Mesa got the last frame callback. They perform blocking wayland
      event reading on the main gui thread which makes it impossible for KWin
      to do the compositing and send the callback.
      To workaround this problem we fake a frameRendered directly after each
      damage event for a Qt internal window. Unfortunately this is not yet
      completely sufficient, thus we also need to ensure that the wayland
      events are processed before any events are processed which would cause
      a repaint and block. Thus we first flush QtWayland's wl_display and then
      our Server connection. If there were any damage events we can be sure
      that the frameRendered is sent before Qt attempts to render.
    • Martin Flöser's avatar
      [wayland] Use a dummy window for QtWayland's popup window handling · 29c2ae57
      Martin Flöser authored
      QtWayland only creates popup windows if they have a parent QWindow or
      if there is any window which had input. It's not enough to fake an
      enter, it needs to be either a pointer button press or key press.
      As KWin's useraction menu doesn't have a parent and we most likely
      never send a pointer press to any QWindow it doesn't get shown. To
      circumvent this we create a dummy window and fake a button press/release
      on the window. After that Qt is tricked into believing there's a parent
      window and shows the popup.
      Faking the input is only done with at least Qt 5.5 as QtWayland crashes
      on pointer event without a keymap being installed. As KWin does not yet
      send keymaps we better disable the dangerous code path. With Qt 5.5 the
      crash condition is fixed.
    • Martin Flöser's avatar
      [wayland] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher · 3f94a2af
      Martin Flöser authored
      KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of
      QUnixEventDispatcherQPA. This caused QWindow related events never to
      be send to their destination. Which is one of the reasons why KWin's
      own windows are not shown at all.
      As we cannot easily use QUnixEventDispatcherQPA we do the same as
      that class. Inherit from QEventDispatcherUNIX and call into
    • Martin Flöser's avatar
      [wayland] Don't handle ShellSurface created signals till Workspace is ready · 4a671fbf
      Martin Flöser authored
      Similar to Surface: we ignore till we are all ready to go.
    • Martin Flöser's avatar
      [wayland] Disable Qt's client side decoration for KWin · a9649885
      Martin Flöser authored
      KWin's own windows don't use decorations, so we don't want Qt's
      decos either.
    • Martin Flöser's avatar
    • Martin Flöser's avatar
      Drop Client::m_frameWrapper workaround for reparenting deco · 0dda7b3f
      Martin Flöser authored
      No longer used, so we can just drop it.
      Thanks to QtWayland for emitting a warning, which made me find this
      useless code.
    • Martin Flöser's avatar
      Delay desktopPresenceChanged in EffectsHandlerImpl instead of Workspace · 30e6ae34
      Martin Flöser authored
      The signal might be emited by Workspace just before a Client gets
      destroyed. In that case the argument carried by the queued event is no
      longer valid and causes problems. In EffectsHandlerImpl we can queue
      it without problems as the EffectWindow also stays valid if the Client
      gets destroyed. The referenced Deleted gets destroyed with a deleteLater,
      thus will be after the signal is emitted.
      BUG: 347490
      REVIEW: 123729
  5. 17 May, 2015 2 commits
  6. 15 May, 2015 2 commits