1. 06 Apr, 2017 1 commit
  2. 30 Mar, 2017 4 commits
  3. 19 Mar, 2017 1 commit
  4. 18 Mar, 2017 1 commit
  5. 15 Mar, 2017 1 commit
  6. 14 Mar, 2017 2 commits
  7. 11 Mar, 2017 7 commits
    • Kai Willadsen's avatar
      dirdiff: Fix GTK+ allocation breakage, part X of Y · 0396666b
      Kai Willadsen authored
      I'm not going to dive into why this fixes our allocation warnings. You
      can't make me. I assume it has something to do with animation callbacks
      and private GtkCSSGadget API and complete disregard for your users.
    • Kai Willadsen's avatar
      diffmap: Call the wrong function, for GTK+'s insanity · ef3ba1b8
      Kai Willadsen authored
      Even though queuing a resize here should be totally fine, GTK+
      completely loses it and complains about allocation issues. Given that
      this is code that should basically never be necessary in our layout
      (i.e., every time a scrollbar gets a size-allocate, we can basically
      guarantee that DiffMap will as well) and given how annoying these
      warnings are, we'll give in and just do the wrong thing.
    • Kai Willadsen's avatar
      diffmap: Call our correct parent init · 7277d87f
      Kai Willadsen authored
    • Anders Jonsson's avatar
      Update Swedish translation · 6149926d
      Anders Jonsson authored
    • Kai Willadsen's avatar
      filediff: Place cursor at the start of a replaced chunk · 27fd840d
      Kai Willadsen authored
      This is an ergonomics improvement. In most cases this won't matter at
      all. It's sort of more intuitive to keep doing what we used to do, and
      place the cursor after the chunk that's just had the action done to
      it... after all that's what would happen if you'd just pasted the chunk.
      However, it doesn't really feel right to me. In particular, it's a pain
      when pulling chunks, because you've just pulled a chunk into your
      current pane, and then your cursor is moved off this chunk. Now maybe
      that's okay because you're done with it, but maybe you're not. You may
      want to edit that chunk further, or (in three-way diff cases) you may
      want to then push that chunk to the other side (i.e., in center, pull
      from left, push to right).
      If this doesn't end up working out, the change is trivial to revert.
      However, for now this feels more correct to me.
    • Kai Willadsen's avatar
    • Kai Willadsen's avatar
      meldwindow: Work around broken UIManager life cycle again (bgo#779880) · 0498e704
      Kai Willadsen authored
      This is very similar to bgo#755407, and the "fix" is basically the same,
      even though the reproduction is different. This looks like it was
      reintroduced when we removed the tabs menu, because the code that was
      previously calling ensure_update() was removed along with the tab menu
      This was fine in most cases, but resurfaced with closing the second of
      multiple windows. I have no desire to find out why, and there's no
      chance of getting this fixed in GTK+, thus this hack.
  8. 10 Mar, 2017 5 commits
  9. 08 Mar, 2017 1 commit
  10. 07 Mar, 2017 1 commit
  11. 28 Feb, 2017 1 commit
  12. 26 Feb, 2017 1 commit
  13. 23 Feb, 2017 1 commit
  14. 19 Feb, 2017 1 commit
    • Kai Willadsen's avatar
      filediff: Use cursor position for EOF chunk deletion (bgo#778856 take 2) · 18b6e4bd
      Kai Willadsen authored
      A problem with the previous approach, demonstrated by the test cases
      added, is that GtkTextView inexplicably doesn't bother to add newlines
      that match the existing ones while editing a file.
      The new approach is to avoid doing this calculation manually ourselves,
      and instead rely on cursor position manipulation, since that
      will/should always result in us ending up on the last non-linebreak
      character of the previous line.
  15. 18 Feb, 2017 3 commits
  16. 11 Feb, 2017 4 commits
  17. 06 Feb, 2017 1 commit
  18. 25 Jan, 2017 2 commits
  19. 22 Jan, 2017 1 commit
  20. 21 Jan, 2017 1 commit