HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AccentI was wondering what skin elements to edit for the playlist header bar?
As for requests, it would be helpful to have an override for the status bar if player controls are docked in the top panel.
I was wondering what skin elements to edit for the playlist header bar?
- Image overrides for "UnknownAlbum" and "UnknownGenre"- Unknown album its already there as: "NoArtwork"
- Image overrides for "UnknownAlbum" ...its already there as: "NoArtwork"
I was wondering what skin elements to edit for the playlist header bar?
I think it's using bg and fg of MusicExplorerHeader element.
override for highlight border in <element id="NowPlayingPopup.Body"looking at the code, its always been hardcoded to grey. I have changed it to use the panel border colors if it is different to the background color
(I actually think bdr attribute use to do this in 2.5)
support for extra "open Auto DJ settings" image in bitmap skins- for the next update, i have added "AutoDjSettingsButton". For reference, the MB one is 11x3px but it doesnt have to be the same size
I meant the record image that thumbnail browser shows for "All Albums" item when "Album" is selected.- thats in the next update as "UnknownAlbumIcon"
- thats in the next update as "UnknownAlbumIcon"
- and in case you missed by edit: I have added "UnknownGenre" for the next update. I recommend 128px for the 100%dpi image
support for highlight colouring on override "EditSave" iconi have changed the default save button and default colouring to be consistent with the other buttons.
either as auto-colouring (as other icons in the header currently do) or the addition of an "EditSaveHighlight" image
Support for bg/fg for tag editor or only for vertical tag editor.done for the vertical tag editor in the next update:
Would it be possible to override the image that pops up when dragging and dropping playlist items?for the next update i have added
The playlist header colour is generated from the album cover.I was wondering what skin elements to edit for the playlist header bar?
I think it's using bg and fg of MusicExplorerHeader element.
@Steven;
Can you support an override for that including bg2 for the gradient? Also support bg2 for MusicExplorerHeader element too.
The playlist header colour is generated from the album cover.I was wondering what skin elements to edit for the playlist header bar?
I think it's using bg and fg of MusicExplorerHeader element.
@Steven;
Can you support an override for that including bg2 for the gradient? Also support bg2 for MusicExplorerHeader element too.
I can add support for bg2 on the MusicExplorerHeader element
support for extra "open Auto DJ settings" image in bitmap skins- for the next update, i have added "AutoDjSettingsButton". For reference, the MB one is 11x3px but it doesnt have to be the same size
support for extra "open Auto DJ settings" image in bitmap skins- for the next update, i have added "AutoDjSettingsButton". For reference, the MB one is 11x3px but it doesnt have to be the same size
Can you show me an example code?
<element id="AutoDjSettingsButton">
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAA1klEQVQ4jc2SsUoDQRiE10IDIqTOAwRUMCCkTJuHUiwsBONjWKQ2r2B/qcI1WZJKrrjiyO3+8yEpxM4iJLsgEZx2mI/hn9+5fyXvfUfSA7AEPoGVpKe6ri+y4bIsz4B3SW9mNvDed2KM18BU0ryqqvMkwMzuJM2ccye7nqRXYJIESFpIGu7z2rbtS/rIATZN03QP+cDXvnZHbXCfucFLErCzwk1RFKcxxitgCqwl3SYBzv38wSPggS2wBp7NbAz4EMJlFnJIIYTRsSDL1FpZSer9Ovwn+gZY2cZuENOVQQAAAABJRU5ErkJggg==
</element>
Is there a setting to make scrollbar corners square instead of rounded? If not that would be nice.can you post a screenshot so i am sure what you mean
support for extra "open Auto DJ settings" image in bitmap skins- for the next update, i have added "AutoDjSettingsButton". For reference, the MB one is 11x3px but it doesnt have to be the same size
it only works for standard player layout ie. if you are using a bitmap skin, its not supported
OK. I thought it was for bitmap skins.
Is there a setting to make scrollbar corners square instead of rounded? If not that would be nice.can you post a screenshot so i am sure what you mean
Is there a setting to make scrollbar corners square instead of rounded? If not that would be nice.for the next update i have added:
<element id="ScrollBarSliderSquare">true</element>
- Support for new (optional) player controls for bitmap skins: Play Previous/Next Albumredwing, are you looking to replace the existing 2 controls or 2 extra, and how important is this to you?
i think i have done all the requests except for this and the auto-dj settings in bitmap skins
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
it would be helpful to have an override for the status bar if player controls are docked in the top panel
it would be helpful to have an override for the status bar if player controls are docked in the top panelPanel.StatusBar.Default and Panel.StatusBarControl.Default are the defaults
Panel.StatusBarInPanel.Default and Panel.StatusBarControlInPanel.Default are overrides when the player is docked at the top
BTW can you support optionally adding stop button to the standard player bar in progress bar in middle layout?yes thats fine and supported for the next update
To make things simple, the button can be really tiny without having to reposition other buttons when it's added. But it would be very useful.
it would be helpful to have an override for the status bar if player controls are docked in the top panelPanel.StatusBar.Default and Panel.StatusBarControl.Default are the defaults
and
Panel.StatusBarInPanel.Default and Panel.StatusBarControlInPanel.Default are overrides when the player is docked at the top
Panel.StatusBarInPanel.Default and Panel.StatusBarControlInPanel.Default are overrides when the player is docked at the top
No, those work when docked at the bottom.
OR the player controls are docked in the top panel.
Panel.StatusBarInPanel.Default and Panel.StatusBarControlInPanel.Default are used when status bar is above the player bar when docked in the bottom panel OR the player controls are docked in the top panel.
Panel.StatusBar.Default and Panel.StatusBarControl.Default are used when the status bar is below the player controls and docked in the bottom panel.
Panel.StatusBarInPanel.Default and Panel.StatusBarControlInPanel.Default are used when status bar is above the player bar when docked in the bottom panel OR the player controls are docked in the top panel.
As redwing said this is not how it works, when player controls are docked in the top panel the values used for the status bar are from Panel.StatusBar.Default and not Panel.StatusBarInPanel. If it worked the other way around it would solve my problem.is it that you need an extra setting for when the status bar is below the player but touching each other?
is it that you need an extra setting for when the status bar is below the player but touching each other?
i have changed the default save button and default colouring to be consistent with the other buttons.
In all cases the highlight background/border is the same for all the buttons, including when you have a custom "EditSave" button
for the next update i have changed the vertical tag editor and also the main panel tag editor to use the same brightening algorithm thats used for all other controlsi have changed the default save button and default colouring to be consistent with the other buttons.
In all cases the highlight background/border is the same for all the buttons, including when you have a custom "EditSave" button
Can you support this for the vertical tag editor too? For some skins, it's not clear whether the mouse is over the save icon when you're trying to save.
for the next update an additional override for when the status bar is on the bottom and the player is directly above itis it that you need an extra setting for when the status bar is below the player but touching each other?Yeah, my goal is for the status bar to "blend in" with the player only when it's placed directly underneath.
<element id="Panel.StatusBarBelowPlayer.Default" bg=xxx,xxx,xxx fg=xxx,xxx,xxx />
<element id="Panel.StatusBarControlBelowPlayer.Default" fg="xxx,xxx,xxx" />
A minor bug with Auto-DJ settings:it looks like i intentionally coded it that way and i vaguely recall there was a reason so would prefer to leave as-is
That panel has two slider bars and while slider buttons are using Controls.SliderButton.Default/Disabled elements, slide bars don't use Controls.SliderBar.Default/Disabled elements.
for the next update i have changed the vertical tag editor and also the main panel tag editor to use the same brightening algorithm thats used for all other controlsi have changed the default save button and default colouring to be consistent with the other buttons.
In all cases the highlight background/border is the same for all the buttons, including when you have a custom "EditSave" button
Can you support this for the vertical tag editor too? For some skins, it's not clear whether the mouse is over the save icon when you're trying to save.
for the next update i have bumped up the brightness for dark skins
The custom EditSave image doesn't show up for vertical tag editor. Is it intended?yes, as the header colours could be very different
Now you can hardly notice a mouse-over:i have tweaked it further for dark skins. For the next update the adjustment is now very similar to what you are using on the player controls
(https://i.imgur.com/31B92UJ.png)
(Sportura Pinstripe)
maybe it would be better to keep them the same, so i will also implement it on the vertical tag editorThe custom EditSave image doesn't show up for vertical tag editor. Is it intended?yes, as the header colours could be very different
When grouping header is enabled in Album & Tracks compact grid view, splitter line color is not following Content[AlbumAndTracks].ArtistSplitterLine element. It only works in detailed view. Also compact view uses another splitter line just below sub-header. Looks like we need new elements for them.the change was intentional
<element id="Content[AlbumAndTracks].GridHeaderSplitterLine" bg=xxx,xxx,xxx />
<element id="Content[AlbumAndTracks].GridTrackSplitterLine" bg=xxx,xxx,xxx />
thats because you are not using a transparent background on the image. Its easy enough to make MB apply transparency
no, it will make the highlighting work better
redownload the latest version to see what i mean
- I have added "UnknownGenre" for the next update. I recommend 128px for the 100%dpi image
would it work ok if the icon override is only used in the thumb browser and i will leave the music explorer one to use the standard icon?
Controls.GenreThumb fg=xxx,xxx,xxx re-colours the standard genre icon (and mistakenly the override icon as well but thats fixed for the next update)
The genre icon override now only applies to the thumb browser and as such the recommended size is now 70px
I noticed if the size is a little bigger or smaller, all genres item shows artist or album picture. It doesn't happen with other unknown icons when the same size of image is used.i dont understand. Perhaps you could post a screenshot?
<element id="Content[NowPlaying].ScrollBar" bg="X,X,X" bdr="X,X,X" />
<element id="Content[NowPlaying].ScrollBar.Lowlight" bg="X,X,X" bdr="X,X,X" />
<element id="Content[NowPlaying].ScrollBarThumb" bg="X,X,X" bg2="X,X,X" fg="X,X,X" />
these have been added and apply to when the Large Album view is used in the Now Playing panel:Thank you! :)
Controls.VerticalMenu is 4px short of matching InputPanel.Default (see Mellon Remix or Future Shock skins)thats fixed for the next update
My OCD thanks you :DControls.VerticalMenu is 4px short of matching InputPanel.Default (see Mellon Remix or Future Shock skins)thats fixed for the next update
Could we please have:
<element id="VolumeVisualiserText" fg="X,X,X" />
<element id="VolumeVisualiserText" fg="X,X,X" />http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
The playlist header's album artwork placeholder seems to be auto-generated. Could it instead use custom images supplied with "NoArtwork" or "AlbumIcon" elements?the next update will use the new "UnknownAlbumIcon" override image when present. That image is used for the thumb browser
Is there any interest in having a setting that tells MB to automatically recolour the player controls panel and the controls based on the album cover?
I think some of the skins would work quite well with that.
It would require using one colour for all the controls and setting the alpha on each control as appropriate
It was actually your threshold light skin that i was looking at but i think it could work well with any neutral skin.
As mentioned, the panel controls would need to be the same colour in the bitmap skin, using alpha values as appropriate, and MB would choose the fg and bg for everything in the panel based on the album cover, preserving the alpha values.
Also its recommended to set:
<element id="WindowBorderWidth">0</element>
<element id="PlayerAutoColor">true</element>
<?xml version="1.0" encoding="utf-8"?>
<root dependsOn="ThresholdLight.xmlc">
<element id="PlayerAutoColor">true</element>
<element id="WindowBorderWidth">0</element>
</root>
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
note i have only tested this against the ThresholdLight skin. Its possible some buttons might cause an issue (rendering issue) so let me know if that does happen
all you need to do is set:Code<element id="PlayerAutoColor">true</element>
here is a simple way to experiment with it without having to edit the original bitmap skin:Code<?xml version="1.0" encoding="utf-8"?>
<root dependsOn="ThresholdLight.xmlc">
<element id="PlayerAutoColor">true</element>
<element id="WindowBorderWidth">0</element>
</root>
note your skin should use a single background colour and for volume button, progress bar, and progress button, MB will search for the skin background colour and make the parts of those controls with that colour transparent. For the progress and volume buttons, any parts that are not the button edge colour will be made transparent or semi transparent (this is needed to handle the type of buttons used in the threashold skin). If thats a problem for your skin let me know and i will add a setting to disable the behaviour
automatically recolour the player controls panel and the controls based on the album cover
If I may make a suggestion, I think it would make sense if the player controls are never inverted (from white to black), but rather limit the background color's maximum brightness to still maintain readability. As it is now this seems to only affect some shades of yellow and green.that was the plan but i see yellow is defeating the algorithm so i will make some further tweaks
I will change Pastels skins to use the default player for 3.2, so they will also benefit from this feature.currently the functionality only works with custom bitmap skins or derived from custom bitmap skins
currently the functionality only works with custom bitmap skins or derived from custom bitmap skins
For me it works with xml skins as well with the two lines added.you will find the progress bar doesnt display properly, at least for the skins i tried plus there are sections of code not implemented for standard layouts.
BTW can't it work with DisableSinglePxBorder setting enabled?
Clicking on restore/maximize button changes player controls colors when this feature is enabled.working fine here. Are you using a custom bitmap skin and if so which one?
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
this version now supports standard skins and user control over the auto-colouring
right click/ Panel Layout/ Auto-Pick Panel Colours
For custom skins, <element id="PlayerAutoColor">true</element> is still required so the user has the option to choose auto-colouring
I just tried with a pastel skin and i see a couple more tweaks are needed
have you thought about optionally displaying a gradient/blur effect for the auto-picked color player background?
you will need to change it to use a single colour or at least not use the panel background colour (based on the top left pixel)I just tried with a pastel skin and i see a couple more tweaks are neededIt looks better except the progress bar with a dotted line. Can you improve that? If it's not easy, never mind. I'll change to default player bar.
I tested with various album covers and I think the algorithm could improve a little.While i do agree the colours are not so diverse, the darkness is intentional to ensure the controls are always strongly visible. I think darkness works best with both dark and neutral skins, whereas light colours can look too bright on dark skins or "mushy" on neutral skins.
The colors it picks up are too dark. No light colors at all. Also most white background covers are picked up as yellow/greenish color that makes no differences with real yellow/green colored covers. Why not use light grey instead for them?
The overall colors it shows are not so diverse and you only see some similar colors all the time out of various colors of covers.
you will need to change it to use a single colour or at least not use the panel background colour (based on the top left pixel)I just tried with a pastel skin and i see a couple more tweaks are neededIt looks better except the progress bar with a dotted line. Can you improve that? If it's not easy, never mind. I'll change to default player bar.
I fixed the dotted line. It was about the shape of progress bar. I changed it from a rounded to a squared rectangle.its no problem for the progress and volume slider (will be set to 50%)
Is it possible to show different colors for progress bar and fill like the default player bar? (also for volume slider and player buttons in different states)
<element id="PlayerAutoColorUsingStandardSkinRules">true</element>
the reason will be because you are using different colours, even small differences. Different alpha is OK.
If its a problem i guess the new setting could override that so MB just blindly recolours the button preserving the alpha
the button colouring now uses the PlayerAutoColorUsingStandardSkinRules setting
While i do agree the colours are not so diverse, the darkness is intentional to ensure the controls are always strongly visible. I think darkness works best with both dark and neutral skins, whereas light colours can look too bright on dark skins or "mushy" on neutral skins.
I will spend some time on the weekend experimenting some more though. Having a quick look at the colours used by Groove, it appears to go down the same route (I may be proved wrong but thats what i am seeing for some bright album covers)
I realise now what the issue is with the progress bar in the pastel skin and will be fixed for the next update, so you can revert it back to using rounded corners if you wishI just tried with a pastel skin and i see a couple more tweaks are neededIt looks better except the progress bar with a dotted line. Can you improve that? If it's not easy, never mind. I'll change to default player bar.
I realise now what the issue is with the progress bar in the pastel skin and will be fixed for the next update, so you can revert it back to using rounded corners if you wish
I have been experimenting with using a blurred album cover to give the panel colours some texture. It can look really good, but to get it working well across many album covers in terms of the panel controls showing clearly means i need to flatten the blur to the point that its hardly worth doing for the normal narrow type player panel.
Additionally if MB detects the contrast for the player controls is not strong enough, it will just use a solid background colour.
I have widened the panel colour range - it still orients toward dark colours but better than before
Based on feedback, i might remove the blur effect
Tweaked some more. I feel its ok now
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
Working fine now. Haven't seen an unmatched color case so far with the new version. Thanks!
I have now added the Compact Player. Overall I dont think it works that well in the Compact Player (except perhaps the Large Album view) but since i've done it i will leave it in.
- When disabling auto-pick option, the volume slider button is not colored correctly with Pastels skin. Switching to the main player and back fixes it.these are fixed now, along with the missing wavebar colouring:
- This is not about this new feature but when track info is drawn over the main panel (Artist Picture view & Album Color Mix view) I think it should use automated color for the text like Large Album view since the current color is only meant for the track info in the now playing panel.
<element id="PlayerProgressFractions">true</element>
Is there an override for the lyrics panel?no - just lyrics and not the other child panels such as bio, track info? If its all of those sub-panels then use:
Is there an override for the lyrics panel?no - just lyrics and not the other child panels such as bio, track info? If its all of those sub-panels then use:
Panel.ChildBody.Default
ElementPanel.Default
ElementPanel.ScrollBarThumb
ElementPanel.ScrollBarBackground
ElementPanel.ScrollBar
ElementPanel.ScrollBar.Lowlight
I have come to like the player auto-colouring quite a bit and one thing I am thinking of doing is making auto-colour of the player panel turned on by default. Of course it would only be applied with standard skins or custom skins that state its supported.
However I am wondering how skin authors might feel about that as it could be interpreted as overriding your skin by default so not fully respecting your work.
If anyone objects (send me a PM if you wish) I can do this by adding another skin setting that allows you to specify auto-colour as the default.
For the next v3.2 update, I have added the following that when supplied overrides: Lyrics; Artist Biography and TrackInfo panelsCodeElementPanel.Default
ElementPanel.ScrollBarThumb
ElementPanel.ScrollBarBackground
ElementPanel.ScrollBar
ElementPanel.ScrollBar.Lowlight
http://musicbee.niblseed.com/V3_2/MusicBee32_Patched.zip
I have come to like the player auto-colouring quite a bit and one thing I am thinking of doing is making auto-colour of the player panel turned on by default. Of course it would only be applied with standard skins or custom skins that state its supported.
However I am wondering how skin authors might feel about that as it could be interpreted as overriding your skin by default so not fully respecting your work.
If anyone objects (send me a PM if you wish) I can do this by adding another skin setting that allows you to specify auto-colour as the default.
<element id="PlayerAutoColor">false</element>
Somehow I thought you're referring to when switching to another skin rather than when installing MB first time.i was originally but changed my mind and left that setting in case someone found it useful
I don't know why I thought so, but it wouldn't make much sense.
Anyway I'm not gonna disable the feature for any of my standard skins, but hope another skinner may find the setting useful.
When auto color pick option is enabled with Pastels skins, track info scroll overlaps with track duration. If that option is off, it works fine.i can reproduce this for the pastel skins and its fixed for the next update
the following are overrides for the next update:Codethe track splitter line is only used if there are no alternating row colours set (or the same)<element id="Content[AlbumAndTracks].GridHeaderSplitterLine" bg=xxx,xxx,xxx />
<element id="Content[AlbumAndTracks].GridTrackSplitterLine" bg=xxx,xxx,xxx />
For the progress and volume buttons, any parts that are not the button edge colour will be made transparent or semi transparent (this is needed to handle the type of buttons used in the threashold skin). If thats a problem for your skin let me know and i will add a setting to disable the behaviour
Are you able to send the skin so i can see why it is a problem?
For the progress button, why didnt you just set the alpha to 1 on the top left pixel? I would have thought that could have been an acceptable solution
id="NowPlayingList.SequenceInfo" bg fg fg2 bdr
<element id="PlayerFlat.DisplayPanel" bg="255,255,255" fg="150,150,150" />- This is Cotton skin and see that the track text keeps flickering when it scrolls.probably not, MB is using the most efficient windows API (that i know of) for the scrolling and rendering. I think its because its scrolled 1px each tick makes it slightly jumpy and to get it smooth would require fractional px scrolling which the windows API doesnt directly support. Having said that, your gif looks more jumpy that what i see on my machine
(https://i.imgur.com/GQ5mk6t.gif)
I first thought it's about some setting but it turned out it happens with any skins if the fg of the text is not too dark.
For instance, try this with the default skin:CodeCan you improve it?<element id="PlayerFlat.DisplayPanel" bg="255,255,255" fg="150,150,150" />
Having said that, your gif looks more jumpy that what i see on my machineIt's a low quality GIF only with 16 FPS.
to get it smooth would require fractional px scrolling which the windows API doesnt directly support.Yes, a new setting just like the PlayerProgressFractions setting for the progress bar would be great that would work for the scrolling track text.
- When an item is selected in the preferences, a dotted line surrounds it. It's invariably 0,0,0 and hence almost invisible with dark skins.i have put something into the next v3.3 update but it seems to have a mind of its own about what colour is actually used, and on dark skins its bright white
(https://i.imgur.com/OqgjLli.png)
Can you make the color auto-adapt to the background or provide an override?
i have put something into the next v3.3 update but it seems to have a mind of its own about what colour is actually used, and on dark skins its bright white
- Right after playing a track with long artist value, playing a track with shorter artist value shows some remaining text of the previous artist on the display panel.I think its because you need to add another 8px to the height for the playing track text eg. set the bottom rule to -14 instead of -22.
I think its because you need to add another 8px to the height for the playing track text eg. set the bottom rule to -14 instead of -22.
Its easy for me to add a setting that forces far alignment (left align on the left progress and right align on the right duration)
<element id="PlayerSplitProgressTextFarAlign">true</element>
<element id="PlayerWaveBarHideMultiLine">true</element>
OK. Then what about the PlayerInfoCentered setting? Are you gonna add another setting for 2-line text or the setting will center 2-line text as well?it now respects the "PlayerInfoCentered" setting
multiLine="true" will be no longer needed, or does that always force 2-line text?for custom skins, the only way to set 2 line (multiline) is
If track text height of a bitmap skin is less than 40px, then MB will auto-expand it when 2-line text is enabled?
<element id="TrackText" parent="Panel" multiLine="true">
OK, I got it.sure - but I need to think about how to handle the height adjustment that would be needed when toggled from multi-line to single line
But can you make multi-line custom skin display single-line text optionally?
Then still a single custom skin can display both options, otherwise I will have to release two versions.
Why not just display text in the middle with no adjustment to player images?Thats certainly the simplest thing to do. However to accomodate the 2nd line the track text panel would need at least 20px extra (perhaps more so its not too squashed) compared to the single line text, so thats quite a bit of wasted space with in the single line mode.
Perhaps design the panel with single line height in mind and the extra height needed for the 2nd line can be configurable in the skin
the current font height adjustment works well enough on all custom skins for small font height adjustments but the requirement here is for a large adjustment to accommodate an extra line and wont work well in all cases eg. the Tron Punk skinPerhaps design the panel with single line height in mind and the extra height needed for the 2nd line can be configurable in the skin
If that's possible, then why did you say custom skins need enough space for 2-line text and my earlier suggestion won't work well enough for most custom skins?
<element id="PlayerMultilineSupported">true</element>
- It requires a restart to change the displayed font size of the second line.1 and 3 are fixed
- Multi-line text overlaps with the progress bar of some custom skins e. g. Cotton or Gray skin especially with a large font.
- Now custom skins created with <multiLine="true"> attribute show no track text.
<element id="PlayerMultilineYAdj">-6</element>
- It also doesn't work with custom skins having track text over progress bar (e.g. Dark Green Bee) in that first line doesn't show up. For now this setting doesn't work properly with any of my custom skins.the first wont be supported.
- Even when PlayerInfoCentered is set false, multi-line text is always center-aligned.
for the second, at least for standard skins it will be forced. But if you are referring to a custom skin then i guess thats a bug
i take that back, i will have a look at adding support this- It also doesn't work with custom skins having track text over progress bar (e.g. Dark Green Bee) in that first line doesn't show up. For now this setting doesn't work properly with any of my custom skins.the first wont be supported.
So it looks like custom skins still need to be initially created with enough panel height to work well with multiple line setting.I dont think you need to add extra space for it to work well. In the cotton-skin case its the way your specified the layout for the track text using verticalcenter. You can see there is plenty of height available but the centering messes up the adjustments MB applies. There are other reasons for other skins, so thats why i would rather you tell MB how much extra to adjust the y position.
But then it can't show the single line. Are you gonna support this, or it has to be a separate version?
its the way your specified the layout for the track text using verticalcenter. You can see there is plenty of height available but the centering messes up the adjustments MB applies.
- Try with Cotton skin and notice the second line, when it's long, overlaps with track position on the right unlike the first line.the first is fixed for the next update
- When it starts scrolling, the left alignment is not respected with PlayerInfoCentered not set. Compare when it scrolls with when not.
In any case the scrolling text display should now show in the same apparent position as the static text display, and the static text display position is the same as older versions ie. 3/4px offset from the exact track text panel bounds
The second line is still centered with PlayerInfoCentered not set.should be fixed now
<left relativeTo="TrackRating.Right" offset="18" />
<right relativeTo="ProgressBar.Right" offset="-20" />
The second line is still centered with PlayerInfoCentered not set.should be fixed now
But there's an issue. fg2 of PlayerFlat.DisplayPanel colors both track text on progress bar's filler part and the 2nd line of track text.I literally just uploaded a change for that. However the 2nd line doesnt have any colour override for when the progress bar is over the text. Thats not easy for me to implement and I probably wont
The fg for the filler part may need an override.
For custom skins with a normal progress bar, 2nd line is visible in the wavebar layout with PlayerWaveBarHideMultiLine not set. This is a bug, right? Or does that setting have to be set not to show 2nd line in the wavebar layout?The default assumption when multi-line is enabled within the custom skin definition (<element id="TrackText" parent="Panel" multiLine="true">) is the multi-line track details are always visible and PlayerWaveBarHideMultiLine is required so its not displayed. If you dont set the flag and the text would be obscured by the wavebar then the results will be unpredicatable.
If you are not using multiLine="true" but are infact referring to <element id="PlayerMultilineSupported">true</element> then that sounds like a bug but i would need the skin in question to see whats going on.
For custom skins with a normal progress bar, 2nd line is visible in the wavebar layout with PlayerWaveBarHideMultiLine not set. This is a bug, right? Or does that setting have to be set not to show 2nd line in the wavebar layout?I am not seeing this behaviour with the skin you sent. Could you post a screenshot?
What would happen if a custom skin supplies only 200% bitmap images for player images? Can MB scale them down properly when 100% or 150% images are needed? If there's no downsides with that, that would be much easier for creating images and it will also make custom skins much smaller.if you supply SVG images, MB automatically creates 100%, 150% and 200% png images for the player panel. If you are refering to appending "_200" to a .png image file or text representation, then as it stands MB only scales up so would only use the 200% image when the dpi scaling is 200%+
<element id="PlayerAlignElementToPosition">TrackText</element>
<element id="PlayerAlignElementToDuration">TrackRating</element>
The white color used in the wavebar above and the background below was meant for white player bar & white sidebar. But it's applied in the wrong context and doesn't look good. Dark skins look worse as they draw a black wavebar in the middle. How about making the wavebar transparent or using an auto-generated color instead?are you using Compact.Player.Wavebar and Compact.Player.Wavebar.Inner?
Yes.ok, i get your point now
Lengthy title overlaps with rating.
It happens only with wavebar and works fine with progress bar. Why not make it consistent?of course - it's fixed for the next update
<element id="Panel.StatusBarControl.Default" fg="49,58,23" fg2="250,0,0"/>
<element id="Panel.StatusBarControlInPanel.Default" fg="158,168,132" fg2="250,0,0"/>
<element id="Panel.StatusBarControlBelowPlayer.Default" fg="42,52,20" fg2="250,0,0"/>
I definitely dont want to tweak the algorithm at this point in the release but that is my preferred solution as that algorithm is used in a number of places, so i will leave it to v3.4Sorry Steven, forgot about this post :-[
Could you send me the skin or let me know its name?