Bug 9929 - Small adjustment to Large Album view...
: Small adjustment to Large Album view...
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 7.3.0
: PC Other
: P2 minor (vote)
: 7.x
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-07 11:35 UTC by Matt Wise
Modified: 2009-09-08 09:30 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
With MusicIP disabled (36.88 KB, image/png)
2008-11-07 11:35 UTC, Matt Wise
Details
With MusicIP enabled (35.69 KB, image/png)
2008-11-07 11:35 UTC, Matt Wise
Details
with moreThanThis (9.62 KB, image/jpeg)
2008-11-08 10:35 UTC, Jim McAtee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Wise 2008-11-07 11:35:32 UTC
Created attachment 4215 [details]
With MusicIP disabled

I propose a small adjustment to the Large Album view in SC. because its so late in the 7.3 schedule, I'm hoping we can still push this in ... but I did not want to check it in yet. 

The code change is simple:

diff slimserver.css slimserver.css.new 
582,583c582,584
< 	bottom: 5px;
< 	right: 5px;
---
> 	bottom: 0px;
> 	right: 0px;
> 	left: 0px;
585,586c586,587
< 	text-align: right;
< 	background-color: #c4c4c4;
---
> 	opacity: .85;
> 	background-color: #000000;

The results I think are fairly dramatic... the buttons are much more dynamic in their location and they're quite a bit more attractive. Attached are pics of the new changes.
Comment 1 Matt Wise 2008-11-07 11:35:58 UTC
Created attachment 4216 [details]
With MusicIP enabled
Comment 2 Matt Wise 2008-11-07 11:37:18 UTC
Oh, here's the code without the diff attachment:

.thumbArtwork span.browsedbControls {
        position: absolute;
        top: auto;
        bottom: 0px;
        right: 0px;
        left: 0px;
        padding: 2px;
        opacity: .85;
        background-color: #000000;
}

Comment 3 KDF 2008-11-07 13:36:47 UTC
nice change.  I'm a bit unsure about the black, as it's not a colour that is used a whole lot in the current UI.  However, the really nice benefit is that it's full width so it fits well with covers that are not as high as they are wide.  The unpatched version looks like the controls are misaligned in that case.
Comment 4 Matt Wise 2008-11-07 13:40:20 UTC
Yeah the black isn't used much, but I figured since its slightly translucent it would look nice. Additionally, I actually thought replacing some of our grey backgrounds with black ones might look quite nice... but thats not really my call :/. 

Comment 5 Jim McAtee 2008-11-07 22:49:29 UTC
Have you tried it with no background color at all behind the buttons?  The gray and white buttons have enough contrast that they should stand out on just about any color of cover with no need for a background.
Comment 6 KDF 2008-11-07 23:16:34 UTC
with no background, the case I mentioned above still looks as if the buttons are aligned below the art.  The background serves to extend the bottom edge so that it is always below the buttons even if the artwork is wider than it is high.
Comment 7 Jim McAtee 2008-11-08 10:35:14 UTC
Created attachment 4220 [details]
with moreThanThis

Just tried it out. Looks nice.

FWIW, the icons don't center themselves horizontally in FF 3.0 on my system without

text-align: center;
Comment 8 Matt Wise 2008-11-08 11:13:03 UTC
I tried it without a background (but the icons ON the album art) and there were definately albums where the buttons blended in. I thought the black transparent background just made it look a bit more polished. If the buttons were below the songs, that'd be fine as well -- but you dont want the text moving down just to make room for those icons so im not sure how to handle it.

 I actually spent a while (and am just not good at this stuff) trying to figure out how to change the text below the albums so that the Album Title was in bold, and then the Artist Name was one line down (not separated by 'By', but by a whole line). 
Comment 9 Jim McAtee 2008-11-08 12:50:58 UTC
(In reply to comment #8)
>  I actually spent a while (and am just not good at this stuff) trying to figure
> out how to change the text below the albums so that the Album Title was in
> bold, and then the Artist Name was one line down (not separated by 'By', but by
> a whole line). 

I've tried to figure out how to make the same change, with no luck.  It was relatively easy in the old Default skin.  This is in cmdwrappers_Default file, in the 'BLOCK galleryitem' section:

<div class="artworkText" style="width:[% item.size %]px;"><span style="width:[% item.size %]px;">
  [%- content | indent(4) %]
</span></div>

What/where is 'content' created and can it be customized?

FWIW, I prefer the following, with 'year' in a smaller font:

 Artist Name
 Album Name
    Year

This is more in keeping with the way I (and from what I've seen, most people) tend to label CDs, with the artist name first.
Comment 10 Michael Herger 2008-11-10 08:04:43 UTC
Matt - could you please come up with a solution for IE6 ;-).

change 22683 - patch applied with the old layout moved to ie.css for IE6 compatibility.
Comment 11 Jim McAtee 2008-11-10 08:07:25 UTC
Any clues on how to modify the text layout in the gallery?
Comment 12 Michael Herger 2008-11-10 08:16:51 UTC
edit iteminfo in cmdwrappers_Default
Comment 13 Jim McAtee 2008-11-10 08:54:24 UTC
(In reply to comment #12)
> edit iteminfo in cmdwrappers_Default

Thanks.  Mixed results there, as it affects a lot more than just the text in the gallery view, but I could live with that.  I imagine some conditional in cmdwrappers could work it out, but this stuff becomes more of a mystery to me the more I try to work with it.

In skinconfig.yml right now I have:

---
skinparents:
 - Default
preprocess:
 - cmdwrappers_Default

How can this modification to the gallery text be made in a skin that inherits from Default without:

1. directly modifying cmdwrappers_Default in the Default skin?

or

2. copying all off cmdwrappers_Default into the new skin and using it _instead_ of the one from Default?

Obviously #1 can't be used for an inherited skin.  Number 2 is nearly as bad, as changes to cmdwrappers_Default coming through SVN won't be picked up and the skin will inevitably break.

I've tried variations of 

preprocess:
 - cmdwrappers_Skin
 - cmdwrappers_Default

and 

preprocess:
 - cmdwrappers_Default
 - cmdwrappers_Skin

and placing just the one block from cmdwrappers_Default into cmdwrappers_Skin.  But with no luck.
Comment 14 James Richardson 2008-12-15 12:09:23 UTC
This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Comment 15 Chris Owens 2009-07-31 10:31:37 UTC
Reduce number of active targets for SC