1. 23 Feb, 2012 1 commit
    • Carlos Garnacho's avatar
      range: Don't perform a GTK+ grab · 170b391e
      Carlos Garnacho authored
      The implicit grab on priv->event_window already warrants that this
      widget is the only one getting events while the button is pressed,
      so avoid the extra GTK+ grab here.
      170b391e
  2. 14 Feb, 2012 3 commits
  3. 27 Jan, 2012 1 commit
  4. 15 Jan, 2012 1 commit
  5. 09 Jan, 2012 1 commit
  6. 14 Dec, 2011 1 commit
  7. 21 Nov, 2011 1 commit
  8. 17 Nov, 2011 1 commit
  9. 16 Nov, 2011 1 commit
  10. 11 Nov, 2011 1 commit
  11. 23 Oct, 2011 1 commit
  12. 21 Oct, 2011 1 commit
    • Cosimo Cecchi's avatar
      GtkRange: use the right widget for coordinate translation · 18a638a7
      Cosimo Cecchi authored
      GtkRange needs to check if its allocation intersects with the resize
      grip allocation (trimming its own allocation if it does).
      In order to do that, it needs to translate its allocation into window
      coordinates, and before that, find the window to whose the allocation
      is relative; code goes all the way finding the right parent widget, but
      then doesn't actually use it when translating the coordinates, leading
      to using the wrong rectangles for the intersection check.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=662308
      18a638a7
  13. 10 Aug, 2011 1 commit
    • Matthias Clasen's avatar
      Make focus rectangles optional · 2ba9c4b4
      Matthias Clasen authored
      This commit introduces a new setting, gtk-visible-focus, backed
      by the Gtk/VisibleFocus X setting. Its three values control how
      focus rectangles are displayed.
      
      'always' is equivalent to the traditional GTK+ behaviour of always
      rendering focus rectangles.
      
      'never' does what it says, and is intended for keyboardless
      situations, e.g. tablets.
      
      'automatic' hides focus rectangles initially, until the user
      interacts with the keyboard, at which point focus rectangles
      become visible.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=649567
      2ba9c4b4
  14. 05 Jul, 2011 1 commit
  15. 12 Apr, 2011 1 commit
  16. 16 Mar, 2011 1 commit
    • Cosimo Cecchi's avatar
      range: allow stepper-spacing > 0 and trough-under-steppers = TRUE · 9205abe3
      Cosimo Cecchi authored
      Commit 4bb3d644 introduced a limitation
      to GtkRange style properties; when stepper-spacing is > 0,
      trough-under-steppers is automatically set to FALSE; this means that
      setting a spacing between the steppers (e.g. the scrollbar buttons) and
      the trough (i.e. the area over which the slider is free to move) would
      make the buttons always get the full allocation on the !orientation
      direction.
      The rationale is without this limitation, you would get an area which
      seems clickable, but it's actually not.
      
      While this is true, and undesirable, for big stepper spacings, themes
      that use trough-under-steppers (which is TRUE by default anyway),
      might want to set smaller spacings to avoid drawing a double line between
      the button and the slider borders.
      
      To add confusion, the documentation got it flipped, i.e. it stated
      setting a positive stepper-spacing would set trough-under-steppers to
      TRUE (which would also make the behavior expected by commit
      4bb3d644 impossible).
      
      I don't think hardcoding either of the two limitations is a good thing.
      We should let themes handle this instead, and remove this limitation. If
      you want the old behavior, you can manually set trough-under-steppers to
      FALSE if you set a positive stepper-spacing in your theme.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=644777
      9205abe3
  17. 03 Mar, 2011 2 commits
  18. 23 Feb, 2011 1 commit
  19. 30 Jan, 2011 1 commit
  20. 24 Jan, 2011 1 commit
  21. 20 Jan, 2011 1 commit
  22. 19 Jan, 2011 1 commit
  23. 15 Jan, 2011 2 commits
  24. 06 Jan, 2011 1 commit
    • Tristan Van Berkom's avatar
      Fixed issues with "hierarchy-changed" signal. · fdba9f28
      Tristan Van Berkom authored
      GtkFileChooserDefault watches the toplevel and montitors "set-focus"
      signal on it... however the connection needs to be remade when the
      GtkFileChooserDialog is in an embedded toplevel.
      
      Measure's taken: GtkWindow propagates hierarchy changes when
      _gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
      unsets the widget's parent window earlier in the function so that
      the possible hierarchy change is still able to properly access the hierarchy.
      
      GtkFileChooserDefault checks if the "new" toplevel is indeed
      gtk_widget_is_toplevel() but not the old one, GtkRange has been
      updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
      vfunc, other classes already do this properly.
      fdba9f28
  25. 05 Jan, 2011 3 commits
  26. 04 Jan, 2011 3 commits
  27. 13 Dec, 2010 1 commit
  28. 02 Dec, 2010 1 commit
  29. 01 Dec, 2010 1 commit
  30. 13 Nov, 2010 1 commit
  31. 10 Nov, 2010 1 commit
  32. 30 Oct, 2010 1 commit