a number of users seem to feel that looking at the targets will tell them when the  various issues ARE going to be fixed.  In light of that, it should really be up to those who are taking the burden of making it work to determine when it can be done. 

there is a javascript that already sizes the artwork to the frame.

Yes, I've noticed that the artwork never exceeds the width of the frame, which is good, but that's usually too large, with the track list appearing well down the page.  Of course you can control it yourself by limiting the size of the artwork that you scan or download, or by resizing it yourself, but with the capability SlimServer has to resize images, setting a pref and having all artwork on the album pages kept within a set size would save a lot of work.  Plus it would still leave you with the ability to view the full-sized artwork on the next click.

I think you'd still want to retain the JavaScript routine for people who choose to set the max size to 2000 pixels or 'unrestricted' or whatever.

personally, I feel there needs to be a real reason for a pref...we have too many already. it is a never ending loop requiring prefs, and dealing with those who complain that there are too many prefs.  It is also possible for any skin
 to be designed with a fixed cover art size (which is what it used to be until people complained, etc etc)

Of course it's never ending.  That goes without saying.  If there 
are 100 prefs today, you can bet that some day there will be 200.

There aren't too many - the complaints are that people can't find 
them and often can't understand them.  But that's due to the 
interface being poorly organized, with many prefs not documented 
well.  I doubt there are many complaints from users about having
too much control over the server.

So mark it low priority or write it off.  I thought that with the 
ability to resize artwork, and the current pref for thumbnail
sizing that this one was a gimme that made perfect sense.

I think that having a well chosen image size for the page that doesn't overwhelm (and hide other information) and that's clickable to bring up the full size image (like amazon does) is probably a good solution that doesn't require a pref.

Since this is an enhancement request, it's going to need to be moved to 6.5.

Why was this moved from target 6.5 to future?  If you don't want to deal with it, then mark it INVALID.  Christ, 6.5 is many months in the future, so why are you already pushing enhancement requests into the black hole of 'future'?

Let's make the maximum size on that page smaller than the full width of the pane, probably about half of the width (it shouldn't block the song list).  This should be a trivial change to the HTML to include the targeted size.

FWIW: 6.5 is on a fast track and is targeted for final release at the end of july, that's why we're punting on new features, but since this is a simple layout issue we'll take it now.

Created attachment 1274 [details]
the simple fix

the "simple" way is attached.  much more complicated to track client width and somehow send back to TT to use the GD resizing (but I plan to have nothing to do with that).  So, you get that moment of large, then it snaps to size.  it is also browser resizing.  
I look forward to watching this issue be rehashed indefinately.

KDF, Dean and Dan say the patch looks good, and Dean says to put it in.

Is this done?

I'll merge tonight.

in trunk at change 9227, 6.5 branch at change 9228