Re: [Rhythmbox-devel] Patch proposal: Show album cover as iconnext to the song tiltle



On Wed, 2004-02-04 at 22:30, Joergen Scheibengruber wrote:
> Hi,
> 
> see http://bugzilla.gnome.org/show_bug.cgi?id=133459

I like discussing things in email more, so I'll respond here...

> http://www.wh-hms.uni-ulm.de/~mfcn/shared/rhythmbox-album_icon.png for a
> screenshot :-)

Very cool!  Thanks for working on this, I think it is nice functionality.

Ok, so I had a look at your patch.

First - I'd prefer we kept Rhythmbox working completely over GnomeVFS. 
Right now your patch attempts to extract a local URI (and will abort if
the URI isn't local).  Instead, what you should do is just pass the URI
directly to RBHeader.  It will then use GnomeVFS to open the uri, create
a new GdkPixbufLoader, and feed the data to the GdkPixbufLoader over
GnomeVFS.  If you wanted to do it a little bit more cleanly, you could
put this function somewhere in lib/.

Also, it would be good to check would be the size of the image; make
sure it isn't insanely large.  This will prevent someone from putting an
enormous cover.jpg in a shared directory to cause Rhythmbox to crash.

Secondarily, we need to abstract the way we decide where the album cover
is a bit more.  The ID3v2 standard defines a field for including
pictures: http://www.id3.org/id3v2.4.0-frames.txt

Does anyone know how many people actually use this?  If we were actually
going to support it, we'd need to add it to RBMetadata, and therefore
GStreamer and/or monkey-media.  

Do people store album covers in any other way?  Would renaming the
covers to cover.{jpg,png} be a problem?

Also, it could be interesting to think about downloading these
automatically; I think Muine has support for using amazon.com's web
services for this purpose.  Looking at Amazon's web services page, it
seems their license is actually fairly unrestrictive.  To actually use
this we'd need to have an (optional) dependency on soup. 

Finally - have you considered creating an arch branch to work on this? 
It will make things much easier - you will be able to hack and commit to
your own branch, and when it's ready we can just pull it in via
star-merge.

This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]