Author Topic: PlayerMultilineYAdjustment functions dependent of skin.xml  (Read 7165 times)

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
element id="PlayerMultilineYAdjustment" only seems to function when multiLine="true" is forced in the skin.xml.
I would think it should function independent of that skin.xml setting?
Last Edit: January 16, 2021, 02:35:54 PM by hiccup

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
Doing a google search I can see redwing made a reference to it but I cant find it implemented in any MB version.
What is it you are trying to achieve?

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
After some more testing I now better understand how the feature is implemented.

I was confused because I would design the skin tweaking the text lines with having 'multiline=true in the skin.xml.
(I then thought it was a compulsory setting to get multilines to begin with. I now understand it does not mean 'enable' multiline, but 'enforce' multiline.)

Then during experimenting I removed 'multiline=true', and without changing anything else the text lines would show up at very different positions and in a different font size.

But now I see that's irrelevant. You design a skin with multiline either forced or not, and you tweak it following that decision.
It doesn't matter that things look very different when you switch forced multiline mode.

I do have a request. Could it be made available to have the main text line at a vertical offset position when the user turns off multiple lines?

Currently the second line is simply removed from display, leaving the single line hanging high.
I would like to position it at the vertical centre when multiline is off.

edit,
Checking and comparing with MB's default skin it looks like the mechanism is working differently then I thought, and the second line is not simply 'made invisible'.
It appeared like that in my testing skin when fixedHeight=true was set, but with different values I now see different behaviour and the panel size actually changes depending on single or multiple lines.

So for as far as my understanding of the mechanics involved goes for now, the requested offset for single vs multiline would only be needed when fixed height is set in the skin.xml.
Last Edit: January 16, 2021, 02:40:12 PM by hiccup

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
Besides the centering request I have another one:

It always occurred to me that MusicBee's auto player panel heighten feature kicked in much too soon, and for that reason I always set my skins to a fixed panel height.

Experimenting with the multiple line feature has possibly shed some light on the cause of that for me.
Here is my skin on the left, and MB's skin on the right.
They both have the exact same font set.



My skin gets it's height enlarged while that shouldn't be necessary considering the height being large enough for that font size.
(the initial panel size is even taller than MB's player panel on the right)
The blue lines indicate the actual background.png size, which is 60px.
The red lines show the enlargement that MB applies.
Obviously I would prefer the panel to remain as low as intended, and it only getting enlarged when necessary.
(Maybe it is enlarging because it anticipates on a progress bar possibly occupying the same vertical space, and it doesn't know the size and location of it?
Just guessing.)


I can keep using fixed panel heights, but it would be nice if that wasn't necessary.
Setting it to a fixed size will also restrict the possibilities for users to use larger fonts when they desire so.
Last Edit: January 16, 2021, 02:35:21 PM by hiccup

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
To be sure it's not missed, I have edited my reply #3 with an additional observation.
Last Edit: January 16, 2021, 02:36:06 PM by hiccup

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
For bitmap skins, its possible to indicate the skin is designed specifically for multi-line display. In that case no height adjustment is applied and the user cannot change to single line. This was done originally for some of Alumni's skins.

For skins in general, if you can use the element "PlayerMultilineSupported" and when set to true it means the skin is designed to support both multi-line or single line. So when the user sets multi-line display, MB adjusts the panel height by the height of the 2nd line font. Thats unless you force a specific panel height which it sounds like you are doing.

Also I just discovered that "PlayerMultilineYAdj" is implemented - it adjusts the position of the text when the user sets multi-line. So you might position the text for single line and then set "PlayerMultilineYAdj" to get MB to move the text up/down for 2 line display
Last Edit: January 17, 2021, 05:46:29 AM by Steven

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
For bitmap skins, its possible to indicate the skin is designed specifically for multi-line display. In that case no height adjustment is applied and the user cannot change to single line.

I understand, that's why I wrote:
"I was confused because I would design the skin tweaking the text lines with having 'multiline=true in the skin.xml.
(I then thought it was a compulsory setting to get multilines to begin with. I now understand it does not mean 'enable' multiline, but 'enforce' multiline.)"


Quote
Thats unless you force a specific panel height which it sounds like you are doing.

As I wrote, I have been testing both:
"I can keep using fixed panel heights, but it would be nice if that wasn't necessary.
Setting it to a fixed size will also restrict the possibilities for users to use larger fonts when they desire so."


Quote
Also I just discovered that "PlayerMultilineYAdj" is implemented

I have been trying that setting last week, but it did nothing at all.
I now see why. In several forum posts it is named "PlayerMultilineYAdjustment" and I used that.
But I notice you now say it is "PlayerMultilineYAdj", which is correct, and now that function works.

Perhaps you can edit older forum posts using the wrong name for it?
Such as:
https://getmusicbee.com/forum/index.php?topic=23223.msg151407#msg151407
https://getmusicbee.com/forum/index.php?topic=26914.msg151476#msg151476

- - -

Irrespective of any adjustment settings, it doesn't solve the issue of:

Quote


My skin gets it's height enlarged while that shouldn't be necessary considering the height being large enough for that font size.
(the initial panel size is even taller than MB's player panel on the right)
The blue lines indicate the actual background.png size, which is 60px.
The red lines show the enlargement that MB applies.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
The links have been corrected
I have added the following which when true suppresses the line 2 font height adjustment when multi-line mode is set
Code
<element id="PlayerMultilineNoHeightAdjustment">true</element>
https://getmusicbee.com/patches/MusicBee34_Patched.zip

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
Yes, this gives much better results.

For now it looks like the only thing left that would improve it even more for me is the font-size/panel-size ratio.

-  When the panel is set at fixed size:

The font size is dictated by the height of the panel.
I feel it would be nice—and think there is room—for the auto-sized font to be a little bit larger.
Perhaps have it respect the font size chosen by the user, to the limit of when it would overflow the trackinfopanel.

- When the panel is not set at a fixed height:

I still feel that MusicBee's auto-enlargment of the panel height kicks in a little bit too early.
The new element has improved this a lot though, so if anything further can be done, it won't have to be much.


Two specific questions remain:

1.
What panel element is MB looking for to decide on the font size?
Is it 'panel' or is it 'trackinfopanel'?
If it is 'panel', does it anticipate/guess on a progressbar height?
If it is 'trackinfopanel', my impression is that it may not be making the most of the available space?

2.
After all this testing, I have come to doubt the usefulness and purpose of the: multiLine="true" option that can be set in skin.xml
What is it added value?
It will set (force) multiline by default, and it removes the multiline yes/no option for the user.

But if the user is not thrown off or confused by the absence of the 'disable multiline' option, he can simply empty the value for the second line.
The result would be the same as when the user would have had the option to disable multiline to begin with?

So what is the actual advantage—for either the skinner or the end-user—to use that option in skin.xml?
Last Edit: January 17, 2021, 07:07:13 PM by hiccup

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
1.
What panel element is MB looking for to decide on the font size?
Is it 'panel' or is it 'trackinfopanel'?
If it is 'panel', does it anticipate/guess on a progressbar height?
If it is 'trackinfopanel', my impression is that it may not be making the most of the available space?
the font is based on the font the user has set for the player controls panel, and the second line reduces that font size by 0.75 points for the default font and 1.5 points when a custom font is used eg. line 1 is 9.75 points then line 2 is 9 points
The panel height is adjusted by the height of the 2nd text line font

2.
After all this testing, I have come to doubt the usefulness and purpose of the: multiLine="true" option that can be set in skin.xml
What is it added value?
It will set (force) multiline by default, and it removes the multiline yes/no option for the user.

But if the user is not thrown off or confused by the absence of the 'disable multiline' option, he can simply empty the value for the second line.
The result would be the same as when the user would have had the option to disable multiline to begin with?

So what is the actual advantage—for either the skinner or the end-user—to use that option in skin.xml?
its historical and was done for Alumni's skins before more general support was added - his skins were specifically designed for 2 line display

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
Thnx for explaining.
I am now in the process of slowly correcting some probably wrong assumptions that I've always had about how things work regarding font/panel size ratio.

One thing I learned today is something I never new/expected:
When I use a background image with a height of e.g. 50 pixels, I always thought the player panel would be at least 50 pixels high, and it would only get enlarged when a larger font makes that necessary.
That's why it always surprised (and annoyed) me that MusicBee quickly starts increasing it's size even with small fonts, while there is more than enough space considering the available 50px.

But today I think I noticed that the background height can also be reduced by MB depending on the font size.
So the background image height is not treated as a minimum defined height, but it is always dynamic?
The 'sizing engine' is unaware of- and ignoring the actual available space?
The height of the background.png and the size of trackinfopanel are irrelevant?
MB will always decide on increasing or reducing the panel, solely depending on the font size and nothing else?

This might explain why the panel is getting needlessly enlarged in many cases.

I could probably try to avoid this by using much lower background images, but while that would probably indeed improve the font/panel size ratio, it can also easily spoil the intended design of the player panel.
I'll have to do more testing to see if I can get the results that I want, but I am wondering if it wouldn't be better if it would work as I thought it did:
The background image height is never reduced, and it only gets enlarged as soon as the font size doesn't fit anymore.

This is also why I asked earlier if the font size engine was looking at the height of the trackinfopanel, or at the heighth of the panel to decide if the panel should be enlarged.
But I know understand that understanding was probably a misconception and it doesn't work like that at all.

edit,
I just tested using a very tall background image size of 100px, and it seems this is indeed how it works. The panel already gets enlarged when choosing font size 12.
hmm

edit2:
To clarify the reasoning behind this: (it's not just some pixel ocd)
I could easily go back and keep using fixed panel sizes for my skins and just forget about all this.
But it would be nice if the panel could be exactly as tall as intended for single track lines (perhaps increasing when fonts are getting really large), and would (almost for sure) increase when multiple lines are selected by the user.
Last Edit: January 23, 2021, 05:41:23 PM by hiccup

hiccup

  • Sr. Member
  • ****
  • Posts: 7799
Another thing comes to mind:

Currently the top of the font is positioned depending on skin settings.
That makes it impossible to maintain vertical centering of the text for different font sizes.
Perhaps make it possible to have the center of the font positioned?
For multiline it would have to be the vertical center of the two lines combined.

(this is mostly relevant for fixed panel sizes)
Last Edit: January 24, 2021, 10:14:38 AM by hiccup