1. 20 Jul, 2015 1 commit
  2. 17 Jul, 2015 1 commit
    • Bertrand Lorentz's avatar
      Update for dbus-sharp 0.8.1 & dbus-sharp-glib 0.6 · 37f949bc
      Bertrand Lorentz authored
      We now require both dbus-sharp 0.8.1 and dbus-sharp-glib 0.6.
      
      Switching to >=0.8 dbus-sharp was necessary as a first step
      towards fixing bgo#630110 ("Get single instance and remote
      control working on Win32"). But it's rather better to already
      require 0.8.1 instead of 0.8, because 0.8 had regressions (see
      bgo#725446).
      
      These new versions of these dependencies have API/ABI breaks, so
      then their version in their pc files is raised from 1.0 to 2.0.
      
      Switching to these versions allow us to also make some cleanups:
      
      We were using an obsolete Bus.Session.Register which required a bus
      name, and it's now gone. This allows us to remove some
      DBusServiceManager.RegisterObject overloads that become unnecessary.
      
      As an additional consequence, we don't need the DBusExportable attribute
      anymore. It was used by classes implementing IDBusExportable to indicate
      their service name, which was then used for the bus name.
      37f949bc
  3. 09 Jul, 2015 1 commit
    • Stephan Sundermann's avatar
      ThickClient: fix left menu in gtk3.14 (bgo#749960) · 5aef9d43
      Stephan Sundermann authored
      Rendering of the left sources panel got broken
      somewhere between gtk 3.10 and gtk 3.14, as some
      treeview rendering mechanisms might have changed:
      now OnRender is not called anymore when the width
      is 0; so let's call the base implementation of
      OnGetPreferredWidth() here instead.
      
      This fixes the main glitch about using Banshee
      2.9.x in Ubuntu 15.04, for example, which already
      bundles gtk 3.14.x.
      5aef9d43
  4. 07 Jul, 2015 4 commits
  5. 06 Jul, 2015 2 commits
  6. 03 Jul, 2015 1 commit
    • Andrés G. Aragoneses's avatar
      Revert "Migo: Fixed parsing RSSs with BOM (bgo#727432)" · 1bb41479
      Andrés G. Aragoneses authored
      This reverts commit 27f1135e.
      
      There were some problems with this patch:
      
      a) When improving the version that Marcin posted in bugzilla,
      in order to not hardcode UTF8 encoding, I incorrectly placed
      this logic inside an if block like this:
      
       if (s.StartsWith("<?xml")) {
      
      Given that the logic to remove the bom also asks for
      
       if (s.StartsWith(bom)) {
      
      You would think that the logic added to fix this bug
      would simply not work (because the condition that made
      the code flow enter into the parent block would make
      the second condition FALSE).
      
      However, surprisingly enough, the bom from the podcast
      example in bugzilla [0] is parsed as UTF8 and UTF8's
      ByteOrderMark's length is 1, and Mono returns true for
      both of the conditions above, even if bom is obviously
      not "<" (the first character of the "<?xml" string to
      check if the content is XML.
      
      I still don't understand how can this be possible, but
      the consequence of it is that the content is stripped
      from its first character, so all XML feeds received
      that started with "<?xml" were converted to a string
      starting with "?xml", which clearly resulted in a
      parsing error.
      
      Not sure if this is a Mono bug, and not sure this is
      fixed in newer versions, but with the version I'm using
      now (3.2.8) I cannot reproduce bug 727432, and this is
      a very widely used version of Mono (it comes with
      Ubuntu 14.04 LTS, 14.10, and 15.04). So I'm reverting
      the fix for this (until we figure out a better fix, and
      the exact environment to reproduce it), otherwise many
      more podcasts would be broken.
      
      [0] http://podcast.dr.dk/p1/rssfeed/orientering.xml
      1bb41479
  7. 30 Jun, 2015 1 commit
  8. 27 Jun, 2015 1 commit
    • Andrés G. Aragoneses's avatar
      SourceMessage: fix race in access to actions collection (bgo#751582) · 7ad6e330
      Andrés G. Aragoneses authored
      This foreach() loop had the potential problem of a typical race
      throwing a 'System.InvalidOperationException: Collection was modified;
      enumeration operation may not execute.'
      
      The normal thing to do in these cases is just to make a copy of the
      collection (via the .ToArray() method, for instance), at the
      beginning of the loop. However, this approach alone:
      
      a) would have presented a new race between the check for null
      and the call to the ToArray method.
      b) wouldn't have worked at compile time because IEnumerable<X>
      doesn't have this method (List<X> does).
      
      The proper way to fix (a) involves also avoiding to have
      a null value. How? Initializing the field always at
      construction time of the SourceMessage class.
      
      This has the good side-effect of being able to remove all
      null-checks around this field and its wrapper property.
      
      WRT (b) we could have created a new list at the beginning
      of the foreach loop, but it's more practical to just do the
      copy in the SourceMessage class, because, in the end, a read
      access should also involve lock()ing, otherwise writers to
      the collection could race with the readers of it.
      7ad6e330
  9. 21 Jun, 2015 3 commits
  10. 02 Jun, 2015 1 commit
  11. 29 May, 2015 2 commits
  12. 28 May, 2015 2 commits
  13. 26 May, 2015 1 commit
  14. 25 May, 2015 1 commit
  15. 09 May, 2015 3 commits
  16. 15 Dec, 2014 4 commits
  17. 12 Dec, 2014 2 commits
  18. 15 Aug, 2014 1 commit
  19. 11 Aug, 2014 1 commit
    • Nicholas Little's avatar
      Dap.Mtp: Improve status logging on load (bgo#734430) · 0462f352
      Nicholas Little authored
      The loading operation for MTP involves enumerating files, clearing
      empty albums, writing track information to the database and reading
      playlists. Banshee only produces a status update for the first step, in
      addition the current never reaches the total (due to an off-by-one
      issue) so it appears that the last track takes a long time to enumerate
      and load.
      
      This patch adds status messages for those operations so the user
      doesn't experience a long delay with the same message before being
      able to use his device. In addition, we move the calls to
      Catalog.GetString outside of their respective loop bodies as a small
      performance optimisation.
      Signed-off-by: 's avatarAndrés G. Aragoneses <knocte@gmail.com>
      0462f352
  20. 10 Aug, 2014 1 commit
  21. 06 Aug, 2014 1 commit
  22. 04 Aug, 2014 1 commit
  23. 02 Aug, 2014 3 commits
  24. 01 Aug, 2014 1 commit