1. 27 Feb, 2012 6 commits
  2. 24 Feb, 2012 4 commits
  3. 23 Feb, 2012 4 commits
  4. 21 Feb, 2012 4 commits
  5. 19 Feb, 2012 4 commits
  6. 13 Feb, 2012 1 commit
    • Alexander Larsson's avatar
      Always make offscreen window rgba · 42c2d51a
      Alexander Larsson authored
      This fixes issues where the new default bg of transparent
      didn't work, making offscreen windows black.
      
      I don't think this is a practical performance problem.
      Offscreen windows are rarely used and generally used for
      graphics tricks like alpha anyway.
      42c2d51a
  7. 09 Feb, 2012 4 commits
    • Rui Matos's avatar
      x11: Cancel _NET_WM_MOVERESIZE if we get a matching ButtonRelease · db2eb85e
      Rui Matos authored
      This implements the following part of the EWMH spec:
      
      "The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
      operation by sending such message if they detect the release themselves
      (clients should send it if they get the button release after sending the move
      resize message, indicating that the WM did not get a grab in time to get the
      release)."
      
      In particular, it fixes the case of clicking widgets that use
      gdk_window_begin_[resize|move]_drag*() and the click "sticking", i.e. the
      mouse button getting released but the resize or move operation remaining in
      effect.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=669208
      db2eb85e
    • Alexander Larsson's avatar
      Fix transparency handling with non-double-buffered drawing · 251cffb6
      Alexander Larsson authored
      Sometimes we need to read back the window content into our double
      buffer due to rendering a window with alpha when there is
      no implicit paint or it has been flushed due to non-db drawing
      before.
      
      However, in this case we can't use gdk_cairo_set_source_window as
      it might trigger an implicit paint flush as we detect what we
      think is a direct non-double buffered window draw operation, which
      will flush the implicit paint operation that we're just setting up.
      
      To fix this we use the raw gdk_window_ref_impl_surface operation
      to get the source surface.
      251cffb6
    • Alexander Larsson's avatar
      Fix non-double-buffered drawing · 5d9736fe
      Alexander Larsson authored
      There was a sign issue in a coordinate transform that made us
      flush the wrong region when flushing an implicit paint.
      The non-double buffered drawing would then be drawn over the
      right area, but then at the end of the implicit paint this
      would be overdrawn with the area we didn't properly remove
      from the implicit paint.
      
      Also, the translation from window coords to impl window
      coords is now done before removing any active double
      buffered paints, as these are also in impl window coords.
      5d9736fe
    • Alexander Larsson's avatar
      Make the default background for GdkWindows transparent · fed1cfb1
      Alexander Larsson authored
      With the changes in default CSS to make the default background transparent
      we ran into issues where intermediate GdkWindow (for instance the
      view_window in GtkViewport) where we didn't set an explicit background
      (because before they were always covered). So instead of showing throught
      the transparent windows were showing the default backgroind of the intermediate
      window (i.e. black).
      
      With this change we also needed to fix GtkViewport, as it was previously
      relying on the bin and view windows to cover widget->window so that the
      border was not visible if shadow_type was NONE.
      fed1cfb1
  8. 31 Jan, 2012 2 commits
  9. 30 Jan, 2012 1 commit
  10. 29 Jan, 2012 1 commit
  11. 27 Jan, 2012 2 commits
  12. 26 Jan, 2012 2 commits
  13. 25 Jan, 2012 3 commits
    • Dieter Verfaillie's avatar
      win32: fix gdk_win32_window_raise · fe190770
      Dieter Verfaillie authored
      When calling gtk_window_present(), gdk_win32_window_raise did not
      actually raise the window anymore. Replacing BringWindowToTop() with
      SetForegroundWindow() fixes this.
      
      During testing, we also discovered that sometimes SetForeGroundWindow()
      will (correctly) refuse to raise the window and fail(for example: sometimes
      when dragging a different application at the time of a gtk_window_present()
      call). To prevent a GdkWarning from being produced, usage of the API_CALL
      macro has been removed for this case.
      
      Additional goodies of SetForeGroundWindow:
      - it brings the window to the front when the process owning the
        window to raise is the foreground process (for example when
        gtk_window_present is called from a GtkStatusIcon's activate
        signal handler)
      - it limits itself to flashing the task bar button associated
        with the window if the process owning the window to raise
        is *not* the foreground process (for example when gtk_window_present
        is called from a g_timeout_add callback function)
      
      https://bugzilla.gnome.org/show_bug.cgi?id=665760
      fe190770
    • Javier Jardón's avatar
      104d9cab
    • Alexander Larsson's avatar
      broadway: Properly handle masked websocket messages · fa6ad2ca
      Alexander Larsson authored
      Thanks to Rafal Luzynski for pointing this out.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=656521
      fa6ad2ca
  14. 20 Jan, 2012 1 commit
  15. 19 Jan, 2012 1 commit