Re: [Rhythmbox-devel] another queue UI layout

[Thomas Lunde <tlunde gmail com>]

On Sat, 26 Mar 2005 15:51:47 +1100, James Livingston <jrl ids org au> wrote:
> the reason for not doing the second was. If we do want to make it a
> multi-purpose area probably the best thing to do would be have a submenu with
> the options of what to put there (nothing, queue, cover-art, visualisation, etc).

Either a menu or a set of radio buttons in a pref pane works and both
have the advantage of discoverability.  I discovered the "change by
clicking on the title bar of the area" UI in iTunes quite by accident,
so it is lacking discoverability -- but it almost makes up for that by
its accessability since it is really easy to quickly shift from one
view to another.


> I think one of the other arguments that came up was where to store the cover art,
> a number of places being suggested.
> 
> 1) in the file itself
> This has several problems, notably that you can't do this with anything downloaded
> from Amazon (I think it was 3 months you could keep it for). Other ones included the
> fact that quite a few people don't want to have multiple copies of the image (one
> per track) and that some formats don't support this. On the good side it is how iTunes
> does it (so I've been told).

A couple of points:

a.  Yes, iTunes does it this way.  That, by itself, is not a good
(enough?) reason for rhythmbox to do so.  However, because iTunes does
it this way, all of the new portable audio players with screens (both
the iPod and the WMA horde) recognize and will use embedded cover art.
 Since it'd be nice to have a seamless experience (excuse the
marketing-speak) with these devices, I think it important that if art
is in the file itself that something useful be done with it.

b.  I just read Amazon's TOS:
http://www.amazon.com/gp/browse.html/ref=sc_fe_c_1_13553801_4/002-0659671-3727212?%5Fencoding=UTF8&node=3440661&no=13553801&me=A36L942TSJ2AJA

It does appear that the TOS require an application which has gathered
data, including images, from Amazon to re-download this data every
three months.  Perhaps the best solution would be to store images that
the app downloads in  ~/gnome2/rhythmbox/covers/  (using the file date
as a check for when they need to be refreshed from amazon.com) and not
store this data in the music files directly.  If the user manually
puts the file into the ID3 tags, that's outside the scope of Rb's
interaction with Amazon and not within our control.

c.  (Ick, the required disclaimer:  Yes, I'm a lawyer but, unless you
are located in Minnesota or Massachusetts, I'm not licensed to provide
you with legal advice.  Please consult a licensed attorney in your
jurisdiction.  If you are in MN or MA, this email does not create an
attorney/client relationship; please consult with a legal advisor who
can provide with you advice based on the specific facts of your
situation.)


> 2) in a file in the same directory as the track (e.g. folder.png or whatever)
> This is perfect for anyone who (like me) stores their music in a /Artist/Album/Track
> hierarchy. This would not work *at all* for anyone who has their music in a flat
> directory.

Using (but not storing) album art we discover here has the advantage
of interop with folks who are coming from using Windows Media Player;
it stuffs cover art (in JPEG format and in two sizes, I think) in the
directories that it manages.


> 3) in a special folder (e.g. ~/.gnome2/rhythmbox/covers)
> This would work under any situation, but has the problem that it is incompatible
> with every other program that deal with cover art.

But does have the advantage that since it is under the control of the
application and if it is the only place in which the app writes cover
art, we have a straightforward way of complying with Amazon's terms of
service.

My $.02.

thomas