Skin- and visual errors related to, and skinning requests for MusicBee v3

[Steven]

A question: With v2 I could have vertical separators (A). But now with this v3 also some horizontal lines B and C show up with that color.
Is that avoidable in some manner?
Also thinking about other skins, it certainly would be good to have the option for a new dedicated element for C.

B is controlled by element "HeaderBar" and defaults to "Panel.ChildHeader.Default" if not provided
i dont have time to check but would guess C is controlled by "Panel.ChildHeader.Default"

[Steven]

This might not be worth mentioning, but on my Windows 7 PC I noticed when the right sidebar is disabled, the main panel header bar extends all the way to the outermost border, which creates a gap in the bitmap window border.

trying now i cant reproduce. Can you provide a screenshot?
Does it happen on startup or only after some action beforehand?

[Alumni]

trying now i cant reproduce. Can you provide a screenshot?
Does it happen on startup or only after some action beforehand?

From my testing it seems to be caused by the Now Playing node (in my case docked in its own tab and using large album cover view).
First of all I disabled the right panel by removing all elements from it, rather than simply hiding it. I then tried to enable the right hand panel in the Now Playing node, assuming it was independent from the right sidebar, but it looks like they are the same thing. As you can see from these screenshots, that's where the visual glitch comes in.


Now Playing screen (notice the right hand border)



Main Library screen (notice the header bar border)

[Steven]

in that case i think i will need your settings file again

[hiccup]

B is controlled by element "HeaderBar" and defaults to "Panel.ChildHeader.Default" if not provided
i dont have time to check but would guess C is controlled by "Panel.ChildHeader.Default"

Ok, I hope I got all this right:

1:

When ignoring any overules I believe that:

A and C are both controlled by:
id="Content[TrackDetail].Body.Default" bdr=

B and D are both controled by:
id="Panel.ChildHeader.Default" bdr=

I can't oversee possible other implications, but looking at the screenshot for this skin, I feel it would make more sense to have C follow B and D.




2:

Two observations about the "HeaderBar" element:
fg= doesn't do anything?
And a visual error:
When I set the element, the title bar looses it's bitmap color and becomes plain white:



3:

I believe I might also succeed in what I am trying to achieve with using the existing id="FilterPanel. elements.
But they currently don't seem to work at all for v3?

[Steven]

I am editing a bitmapped skin with not much fancy stuff going on. The player control buttons are to be drawn by MusicBee itself.
In v2 they are nicely in place, but with exactly the same skin xmlc, in v3 the previous and next buttons don't line up horizontally.

which skin is it?

[hiccup]

which skin is it?

http://1drv.ms/1MCY0pT

[hiccup]

I believe I know what causes this.

The culprit seems to be how v3 renders and centers its player control images on a background image that has an uneven vertical pixel count.

The transparent ButtonSmall.png's which serve as a background for the controls, in this skin had a size of 35x17
I lowered that to 35x16, and now 'previous' and 'next' are identically aligned.

So it seems v2 centered it's drawn player control images (which probably have an even vertical pixel count) identical for 'previous' and 'next', but v3 strangely enough does that differently between 'previous' and 'next' when the background image is 'uneven'.

[Steven]

@hiccup, i am not planning to change the defaults behavior. If i was to start from scratch with non existing skins out there it would make sense to build it better but given where its at now, i will add overrides
for 2, the MusicBee3 skin uses this element. I would think you have probably made an error somewhere eg. colour > 255 that is causing the skin to not load properly. If the fg component is not setting the header bar text colours then that is a bug and i will fix it
for 3, the filter panel elements work for the thumbnail browser and the podcast subscriptions list. I was looking at this last night and i cant remember if its included in the latest version. If not, it will be in the next

for the centering, i recall i did something new for v3 with the play next controls so it scales better with high dpi machines. Its probably something to do with the size allocated to the entire button but i will look at it and address it tonight

[hiccup]

Great, that all makes perfect sense.
Indeed, for (2) the mistake was mine. I had made a minor syntax error in the entry (which np++ didn't alert me to)
But fg is indeed not working for that element (unless it is currently overruled by some other element of course)

[hiccup]

With the same skin from post #111 I noticed some other differences.

1. The volume button, and the 'Stop' button (disabled) get different colors. Also on mouse hoover-over the 'previous' and 'next' controls get another color in v3 than in v2.

2. In v3 the volume bar looks very bland. It has lost its secondary contrasting bordering color. The same for the volume button.

[Steven]

fixes for the above

http://www.mediafire.com/download/hwh28nm8k6ahp2s/MusicBeeDemo.zip
unzip into the musicbee application folder and run MusicBee3.exe

also i have now enabled tab-style panel stacking which is set in the Panel Layout dialog.
Unless i am proven wrong and it is a popular option, i dont want to spend time on it making the tabs fancy. But if enough of you say otherwise i will reconsider.

i have added the following icon overrides:
NowPlayingIcon
MusicExplorerIcon
PlaylistDirectoryIcon


I guess i am at the point now where i can consider new skinning requests. At one stage i was thinking there might need to be panel location (left sidebar, left main panel, etc overrides) but looking at the various skins i am not sure its really needed so for now i am not planning any further enhancements myself.

[hiccup]

also i have now enabled tab-style panel stacking which is set in the Panel Layout dialog.
Unless i am proven wrong and it is a popular option, i dont want to spend time on it making the tabs fancy. But if enough of you say otherwise i will reconsider.

Thanks for doing this! I don't need fancy either. Simple and practical is great.
Now when in tab-style, the drop down arrow in the tab headers can be removed, since there is now a button to quickly select 'selected' vs. 'playing'. That would clean it up a bit more.

And I have another suggestion to have an even cleaner look with these tabs.
Make the tab switch between playing vs. selected by simply clicking on the header once.
When in playing mode, the word 'playing' would probably not even have to be displayed, and when in 'selected' mode, have the word 'selected' appended.

Something like this:

[Alumni]

i have added the following icon overrides:
NowPlayingIcon
MusicExplorerIcon
PlaylistDirectoryIcon

I'm glad to see those overrides introduced.

By the way, are there currently overrides for "Recommendations" and "Upcoming Concerts"?

I was also wondering if there's a way to override the "Devices" icon, or if not could that option be added?

[psychoadept]

Trying to update Mellon Remix now.  Is this offset spot at the Track Information a bug or something I can fix?