Converting old skins (1 Viewer)

[blackheart42]

I completely agree that as new features are added to MediaPortal the skins will have to be updated to use the new features. But it seems that new versions routinely break existing features, hence the big nasty error message if you try to start MediaPortal with an out-of-date skin.

It seems like you have not understood the purpose of this warning message.

If MediaPortal makes one version step forward, then the skin version also moves upwards.

So if a skin was designed for 0.2.2.0 and you want to use it in 0.2.3.0 RC1 then you will see the informativ warning that this skin has been created for an older version of MediaPortal.

This does not mean that it doesnt work.

BUT it means that you will mostlikely miss i.e. new Buttons in some areas or whole "screens" because they have been added after the skin was designed.

i.e. If the skin was designed before the "toggle repeat in playlists" was introduced

you can check "do not show again" in that warning dialog and it wont appear again.

If you see such a WARNING DIALOG then this DOES NOT MEAN that the Skin is BROKEN,
it MEANS that it HAS BEEN DESIGNED for an OLD VERSION, and this COULD CAUSE that you WILL NOT SEE new BUTTONS or SCREENS.


​

Then the informative message should be reworded since all it says is:
"The currently selected skin is outdated. This will cause problems when using MP! (Do NOT file bugreports using this skin)". There is no suggestion that the problems will only be with new features. In fact, the skin that I prefer has a problem with RC1 that makes it hard to use until the developer fixes it.

I think that I remember seeing the "don't show again" box on the warning message, but it's not there with RC1.

As a result, when a new version comes out, skin developers must stop moving forward and check their skin to see what has broken.

i suggest that a skin developer should constandly (one time per week) check the BlueTwo skin for updates/changes (tutorial ::here:: ) if they want to stay in sync with development.

If someone plans to release his skin with 0.2.3.0 final, the it would be a very good idea to follow the tutorial. Not much skinchanmges have been done recently. Major amout are bugfixes because we move to the next final version.
​

A proper API would make it unnecessary for the skin developer to spend any time reviewing changes until he wanted to update his skin to include new features. Of course, this assumes that the number of bug fixes in the existing code has fallen to a low level.

Maybe you can tell me how that works with an example.
recently a new feature/button has been added in the playlists to turn the repeat feature on or off.

so in mymusicplaylist.xml line 36 the following has been added

<control>
        <description>Repeat on/off button</description>
        <type>togglebutton</type>
        <id>30</id>
        <label>486</label>
        <onright>50</onright>
</control>

If you use the latest svn with an skin which does not contain this new button, then you wont see it in the playlist. BUT it your skin is NOT broken, it still works!

So, how would your suggested API help the Designers in this case? [/INDENT]

The API would be a documented list of all interactions that are possible between MP and the skin. In the example you gave above the new button would be added to the document to show the new feature and how to use it. But the biggest value of the API is that once the new button has been added to it, it can only be changed if there's a bug fix and then the change is documented in the API. Rather than doing a compare between sourcecode versions and trying to puzzle out the new bits, the developer just goes to the API document to check the new or changed info.

Modern computer systems could not exist without APIs. They control how software interfaces with hardware, how operating systems interact with applications and how applications interact with each other. Some examples are BIOS calls, Windows32 API, even Google Maps has an API. They allow developers to work independently on different parts of a system and still have their parts work together without having to continuously monitor changes in those other parts.

Without a documented API, changes in MP can break a skin without anyone intending to or even realizing that it's happened. MP has already started along the API route with things like standardized id numbers for the XML pages. There's even an unused link on the developers page to "APIs and functions".

Lack of standardized APIs (not just between MP and the skin - I suspect that others will be required) will limit MP's growth in the future.

 

[infinite.loop]

Then the informative message should be reworded since all it says is:
"The currently selected skin is outdated. This will cause problems when using MP! (Do NOT file bugreports using this skin)". There is no suggestion that the problems will only be with new features.

that message is absolutely correct.

i.e. a ID has been changed, result is that one button is no longer working because the ID in the xml is wrong, then in the pas we GOT bugreports and wasted quite some time just because of an outdated skin.

If a new screen/feature/game is added, then MP will present you with a message that a xml is missing (because the skin is not uptodate) again this will cause a wrong bugreport and that the team is wasting time with testing.​

I think that I remember seeing the "don't show again" box on the warning message, but it's not there with RC1.

It is. i have just seen it yestreday ​

A proper API would make it unnecessary for the skin developer to spend any time reviewing changes until he wanted to update his skin to include new features. Of course, this assumes that the number of bug fixes in the existing code has fallen to a low level.

a designer can install 0.2.2.0, and reskin BlueTwo.
If he decides to update the skin to 0.2.3.0RC1 he has to diff out the changes in BlueTwo between these two.

So the Designer is not forced to check for changes until he wants to update his skin.​

The API would be a documented list of all interactions that are possible between MP and the skin. In the example you gave above the new button would be added to the document to show the new feature and how to use it. But the biggest value of the API is that once the new button has been added to it, it can only be changed if there's a bug fix and then the change is documented in the API. Rather than doing a compare between sourcecode versions and trying to puzzle out the new bits, the developer just goes to the API document to check the new or changed info.

that sounds extremely good. (any examples you have in mind? )

do you have any experience with such systems and the required online facilities?

if yes, then it would be nice if you could check how this could be integrated into MP.
because we would need someone with the knowledge and dedication to integrate it

note:
please keep in mind that i am not a developer. therefor i ask stupid dev questions ​