1. 25 Mar, 2018 3 commits
  2. 24 Mar, 2018 5 commits
  3. 23 Mar, 2018 1 commit
  4. 22 Mar, 2018 3 commits
  5. 18 Mar, 2018 1 commit
  6. 16 Mar, 2018 1 commit
  7. 12 Mar, 2018 1 commit
  8. 09 Mar, 2018 1 commit
  9. 06 Mar, 2018 1 commit
  10. 05 Mar, 2018 1 commit
  11. 02 Mar, 2018 1 commit
  12. 27 Feb, 2018 1 commit
  13. 26 Feb, 2018 1 commit
  14. 25 Feb, 2018 3 commits
  15. 24 Feb, 2018 1 commit
    • Kai Willadsen's avatar
      meldwindow: Fake out our progress spinner on Windows (#133) · a36963e0
      Kai Willadsen authored
      On Windows, the spinner repaint is so slow (and on a high enough idle
      priority) that it stops us making any comparison progress. This looks
      like a Cairo problem, but either way it's not something we can really
      fix in Meld, so we're doing the dumbest possible thing here and shimming
      out the spinner.
  16. 22 Feb, 2018 5 commits
  17. 21 Feb, 2018 1 commit
  18. 20 Feb, 2018 1 commit
  19. 18 Feb, 2018 1 commit
  20. 17 Feb, 2018 2 commits
    • Kai Willadsen's avatar
      filediff: Don't reset saving state from while-closing saves · c645afe6
      Kai Willadsen authored
      The bug here looks something like:
       * Compare files a, b and c
       * Modify b and c
       * Close the tab; when prompted to save, save both b and c
       * Both files will be saved, but the tab won't close
      The problem here was that we were resetting the state to Normal when
      a save succeeded. This doesn't cause an issue if you're only saving
      one file, but if you're saving multiple then the second save to run
      *won't* be in a Closing state in its saved callback, and so won't
      try to close the tab.
    • Kai Willadsen's avatar
      Make our state saving an enum, for both sanity and better debugging · c2b29ade
      Kai Willadsen authored
      This way at least we get meaningful names when debugging these state
      transitions. Also, it's better in every way.
      I've used an IntEnum here just so that I keep the state-changed signal
      signature, though there's no reason that needs to remain the same,
  21. 11 Feb, 2018 1 commit
  22. 10 Feb, 2018 4 commits
    • Kai Willadsen's avatar
      undo: Use py3k-style super · 120b945f
      Kai Willadsen authored
    • Kai Willadsen's avatar
      undo: Ensure that each buffer has a starting checkpoint (#159) · 09ecc418
      Kai Willadsen authored
      With this change, clearing the undo sequence will still ensure that each
      buffer starts with an undo checkpoint.
      Previously, this was *almost* always the case, but on reload of an
      individual file we would clear out the checkpoints for all files, and
      only re-checkpoint the file we reloaded. This caused several weird
      issues, chief among which was that you cause a file to show as being
      changed (along with the action sensitivity issues accompanying this).
    • Kai Willadsen's avatar
      undo: Move all sequence reset logic into our clear() helper · 23ea9375
      Kai Willadsen authored
      This is possible because of the getattr changes in our undo helpers, and
      is about to be useful for checkpoint state maintenance.
    • Kai Willadsen's avatar
      undo: Take and keep track of the buffers an UndoSequence references · eb614e7f
      Kai Willadsen authored
      We're using weakrefs here because I'm paranoid about the lifecycle
      issues with GTK+ + Python refcounting fun.
      Starting a group now means dereferencing and re-referencing these
      buffers, which isn't great, but is probably the least-bad option. The
      other choice here would be to give groups a reference to their parent
      UndoSequence, and have the buffers lookup follow that, which seems...
      more complicated and confusing.