1. 15 Dec, 2014 4 commits
  2. 12 Dec, 2014 2 commits
  3. 15 Aug, 2014 1 commit
  4. 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: default avatarAndrés G. Aragoneses <knocte@gmail.com>
      0462f352
  5. 10 Aug, 2014 1 commit
  6. 06 Aug, 2014 1 commit
  7. 04 Aug, 2014 1 commit
  8. 02 Aug, 2014 3 commits
  9. 01 Aug, 2014 4 commits
  10. 30 Jul, 2014 2 commits
  11. 28 Jul, 2014 4 commits
  12. 25 Jul, 2014 3 commits
    • Nicholas Little's avatar
      Dap: not purge at disconnect & virtualize load (bgo#732634) · ba87f8c8
      Nicholas Little authored
      For DAP sources where metadata is difficult or costly to extract
      (i.e. Bluetooth, as it's a much slower medium), it is useful to
      keep the old metadata around to allow for speedy track enumeration
      in the cases where files are still present.
      
      To allow for those cases this patch:
      
      - Adds two new virtual methods, PreLoad() and PostLoad(), which
      allow subclasses to customise behaviour at those times
      (Bluetooth extension will override PreLoad() avoiding the purge
      of tracks; and will probably add caching strategies to both
      methods).
      - Removes calls to PurgeTracks() and PurgeTemporaryPlaylists()
      from the Dispose() method, which is called when the device is
      disconnected/ejected.
      
      For sources that don't take advantage of this new functionality,
      this shouldn't actually result in a change of behaviour (it is
      true that the track records will not be deleted from the DB when
      the device is disconnected; but this deletion will occur when
      the device is connected again anyway, at PreLoad() via
      PurgeTracks() and at Initialize() via PurgeTemporaryPlaylists(),
      like it used to happen.)
      Signed-off-by: default avatarAndrés G. Aragoneses <knocte@gmail.com>
      ba87f8c8
    • Andrés G. Aragoneses's avatar
    • Andrés G. Aragoneses's avatar
      CoverArt: display embedded artwork even if tags missing (bgo#692107) · b2f8cbb1
      Andrés G. Aragoneses authored
      Most MetadataProvider classes cannot retrieve cover art if there
      is no album name information in the track because they get retrieve
      the metadata from online sources. However, there is a provider which
      does it locally: EmbeddedMetadataProvider.
      
      In this case, the restriction about album name being known doesn't
      really apply, so let's move this restriction to the online providers
      and remove it from the more generic MetadataService and CoverArtJob
      classes.
      b2f8cbb1
  13. 22 Jul, 2014 3 commits
  14. 21 Jul, 2014 1 commit
  15. 18 Jul, 2014 1 commit
  16. 17 Jul, 2014 5 commits
  17. 16 Jul, 2014 3 commits
    • Andrés G. Aragoneses's avatar
      TrackInfoDisplay: consistenly choose a color for both line layouts · b0aa779d
      Andrés G. Aragoneses authored
      The Pango.Layout objects 'first_line_layout' and 'second_line_layout'
      were being assigned a colour in different ways, which could be a bit
      confusing (the latter was using <span color="xyz"> markup, the former
      was using Cairo.Context.SetSourceColor() API), so let's use markup
      in both cases.
      
      This commit changes behaviour, but doesn't (shouldn't) produce a
      different rendering result in any way.
      b0aa779d
    • Andrés G. Aragoneses's avatar
      TrackInfoDisplay: proper mid color for 'from' and 'by' (bgo#732898) · 25fec2bc
      Andrés G. Aragoneses authored
      The mid-color between the default text color and the background color
      of the widget was not being calculated properly because the background
      color obtained for the TrackInfoDisplay widget was the same as the text
      color. This behaviour must have changed recently in GTK3, but what we
      are sure about is that using the Parent's reference colors we get the
      proper colors again (probably because the parent of this widget would
      be a ToolItem, inside a Toolbar, which has its background color surely
      defined, compared to TrackInfoDisplay widget which is implemented in
      the Banshee codebase.
      25fec2bc
    • Andrés G. Aragoneses's avatar
      TrackInfoDisplay: proper fix for not bold but invisible text (bgo#732838) · d3994e49
      Andrés G. Aragoneses authored
      OnStyleUpdated() was in charge of filling the color fields of
      TrackInfoDisplay class with values, but it could happen that
      these colors were retrieved before OnStyleUpdated() hadn't been
      run yet even once, which resulted in a black color, but all
      transparent (alpha=0). The way to fix it is make the colors be
      properties that query the proper value on demand if the value
      had not been set yet, or is resetted.
      
      Thanks to Bertrand Lorentz for the heads up about the hint of
      what was really going on badly.
      d3994e49