Author Topic: 3.4 skinning questions  (Read 4825 times)

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
1.
- For standard skins the last.fm icon can be hidden in the player controls panel using right click/ Panel Layout/ Show Last.fm Scrobble Button

Will this option be available for bitmap skins if position substitutions are added to the skin.xml?


2.
Is the code for the visualiser in xmplay available form un4seen?


If so, could that be added as on option or replacement for the current player bar visualisation?
MusicBee and my library - Making bee-utiful music together

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
1.
- For standard skins the last.fm icon can be hidden in the player controls panel using right click/ Panel Layout/ Show Last.fm Scrobble Button
Will this option be available for bitmap skins if position substitutions are added to the skin.xml?
Not currently but i will have a look at what is involved. I dont want to do anything that breaks the backwards compatibility for the xmlc files, so it would be easier to do this as a standard behaviour. If MB treated the icon of the scrobble button as having 0 width, and placed it in the same horizontal position but vertically off the panel do you think that would work? So any elements that are relative to the button should still work nicely with placement. A skin setting would need to be set to indicate your skin works ok with that approach.

2.
Is the code for the visualiser in xmplay available form un4seen?
If so, could that be added as on option or replacement for the current player bar visualisation?
its orientation is horizontal so takes up a lot more space. I will have a look at what would be involved but would want a definite commitment to implement it if i do go ahead as it would be non-trivial.
Last Edit: July 11, 2020, 05:01:32 AM by Steven

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
If MB treated the icon of the scrobble button as having 0 width, and placed it in the same horizontal position but vertically off the panel do you think that would work? So any elements that are relative to the button should still work nicely with placement. A skin setting would need to be set to indicate your skin works ok with that approach.
Just looking at my included bitmap skins and that approach would work with them.


its orientation is horizontal so takes up a lot more space. I will have a look at what would be involved but would want a definite commitment to implement it if i do go ahead as it would be non-trivial.
I would certainly implement it into my skins.

Maybe it could be rotated to a vertical orientation.  In xmplay it is 17px high. If rotated, it could be stretched/padded to match the current 32px fixed width.  It would then just slot into the current spectrum position.
MusicBee and my library - Making bee-utiful music together

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
oops. deleted the wrong bit. above post edited.
MusicBee and my library - Making bee-utiful music together

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
i think the suggested approach only works well if the buttons on either side of the scrobble button are relative to each other. It seems most of the skins are probably just using an offset from the right hand panel width, so that just ends up leaving a gap where the scrobble button was.
So I dont think its going to generally work and not sure i can see solution that works without the skin-author making substantial changes to how the layout is done
Last Edit: July 11, 2020, 06:35:03 AM by Steven

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
for 2, would you be able to do a quick mock up of how you think it would look?
I guess it could split the left and right channels for the top and bottom graphs respectively

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
option #1

changing to vertical orientation


option #2

changing to vertical orientation and splitting LH/RH channels
MusicBee and my library - Making bee-utiful music together

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
i think the suggested approach only works well if the buttons on either side of the scrobble button are relative to each other. It seems most of the skins are probably just using an offset from the right hand panel width, so that just ends up leaving a gap where the scrobble button was.
So I dont think its going to generally work and not sure i can see solution that works without the skin-author making substantial changes to how the layout is done
I thought the skin author could make adjustments here:
Code
<!-- spectrum, love and rating can be hidden by user preference - when an element is located relative to one of these (hidden) elements, the following rules specify which element should be used instead for the relative reference -->
<!-- the offsetAdjustment attribute enables you to tweak the offset of the dependee element eg. if TrackInfoButton depends of Spectrum with an offset of 15, when Spectrum is hidden TrackInfoButton is placed relative to TrackInfoPanel.Left with offset 8 (15-7)  using the rule below -->
<!--<replacementElement id="Spectrum" replaceWith="TrackInfoPanel.Left" offsetAdjustment="+6" />-->
<replacementElement id="TrackLove" replaceWith="EqualiserButton.Left" offsetAdjustment="0" />
<replacementElement id="TrackRating" replaceWith="VolumeSlidebar.Right" offsetAdjustment="0" />

A skin setting would need to be set to indicate your skin works ok with that approach.
If the author did make the proper adjustments, then this option would let MB display the "Show last.fm Scrobble Button" option
MusicBee and my library - Making bee-utiful music together

Clarence

  • Full Member
  • ***
  • Posts: 145
I hope you don't mind if I throw my two-penny-worth in here.

Is having the LastFm button really that much of an issue?  I currently skin to allow the LOVE button to be hidden as that seems to be inherited, so I comply. However, lots of users don't feel the need to have a stop button. I quite like one so lots of my skins include a dedicated button. So does that need to be optional or do we just accept that some things are what they are? Ditto for any other button.  From a woking point of view, even if using the 'replacementElement id=' option is feasible, that would still mean retrospective amendments to every skin where placement is via proximity to another object. I'm dubious that this would have the desired effect where placement is set to a specific distance from an edge/object.

Whilst I agree with the sentiment of changing the play bar visualiser to something other than a 34px wide series of blocks, could the volume visualiser style not be incorporated in the player (as I suggested here: https://getmusicbee.com/forum/index.php?topic=31689.0 ). To me it would seem a more logical place for it rather than in the panels. I appreciate that the XMPlay visualiser has the horizontal pulse effect and I personally would welcome some variation on visualiser effect such as click to switch between vol/spectrum/oscillating. However, simply porting the volume visualiser to the player would be a big leap in my opinion.

hiccup

  • Sr. Member
  • ****
  • Posts: 7785
1.
- For standard skins the last.fm icon can be hidden in the player controls panel using right click/ Panel Layout/ Show Last.fm Scrobble Button
Will this option be available for bitmap skins if position substitutions are added to the skin.xml?
Not currently but i will have a look at what is involved. I dont want to do anything that breaks the backwards compatibility for the xmlc files, so it would be easier to do this as a standard behaviour. If MB treated the icon of the scrobble button as having 0 width, and placed it in the same horizontal position but vertically off the panel do you think that would work? So any elements that are relative to the button should still work nicely with placement. A skin setting would need to be set to indicate your skin works ok with that approach.

Probably a lot of MusicBee users will not be using lastfm and scrobble. (I would guess the majority)
So it makes perfect sense to me that a user should be able to remove that icon/button from being displayed for bitmapped skins also.

But for those this surely could be a little bit complex.
You can probably divide bitmapped skins in two sorts regarding this:

- The first that have rather straightforward button and background designs, where it is perfectly doable to use the same element replacement feature as you would for Spectrum, Love and Rating.

- The second sort are the graphically more complicated designs with some pixel-perfect button alignments and more sophisticated backgrounds and panels.
For those a solution could be to have a new image element for scrobble, namely something like: NoScrobble.png
For some skins the skinner could choose to use a transparent image with the same size as the other scrobble images.
For other skins he could design a dedicated NoScrobble image that blends in his skin in a manner of his choosing.

So then when the user sets to have the scrobble button not displayed, MusicBee should look for if the skin has an element replacement set, or that it has a NoScrobble.png defined in the skin.xml.

If this could be done, I would surely retro-fit it in most of my skins.

Bee-liever

  • Member
  • Sr. Member
  • *****
  • Posts: 3830
  • MB Version: 3.6.8830 P
Is having the LastFm button really that much of an issue?  I currently skin to allow the LOVE button to be hidden as that seems to be inherited, so I comply. However, lots of users don't feel the need to have a stop button. I quite like one so lots of my skins include a dedicated button. So does that need to be optional or do we just accept that some things are what they are? Ditto for any other button.  From a woking point of view, even if using the 'replacementElement id=' option is feasible, that would still mean retrospective amendments to every skin where placement is via proximity to another object. I'm dubious that this would have the desired effect where placement is set to a specific distance from an edge/object.
The backwards-compatibility that Steven is striving for would mean that you don't have to update your skin if you don't want to.  It would work perfectly fine "as is" and the "Show last.fm Scrobble Button" option would only become available in bitmap skins if you want to make a change to your skins.


Whilst I agree with the sentiment of changing the play bar visualiser to something other than a 34px wide series of blocks...
Yes.  I was looking around for something simple that could replace the current "in-bar" spectrum visualisation.  I think the current "in-panel" visualisations give a good mix, but the current, basic 5 column one could use an upgrade/make-over.

I suggested the xmplay one as I thought the code would be readily available.  If you, Steven or anyone else has another suggestion please feel free to post it here.
MusicBee and my library - Making bee-utiful music together