1. 08 Dec, 2017 1 commit
  2. 25 Nov, 2017 1 commit
  3. 24 Nov, 2017 4 commits
  4. 23 Nov, 2017 1 commit
  5. 20 Nov, 2017 8 commits
  6. 19 Nov, 2017 1 commit
  7. 18 Nov, 2017 10 commits
  8. 17 Nov, 2017 1 commit
  9. 01 Oct, 2017 1 commit
  10. 09 Sep, 2017 1 commit
  11. 16 Jul, 2017 2 commits
    • Kai Willadsen's avatar
      filediff: Reestablish focus on comparison refresh (bgo#784436) · 5640a5b3
      Kai Willadsen authored
      The way that comparison refresh disables and reenables textview
      sensitivity and handlers, it destroys pane focus and stops us from
      updating our cursor data (e.g., what are the next and previous chunks).
      This can lead to a situation where our comparison results have changed,
      but we haven't updated our cursor details. Because next/previous actions
      (among others) don't need a currently focused pane, these will try to
      run with stale data and break.
      The fix here, while it seems odd, is to refocus the last focused pane
      (if there is one) on comparison refresh. The focus change causes the
      cursor structure to re-update, and the cursor data used by actions is no
      longer stale.
    • Kai Willadsen's avatar
      matchers.helpers: Schedule our result check to the main scheduler · 5f2c23f5
      Kai Willadsen authored
      Previously we scheduled the result check to the GLib mainloop in an idle
      handler. This had the downsides that we would spin constantly waiting
      for results, and while waiting for results we weren't showing as busy.
      In 68bf29, we changed the result checker to run on a 10 msec timeout,
      which solved the busy looping, but delayed results slightly and still
      didn't show our normal busy indicator.
      This commit switches both these things up so that we now run our results
      check in the main application scheduler (which runs as a GLib idle
      handler) and therefore we get correct a busy indicator. Doing this
      brings back the busy-loop CPU usage issue, so here we also switch up
      the result retrieval so that we actually block for 1ms when trying to
      retrieve a result, instead of not waiting at all. This is quite
      unpleasant, but it's effective.
  12. 02 May, 2017 1 commit
    • Kai Willadsen's avatar
      filediff, dirdiff: Fix busted overlay scrolling change · 573bdb75
      Kai Willadsen authored
      The change in 1915de was supposed to just move overlay scrolling
      disablement for dirdiff; instead it moved it for filediff and removed
      it for dirdiff. This is the other part of the changeset, removing the
      lagging code in filediff and actually disabling overlay scrolling in
      dirdiff in the UI file.
  13. 01 May, 2017 1 commit
    • Kai Willadsen's avatar
      filediff: Dodge divide-by-zero in some edge cases · 033cae97
      Kai Willadsen authored
      I'm not totally clear on when this happens, but in some cases (e.g.,
      during slow file loading, when line revalidation is taking a while) we
      occasionally get lines with a height of zero. Since this adjustment
      exists mainly for smoother scrolling, it's easiest to just avoid the
      zero rather than doing anything complicated.
  14. 29 Apr, 2017 2 commits
    • Kai Willadsen's avatar
      filediff: Fix race condition on scrolling to first chunk (bgo#780625) · d6b8d241
      Kai Willadsen authored
      When we load a comparison, we scroll to the first difference. If the
      first difference is on the first line of the file, we hit a race
      condition (though reliably triggerable in some cases) where we set the
      `next` attribute of our cursor and schedule a go_to_chunk on it, but
      then our cursor changed callback kicks in and re-sets the `next`
      attribute, causing us to go to the *second* difference.
      There's no obvious reason why we need to set the cursor chunk here.
      History vaguely suggests that it's because we weren't getting cursor
      callbacks, so set up the necessary state manually. However, we can
      just pass the actual chunk we have decided we want to go to, instead
      of modifying the cursor itself, which seems a lot safer.
    • Kai Willadsen's avatar
      filediff: Remove obsolete cursor handling for identical files case · f8d38146
      Kai Willadsen authored
      This handling was added for the case when files are identical and so
      there's no chunk to go to. Previously, we had cursor signals
      disconnected at this point, so this clause existed just so that we would
      have a correct line/column number in the status bar. With more recent
      changes we now get our cursor handling triggered anyway, so this can go.
  15. 25 Apr, 2017 5 commits
    • Kai Willadsen's avatar
      filediff: Fix sync to scroll last line on to screen · 4d5df7aa
      Kai Willadsen authored
      Because we're using exclusive end point for chunks, and because
      GtkTextBuffer will give you the last character on the last line if you
      ask for a point beyond the end of the buffer, we just add a simple
      "how far through my synced line am I" adjustment to handle scrolling
      the last line of a file into view.
    • Kai Willadsen's avatar
      filediff, misc: Align syncpoints at top/bottom better (bgo#780608) · 6b71cde5
      Kai Willadsen authored
      The issue here addressed by this change is that when we get scroll near
      the top or bottom of a pane, and the corresponding pane that gets its
      scroll set has more lines in the top-/bottom-most chunk, we won't ever
      scroll the whole dependent chunk in to view.
      For example, in a situation where we're scrolling to the bottom of a
      comparison in the left pane, with the right pane being set by this
      sync, and we have an end-of-file that looks like:
      viewport  left   right
          |     x      x
          |     x      x
          |     x      x
          |     a      b
          _     EOF    b
      the last two lines of b will often not be scrolled into view. The reason
      here is that the way we decide how to align the right pane is to find
      the middle of the left pane, figure out what chunk is there, find the
      corresponding chunk in the right pane and then try to align those lines.
      This means that the start and end of a file are aligned according to
      whatever chunk is half way up the page. This is fine and good, except
      that if e.g., the first `x` above is in the middle of the screen,
      there's no way that you can scroll the left pane down far enough to be
      able to see the bottom of the right pane.
      The fix here is that we adjust the syncpoint that we use according to
      where we are in the document. If we're showing the first half page, we
      scale our syncpoint to be toward the top of the page; if we're showing
      the last half page we scale the syncpoint towards the bottom. For most
      normal documents, the majority of the document will have a syncpoint
      of 0.5 (the middle of the screen) which is what we've always used.
    • Kai Willadsen's avatar
      filediff: Add a new callback locking helper and use for scrolling · 854e79d7
      Kai Willadsen authored
      The main benefit of this, other than looking nicer in use, is that we're
      doing our locking in a try/finally, so tracebacks in the scrolling code
      won't leave us with a permanently held scroll lock.
    • Kai Willadsen's avatar
    • Kai Willadsen's avatar
      filediff: PEP8 and parenthesis removal · 97517193
      Kai Willadsen authored