1. 27 Feb, 2016 2 commits
  2. 26 Feb, 2016 1 commit
  3. 25 Feb, 2016 2 commits
  4. 20 Feb, 2016 2 commits
  5. 15 Feb, 2016 1 commit
  6. 12 Feb, 2016 1 commit
  7. 04 Feb, 2016 2 commits
  8. 27 Jan, 2016 1 commit
    • Allison Ryan Lortie's avatar
      Tweak startup-notification after the first window · 0d109867
      Allison Ryan Lortie authored
      Presently, Gtk will only send a startup notification completion message
      for the first window that is shown.  This is not good for the case of
      GtkApplication, where we are expected to participate in
      startup-notification for all windows.
      
      We have avoided this problem by manually emitting the startup complete
      message from after_emit in GtkApplication.
      
      Unfortunately, this causes problems for windows that are shown with a
      delay.  It is also a dirty hack.
      
      The reason for the original behaviour is simple: there is a static
      boolean in gtkwindow.c which controls it.  We remove this.
      
      Instead, clear the startup notification ID stored in GDK when sending
      the completion message.  GtkApplication will re-set this the next time
      an event comes in which needs startup-notification handling.  In the
      non-GtkApplication case, newly shown windows will still not send the
      message, since the cookie will have been cleared.
      
      Finally, we remove the hack from GtkApplication's after_emit.
      
      This will probably cause some regressions in terms of lingering startup
      notification messages.  The correct solution here is to always use
      gtk_window_present(), including when merely opening a new document (with
      a new tab, for example).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=690791
      0d109867
  9. 26 Jan, 2016 1 commit
  10. 19 Jan, 2016 2 commits
  11. 18 Jan, 2016 2 commits
  12. 13 Jan, 2016 1 commit
  13. 08 Jan, 2016 7 commits
    • Matthias Clasen's avatar
      x11: Ensure we have a dnd-ask cursor · 04a9b5b5
      Matthias Clasen authored
      We use this for DND, so make sure that we fall back to some other
      cursor if this one isn't present.
      04a9b5b5
    • Carlos Garnacho's avatar
      x11: Initialize GdkWindowAttr struct memory · 23b629e2
      Carlos Garnacho authored
      Valgrind complains about jumps based on uninitialized values
      otherwise.
      23b629e2
    • Matthias Clasen's avatar
      Avoid an X error · b94f30bb
      Matthias Clasen authored
      We are getting the mime data destroy notify called when we
      destroy the surface in finalize. Trying to set the XSync counters
      at this time is a) pointless and b) yielding an X error because
      the counters have already been destroyed.
      To avoid this, unhook the damage tracking before destroying
      the surface.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=760188
      b94f30bb
    • Matthias Clasen's avatar
      x11: Fix damage tracking hack · 4d60b5b1
      Matthias Clasen authored
      We are setting mime data with a destroy notify on the cairo
      surface to get notified when cairo registers damage for the
      surface (in that case, it clears the mime data, calling the
      destroy notify). Unfortunately, the destroy notify is also
      called when we remove the mime data ourselves, which was
      not intentional.
      
      Use a flag in the window impl struct to ignore the callback
      when we are clearing the hook.
      4d60b5b1
    • Matthias Clasen's avatar
      x11: Simplify drag cancel animation setup · 709cc086
      Matthias Clasen authored
      Instead of creating an intermediate pixbuf, just render
      the window surface onto the new surface. Doing things this
      way lets us avoid the cairo_surface_mark_dirty() call in
      gdk_pixbuf_get_from_window(), which is not generally safe
      to call on 'random' surfaces - it asserts that the surface
      has no mime data attached, and the X11 backend uses mime
      data for damage tracking purposes...
      709cc086
    • Matthias Clasen's avatar
      x11: Keep the drag window alive longer · ea0084cd
      Matthias Clasen authored
      We destroy the widget that is wrapped around the drag window
      when the object data on the drag context gets cleared. Destroying
      the window before that happens leads to unpleasantries. E.g. we may
      try to access the frame clock, which doesn't exist anymore, and
      things go downhill from there. So, keep the window alive for
      a little longer.
      ea0084cd
    • Ben Gamari's avatar
      gdkwindow-x11: Ensure that extended update counter is freed · fa66b271
      Ben Gamari authored
      I believe this lead to rampant leakage of SyncCounters by
      gnome-terminal.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=760188
      fa66b271
  14. 06 Jan, 2016 1 commit
  15. 21 Dec, 2015 1 commit
  16. 16 Dec, 2015 3 commits
  17. 14 Dec, 2015 3 commits
  18. 13 Dec, 2015 3 commits
    • Matthias Clasen's avatar
      x11: Implement drag cancel animation · 23b2b493
      Matthias Clasen authored
      Showing the drag cancel animation can be done in the X11
      drag context implementation now that we hold the drag
      window there, and have the start coordinates.
      
      Since we can't control if and when the application destroys
      the drag widget, we take a snapshot of the window contents
      and display that during the animation. This should be good
      enough for all practical purposes.
      23b2b493
    • Matthias Clasen's avatar
      x11: Store drag start coordinates · ed89e5f6
      Matthias Clasen authored
      These will be used in later commits.
      ed89e5f6
    • Matthias Clasen's avatar
      gdk: Allow passing the start coordinates in drag_begin · 268c7a3e
      Matthias Clasen authored
      Add a variant of gdk_drag_begin that takes the start position
      in addition to the device. All backend implementation have been
      updated to accept (and ignore) the new arguments.
      
      Subsequent commits will make use of the data in some backends.
      268c7a3e
  19. 08 Dec, 2015 2 commits
  20. 02 Dec, 2015 1 commit
  21. 17 Nov, 2015 1 commit