Plugin developers read

[sub]

I wanted to post a reminder to developers about some changes that occurred earlier this year.

A common cause of problems in GB-PVR is trying to use a plugin with a skin that does not explicitly provide support for that plugin. This problem occurs because the plugin is expecting to find its supporting skin files (skin.xml and image files etc), but they are not contained with in the active skin.

Early this year I made a change that will take advantage of the fact that all plugins support the default (blue) skin. Specifically, SkinHelper was changed to automatically fall back to using these resource files in the default skin if they’re not available in the active skin.

This change will only affect things explicitly defined in the plugin’s skin xml file(s). Things that are inherited from the BaseSkin.xml will continue to be loaded from the active skin. This means that buttons will still have the correct appearance for the current skin, and the background image will be correct.

To implement support for this functionality in your plugins, you need to use the correct constructor to SkinHelper. The older constructor to SkinHelper did not provide all the information that was be required to support this.

To use this new functionality, the plugin developer would create a SkinHelper instance using:

Code:

[FONT=Courier New]private SkinHelper skinHelper;[/FONT]
[FONT=Courier New]…[/FONT]
[FONT=Courier New]string pluginName = “TV Guide”; // …also the skin subdirectory[/FONT]
[FONT=Courier New]string skinFileName = “skin.xml”; // note the missing path[/FONT]
[FONT=Courier New]skinHelper = new SkinHelper(pluginName, skinFileName);[/FONT]

Behind the scenes the skin helper will determine the correct path and load the XML file. If the XML file cannot be found in the active skin directory, it’ll fall back to using the default one in the blue directory.

Having plugins support is becoming more important as we make an effort to clean up the skinning in GB-PVR. If you have plugins not currently doing this, please try to make this small change in the very near future.

[reven]

the reason why i dont use this:

each of my plugins have been through different versions, and the skin has changed. so if the skin they are using only supports the original plugin, and i use that constructor in the latest one, it will load the skinhelper with an old skin. thus not working

so can you add a third param called version? and just do a string compare on a special attribute "Version"
eg

Code:

<settings>
<Version>2.54.56</Version>
....
</settings>

and if they dont match, default to the blue skin.
thats what im basically doing manually now.

if its just a string compare then each plugin can use their own version numbering.

[psycik]

I did it. I think it makes sense. I can't remember how many people that I;ve "moved on to " gbpvr only to have them frustrated by skins/plugins combinations.

Same with the community skin projects going on with Fatman_do, old_dog and mixman, they're trying hard to come up with a scheme that will make it easier for the end users which is really what we have to think about it.

And if this is the first lead up to it then i think it's a good start.

I think after a while sub, you might want to break functionality with the old constuctor...to enforce conformity.

[reven]

I think after a while sub, you might want to break functionality with the old constuctor...to enforce conformity.

god no, i use that when creating dvd menus for the "my dvd" feature of my vids (not stored in the skin directory you see).

[sub]

Reven, please just bite the bullet and make this change. It is going to be a vast improvement over what we currently have.

[reven]

Reven, please just bite the bullet and make this change. It is going to be a vast improvement over what we currently have.

yeah but it wont work, because of different versions.

i would change if it worked under different versions.

[sub]

Why do you always have to be so difficult? Please, just change it.

[reven]

so the skinhelper, checks to see if the skin exists, if it does it loads that one, but what happens if the skin it loads is a old skin that no longer works with the plugin? what happens when it tries to get a node/compositeimage that doesnt exist?
does it crash and throw a fit? or does it automatically get that node/composite image from the blue one?

[psycik]

But surely when you've released whatever version of your software, and you've missed X skin (not blue), you would have updated the blue skin when you released??

So therefore it should load that.

[sub]

so the skinhelper, checks to see if the skin exists, if it does it loads that one, but what happens if the skin it loads is a old skin that no longer works with the plugin?

We need to think ahead here. With the way I'm trying to move things, the majority of skins wont contain a definition for My Videos (for example). Instead, it'll only be defined in the default skin - and it'll be the correct version, because it was installed with your plugin.

In the future I'm hoping new skins will contain very few files (background.jpg, baseskin.xml, preview.jpg, maybe some custom buttons images or some other overridden images), the rest will be picked up from the base skin. It'll still be possible to have customized skins, but in the majority of cases this wont be required.

It'll also give you the benefit of your plugins working with new skins even though nobody explicitly added MyXxxx support to the skin. As you change your plugins, those skins will continue to work with your new plugins without the need for any changes.