1. 04 Feb, 2014 6 commits
  2. 31 Jan, 2014 2 commits
  3. 28 Jan, 2014 2 commits
  4. 23 Jan, 2014 1 commit
  5. 20 Jan, 2014 3 commits
  6. 18 Jan, 2014 1 commit
  7. 17 Jan, 2014 1 commit
    • Matthias Clasen's avatar
      Add a setting for dialog headers · 3701de14
      Matthias Clasen authored
      This setting will let us keep traditional appearance
      of dialogs on platforms where this is expected.
      The new setting is called gtk-dialogs-use-header, backed
      by the Gtk/DialogsUseHeader xsetting.
  8. 14 Jan, 2014 1 commit
  9. 13 Jan, 2014 2 commits
  10. 09 Jan, 2014 1 commit
  11. 04 Jan, 2014 2 commits
  12. 22 Dec, 2013 1 commit
    • Matthias Clasen's avatar
      Redo header bar decorations once more · 7e1a4800
      Matthias Clasen authored
      Applications need a way to fix or adapt the decoration layout,
      for situations like split header bars. Setting the layout from
      the theme with a style property did not offer a good way to do
      this, and the ::show-close-button property does not provide
      fine-grained control.
      To improve the situation, move the layout string to a property of
      GtkHeaderBar which is backed by a setting. This allows platforms to
      set a default button layout independent of the theme, while applications
      can override the default.
      The style GtkWindow style property is now deprecated and ignored.
  13. 13 Dec, 2013 1 commit
  14. 05 Dec, 2013 2 commits
  15. 04 Dec, 2013 1 commit
  16. 25 Nov, 2013 2 commits
  17. 22 Nov, 2013 1 commit
  18. 18 Nov, 2013 1 commit
    • Carlos Garnacho's avatar
      gdk: Ignore crossings generated by passive grabs when resetting scroll axes · fee754e0
      Carlos Garnacho authored
      Passive grabs may take pointer focus out of the application, even though
      the pointer didn't leave the window, but those events still trigger resetting
      of the scroll axes. This is most visible with compiz, and possibly other
      reparenting WMs, where passive grabs happen on the WM-managed window that
      is a parent of the application toplevel.
      As it is not possible to have scrolling happening on the timespan a passive
      grab takes action, it is entirely safe for GTK+ to assume none happened if
      it gets a crossing event of that nature.
  19. 16 Nov, 2013 2 commits
    • Carlos Garnacho's avatar
      x11: Add extra debug spew on XI2 crossing and button events · 962415ae
      Carlos Garnacho authored
      This information will be useful in case someone stumbles on a situation
      similar to https://bugzilla.gnome.org/show_bug.cgi?id=699574, so we can
      figure out where do the crossing events come from or go to easily.
    • Carlos Garnacho's avatar
      gdk: be more selective resetting scroll events · 4168c3ca
      Carlos Garnacho authored
      It's been reported in several applications that scrolling feels jerky
      since commit cc7b3985.
      Investigation reported that the combination of passive 4-7 button grabs
      on the toplevel and the presence of native subwindows might trigger
      too often crossing events from the child window to the toplevel and
      back as scroll "buttons" trigger the passive grab. Those crossing events
      would reset the scroll valuators rendering scrolling from jerky on
      touchpads (where there's intermediate smooth events between the emulated
      button ones) to ineffective on regular mouse wheels (where the crossing
      event would reset the valuators right before the single smooth scroll
      event we get is delivered)
      So, only reset scroll valuators when the pointer enters the toplevel
      (we only care about this when the pointer is on the window after it's
      been possibly scrolling somewhere else), and it doesn't come from an
      The situations where this happened varied though, the native subwindow
      could be one created explicitly by the application, or created indirectly
      through gdk_window_ensure_native(). The latter was mainly the case for
      evolution (through gtk_selection_set_owner()) and any GtkScrolledWindow
      under the oxygen-gtk3 theme (through gdk_window_set_composited())
  20. 14 Nov, 2013 1 commit
  21. 12 Nov, 2013 1 commit
    • Owen W. Taylor's avatar
      Handle recursion from motion event handlers · f50a3af1
      Owen W. Taylor authored
      If a motion event handler (or other handler running from the flush-events
      phase of the frame clock) recursed the main loop then flushing wouldn't
      complete until after the recursed main loop returned, and various aspects
      of the state would get out of sync.
      To fix this, change flushing of the event queue to simply mark events as
      ready to flush, and let normal event delivery handle the rest.
  22. 25 Oct, 2013 2 commits
    • Matthias Clasen's avatar
      Respect deprecated button images setting · c46aca46
      Matthias Clasen authored
      I have been convinced that it is a bad idea to change the behaviour
      at the same time as deprecating it, so go back to respecting the
      Gtk/ButtonImages xsetting in buttons created with
      gtk_button_new_from_stock() when it is set.
      The setting as well as the function are still deprecated, and the
      default value of the setting will remain FALSE.
    • Matthias Clasen's avatar
      Respect deprecated menu images setting · 627a0368
      Matthias Clasen authored
      I have been convinced that it is a bad idea to change the behaviour
      at the same time as deprecating it, so go back to respecting the
      Gtk/MenuImages xsetting in GtkImageMenuItem when it is set.
      The setting as well as the widget are still deprecated, and the
      default value of the setting will remain FALSE.
  23. 23 Oct, 2013 1 commit
  24. 21 Oct, 2013 1 commit
  25. 26 Sep, 2013 1 commit