Skinning Guide - Part 5 - Dependent Skins

[Rotem K.]

Explanation:
Dependent Skins allow your skin to inherit all color, image and settings(?) elements from a parent skin.

Okay.. but what is it good for?
- If you're using a skin you really like but wantt just a small thing changed, using a dependency is the way to go.
- Dependent skins enjoys updates done in the parent skin.

Syntax:
   <?xml version="1.0" encoding="utf-8"?>
   <root dependsOn="PARENT SKIN NAME">
   <colours id="Default">
       ELEMENTS GOS HERE
   </colours>
   <images id="Default">
       ELEMENTS GOS HERE
   </images>
   </root>

A Dependent Skin For Example:

Blinghound's Pop Blue depends on my Pop Pink Skin File

 
If you still have any questions about dependent skins, or skins in general, ask away, I'll try and do my best to help.

[Greb]

One small addition: in case of 'overwriting' an element that has properties, thos properties have to be in the dependant skin too, even if they don't change.

For example: imagine you want to 'overwrite' this element in the dependant skin:

<element id="Content[Artwork]" bg="X,X,X" fg="X,X,X" bdr="X,X,X" />

That case you should include those elements  in the depedant skin too, even if they share the same values in the dependant and the original skin:

<element id="Content[Artwork].HeaderControl.Default" bg="X,X,X" fg="X,X,X" bdr="X,X,X"/>
<element id="Content[Artwork].Body.Default" bg="X,X,X" fg="X,X,X" bdr="X,X,X" />

Until I realized that it gave me some problems!!!  

[Steven]

they should be the only two elements that cause problems because of the way they have been implemented. When i get some time i'll see if i can figure out a solution

[Greb]

Well, once you know it's not a big problem, since you only have to copy those two lines from the original skin to the dependant one.

Another issue: I was not able to overwrite the element 'Panel.ChildBody.Default' using dependant skins.

[VX]

Greb, you probably found the reason why I didn't succeed in creating iBee Dark dependent skin.
I used free Win Merge tool to compare the two iBee skin files.
Then I removed all identical lines form the dependent skin file leaving the different ones and retaining the syntax presented by Rotem above. A a result I got dependent skin but with the bug presented below:



I know that creation of dependent skins is not as easy as customization of certain colour elements with slider and colour palette as one can do with AIMP or Quintessential Media Player (see the screenshot below), but I did exactly what was described in the forum and got the above error. So I guess there is a bug.



Steven, is it possible to use a dependent skin with different root skins so that every time a dependent skin is selected, the pop up menu appears: 'Choose the root skin to apply the changes' 

To use a dependent skin with different root skin I follow Greb's tip:

A very easy way: I renamed the NEW NAME as Basic. So it's only needed to name the folder as the original skin and to place the skin inside with the name 'Basic.xml'. It works automatically.
That would be the case with Spotify Black, for example: http://www.mediafire.com/?99nn26v2r294he8
But you can use the skin you want as long as the folder has the name of the skin and the skin is named as 'Basic'

I like the solution, but I hope there is another way to achieve this that won't duplicate dependent skin files in different folders to use with different root skins. Thanks for considering 

[Sarge]

I know that creation of dependent skins is not as easy as customization of certain colour elements with slider and colour palette as one can do with AIMP or Quintessential Media Player (see the screenshot below),

I hope MB never goes the route of that boxy cookie cutter lookin soul less program QMP  (my opinion)

[Roadrunner]

Is it possible to refer to a skin out of another subfolder?

[Rotem K.]

Works for me.

Wasn't sure it can work so I just tried it on Pop Blue, entering the entire path after the "dependsOn".
<root dependsOn="C:\Program Files\MusicBee\Skins\New folder\Pop Pink">

[Steven]

anyone doing skins for a public release skin should not put any path dependencies in.
the way MB works is it will first try and open the dependent skin in the folder of the parent skin and if not found then the looks in the root skin folder

[Roadrunner]

Thank you both for the fast answers!

@RotemK: I'm going to try this, thx!

@Steven: My thought was to make a "MyFavorits" folder with very small improvements for my favorit exisiting skins, not worth to spread it all over the world. So, I wouldn't risk to loose my changes by replacing all other subfolders and I hadn't to copy and update the original file too.
Even more: This way I could have a dependent skin with no changes to the original skins, just to keep my favorits all together

[Roadrunner]

<root dependsOn="C:\Program Files\MusicBee\Skins\New folder\Pop Pink">

I've just figured out that relative paths are possible too, your example could be shortened to:

   <root dependsOn="New folder\Pop Pink">

But as far as I understand Steven, it was not the intention, that this works, so use it at your own risk and not for public skins...