1. 18 May, 2014 3 commits
  2. 15 May, 2014 2 commits
  3. 06 May, 2014 1 commit
    • Andrés G. Aragoneses's avatar
      SourceActions: code cleanup · 2ad23085
      Andrés G. Aragoneses authored
      - Removed unused usings.
      - Converted property to auto-property.
      - Use new lambda delegate syntax.
      - Add missing braces in foreach and if blocks, to conform to
      style guidelines.
      - Use a static cast instead of a dynamic cast (as it was not
      checking for null, and could lead to NREs instead of ICEs).
      2ad23085
  4. 05 May, 2014 1 commit
  5. 04 May, 2014 1 commit
  6. 17 Apr, 2014 2 commits
  7. 13 Apr, 2014 2 commits
  8. 06 Apr, 2014 1 commit
  9. 05 Apr, 2014 1 commit
    • Andrés G. Aragoneses's avatar
      Playlists: (refactoring) more progress towards immutability · e4b14cc3
      Andrés G. Aragoneses authored
      PlaylistParser.Parse() was mutable (the result of its execution was
      available at one of the properties of its instance. This can be
      avoided by making Parse() static, and return the result instead
      of just a bool indicating its success (from now on, a null value
      returned means a failure to parse).
      
      To do this, the PlaylistParser class has to be split in two:
      - static class PlaylistParser
      - DTO class ParsedPlaylist
      
      This doesn't only make the code safer, it allows me to remove
      the lock{} inside Parse() method, and makes everything a bit
      more readable and maintainable.
      e4b14cc3
  10. 03 Apr, 2014 2 commits
    • Andrés G. Aragoneses's avatar
      Playlists: tidy · a715b96e
      Andrés G. Aragoneses authored
      Remove some unused usings, fix some indentation and missing braces.
      a715b96e
    • Andrés G. Aragoneses's avatar
      Playlists: refactor PlaylistParser to be less mutable · 47834bb0
      Andrés G. Aragoneses authored
      There's no need to make PlaylistParser.Parse() method depend
      on whether some previous code set the property BaseUri to
      some value beforehand.
      
      All current uses of the setter of the property can simply be
      replaced by a constructor that receives the value for BaseUri.
      By this we avoid any race condition that could be derived from
      reading the object after/before setting the property. Its
      getter access wasn't used at all so we can remove the property
      altogether, leaving the private field for its main usage in
      the Parse() method.
      47834bb0
  11. 02 Apr, 2014 2 commits
    • Andrés G. Aragoneses's avatar
      HACKING: add missing rule about parameter names · 470a3f78
      Andrés G. Aragoneses authored
      There's a mixture of style in Banshee's codebase about param
      names. Sometimes they are written in the same way vars/fields
      are written (under_score notation), but sometimes they use
      camelCaseNotation. Lately I've come to realize that the latter
      is a bit more frequent, so we should write this down ASAP
      before we grow the mixed-style code indefinitely.
      470a3f78
    • Andrés G. Aragoneses's avatar
      MetadataService: refactor SaveHttpStream() with 'using' pattern · 7dfb0b51
      Andrés G. Aragoneses authored
      This method was extremely convoluted because it was checking
      for nulls every time and calling Close() only in the proper
      situations.
      
      By employing the "using" pattern, we can achieve the same with
      less checks and less explicit calls to Close(), as this pattern
      checks for null before disposing, and the Dispose() methods of
      both HttpWebResponse and Stream call Close() underneath.
      
      The code becomes much more readable this way. (And this is also
      safer against resource leaks because the calls to Dispose()
      happen in a finally{} block.)
      7dfb0b51
  12. 31 Mar, 2014 2 commits
  13. 29 Mar, 2014 1 commit
  14. 28 Mar, 2014 1 commit
  15. 27 Mar, 2014 1 commit
    • Dmitriy Petukhov's avatar
      DatabaseSource: fix crash at Rating sync (bgo#727030) · a74b354c
      Dmitriy Petukhov authored
      OnTracksChanged() was iterating the PrimarySources collection,
      and on each iteration there could exist the possibility of making
      the ServiceManager.SourceManager.Sources collection change (and
      PrimarySources is a sub-set of this collection), for example:
      a new rating of 5 stars is set on a track, which makes the
      "Favorites" smart playlist appear (it could be invisible because
      of being empty before).
      
      Even if the super-set of a collection changes without making the
      sub-set change, its enumerator would see it "dirty" (out of sync)
      which would cause an exception, and make Banshee crash. The
      solution to this is make a copy of the PrimarySources sub-set
      before iterating it.
      Signed-off-by: Andrés G. Aragoneses's avatarAndrés G. Aragoneses <knocte@gmail.com>
      a74b354c
  16. 26 Mar, 2014 1 commit
  17. 25 Mar, 2014 1 commit
  18. 22 Mar, 2014 1 commit
  19. 21 Mar, 2014 1 commit
  20. 19 Mar, 2014 3 commits
  21. 18 Mar, 2014 8 commits
  22. 16 Mar, 2014 1 commit
  23. 15 Mar, 2014 1 commit