1. 18 Apr, 2018 1 commit
  2. 17 Apr, 2018 1 commit
    • Daniel Boles's avatar
      Range: Add should_invert_move() for scrolls & keys · 9b011081
      Daniel Boles authored
      This will be used in subsequent commits to fix the sign by which the
      value is changed in response to directional scroll or keypress events.
      
      The idea is: you have a movement to make – in the form of a delta that
      follows widget directions, i.e. −1 means left or up, +1 means right or
      down – and you want to know whether that delta needs to be inverted in
      order to produce the intuitively expected directional change of :value.
      
      The existing should_invert() is not sufficient: it just determines
      whether to invert visually, but we need more nuance than that for input.
      
      To answer that – while not doubling up the work for scrolls and keys – I
      add a helper should_invert_move(), which considers other relevant state:
      
       • A parallel movement on priv->orientation should just use the existing
         should_invert(), which already worked OK for this case (not others).
      
       • Movements on the other orientation now depend on priv->orientation:
      
          ◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
            widget coords) always means increase value & vice-versa. This was
            done in get_wheel_delta(), but move it here for use with keys too.
      
          ◦ For a vertical Range, ignore :invert as it’s only relevant to the
            parallel orientation. Do not care about text direction here either
            as RTL locales do not invert number lines, Cartesian plots, etc.
      
      This returns TRUE if the delta should be inverted before applying to the
      value, and we can now use this function in both scroll and key handlers.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=407242
      https://bugzilla.gnome.org/show_bug.cgi?id=791802
      9b011081
  3. 19 Dec, 2017 2 commits
  4. 14 Oct, 2017 1 commit
    • Daniel Boles's avatar
      Range: Fix inverted horizontal scroll wheel events · 91064360
      Daniel Boles authored
      Bug 737175 aimed to ensure that scrolling up on a horizontal range would
      result in its value increasing, as that’s what users intuitively expect.
      However, its commit 416c370d meant that,
      if the event gives scroll deltas, we inverted our delta unconditionally.
      
      So it broke horizontal scrolling: scrolling left moved the slider right…
      
      We must only invert if using dy as delta. dx already has the right sign,
      so inverting it was wrong.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=788905
      91064360
  5. 11 Oct, 2017 1 commit
  6. 26 Jul, 2017 1 commit
  7. 27 Feb, 2017 1 commit
  8. 01 Feb, 2017 1 commit
  9. 08 Nov, 2016 1 commit
  10. 04 Sep, 2016 1 commit
  11. 29 Aug, 2016 1 commit
  12. 08 Jun, 2016 1 commit
  13. 06 Jun, 2016 1 commit
  14. 30 May, 2016 1 commit
  15. 12 May, 2016 1 commit
  16. 29 Apr, 2016 1 commit
    • Matthias Clasen's avatar
      box gadget: Redo expand flag handling · 21487089
      Matthias Clasen authored
      We only keep one align flag per child, so it seems odd to
      keep separate h/v expand flags. Just keep one expand flag
      and interpret it according to orientation. Allow setting
      the expand flag for child widgets too, though, so we can
      make widget expand without interfering with the recursive
      widget expand flag.
      
      Update all callers.
      
      Use the new possibility of expanding child widgets to make
      the label of check and radio buttons expand. This fixes
      unexpected behavior of these widgets in RTL in some places.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=765742
      21487089
  17. 27 Mar, 2016 1 commit
  18. 26 Mar, 2016 2 commits
    • Matthias Clasen's avatar
      range: Simplify highlight allocation · 7fe1037e
      Matthias Clasen authored
      Since we are really only interested in the center point of the
      slider allocation, the pre-computed slider geometry is perfectly
      fine, just use it always. This avoids the complication with
      gadget visibility.
      7fe1037e
    • Matthias Clasen's avatar
      range: Avoid miscalculating highlight allocation · e33188ad
      Matthias Clasen authored
      The slider gadget may be turned invisible as side-effect of
      gtk_range_calc_slider(). If that happens,
      gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
      which leads us to calculate a negative allocation for the highlight
      node. Avoid this, by just reusing our already calculated slider
      allocation in this case (it is not technically the same as the
      content, allocation, but the difference hardly matter here.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764022
      e33188ad
  19. 11 Mar, 2016 3 commits
  20. 09 Mar, 2016 1 commit
    • Matthias Clasen's avatar
      range: Fix gadget state propagation · fa48dbf1
      Matthias Clasen authored
      The contents node was not getting state updates at all, and the
      trough node was missing some state updates as well, because we
      were not calling update_trough_state() in all the places where
      it is needed.
      fa48dbf1
  21. 06 Mar, 2016 8 commits
  22. 05 Mar, 2016 3 commits
  23. 04 Mar, 2016 1 commit
  24. 03 Mar, 2016 1 commit
  25. 01 Mar, 2016 1 commit
  26. 29 Feb, 2016 2 commits