On Wed, 2005-10-05 at 17:58 +0200, Christophe Fergeau wrote: > Le jeudi 06 octobre 2005 Ã 02:52 +1100, James Livingston a Ãcrit : > > * support using art from in tags, particularly useful for photo ipods. > > Art isn't stored in id3 tags on iPod Photos (well, iTunes adds artwork > tags to the mp3 when you associate a song with its cover, but it also > adds them to a specific file on the iPod, and the iPod then uses that > file, not the embedded id3 tag). Okay, in that case it's the same as the first point. Sources need a way of overriding the art-choosing logic to either a) tell it to use a particular url (podcasts), or b) use a returned pixbuf (ipods). One way to do it might be to give sources a new virtual method: GtkPixbuf* get_art (RhythmDBEntry *entry) The default implementation would pass it off to the "Cover Art Manager" which would handle it. The Art Manager vould use on already in memory, get it from the on-disk cache, read it from the file's tags, get it from the 'net or whatever. Sources like the iPod could load it from the iPod art db and just return that. Sources like podcasts, which have a particular url associated with an entry, could use a Art Manager function something like rb_art_manager_load_uri, which would handle caching the art. The main art display widget would just listen for playing song changes, and do rb_source_get_art (playing_source, entry) to get the new pixbuf. If we wanted to have art in the album browser, we would probably need something like rb_art_manager_get_art_for_album (albul_name). Cheers, James "Doc" Livingston -- "We are a dumbassocracy. Anyone dumb enough to get off of their ass and volunteer/do something is welcome to do so." -- Matthew Rice
Attachment:
signature.asc
Description: This is a digitally signed message part