Plugin developers read

[Torque]

Who benefits? The web site administrator (the skinner)! One person, and not the end user at that.

But it does nothing for my five-year-old-end-user with his remote control.

I don't think you could be more wrong.

How doesn't the end user benefit? User finds a skin that looks the way they want only to find plugin X and Y doesn't work with it or even worse causes crashes. a) they call it quits and use some other software. b) They post the problem on the msg board which takes the time of one to many people to solve.

I see it completely the other way, it would add creativity! I have so many friggin' skin ideas I'd like to do but when I think about how much time it would take to go thru every skin.xml file to make my dreams reality, I shelve them.

Think about it. The ability to set the color, style, and position for buttons/text/boxes/etc for data area, notes area, and header area in one file based on your theme/dream and know that any plugin will work. But you'll still have the ability to tweak each individual plugin if you want. Yes, I understand that the more complex plugins like video archive have a radically different layout, but it would help tremendously if the rounded box and text styles could play off the baseskin if it wasn't defined in it's own skin file.

Something in the baseskin that said:

[SIZE="2"]boxHeader = {DrawRect borderWidth="2" borderColor="Black" fillColor="#FFFFFF" loc="10,10" size="700,30"}
box1 = {DrawRoundedRect radius="10" borderWidth="2" borderColor="Yellow" fillColor="Vertical:#FFFFFF-#2BA301"}
textHeader = {DrawTextWithOutlinetext size="200,50" fillColor="White" borderColor="Black" outlineWidth="1" align="Left" loc="11,11" size="698,20"}
text1 = TextStyle color="LightGray" typeFace="Arial" size="13" style="bold"}[/SIZE]

then in the plugin skin:
[SIZE="2"]<DrawRect style="boxHeader"/>
<DrawText style="textHeader" text="Main Menu"/>

<DrawRect style="box1" loc="4,5" size="155,30"/>
<DrawText style="text1" text="blah blah" loc="6,6" size="100,20"/>
[/SIZE]

[Torque]

whoops, i hit submit instead of preview... sorry for the big text.

[McBainUK]

At some point I will stop copying over the slins and just rely on the built-in GBPVR methods.

For the next release of my plugins I will be doing this too. Wasnt aware of this new constructor before.

[daphatty]

I don't think you could be more wrong.

How doesn't the end user benefit? User finds a skin that looks the way they want only to find plugin X and Y doesn't work with it or even worse causes crashes. a) they call it quits and use some other software. b) They post the problem on the msg board which takes the time of one to many people to solve.

I see it completely the other way, it would add creativity! I have so many friggin' skin ideas I'd like to do but when I think about how much time it would take to go thru every skin.xml file to make my dreams reality, I shelve them.

Think about it. The ability to set the color, style, and position for buttons/text/boxes/etc for data area, notes area, and header area in one file based on your theme/dream and know that any plugin will work. But you'll still have the ability to tweak each individual plugin if you want. Yes, I understand that the more complex plugins like video archive have a radically different layout, but it would help tremendously if the rounded box and text styles could play off the baseskin if it wasn't defined in it's own skin file.

Finally, someone properly articulates the intent of the baseskin.xml and how its proper use by developers/skinners directly affects end users! My sentiments exactly! Thank you, Torque!

[Old Dog]

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.

While the developers are making changes could we get them to refresh their skin related settings each time they are activated?

[daphatty]

While the developers are making changes could we get them to refresh their skin related settings each time they are activated?

That is the point of the baseskin.xml. If developers support baseskin.xml properly, they wont have to. A "refresh" will only be necessary when baseskin.xml is updated/changed.

[Old Dog]

That is the point of the baseskin.xml. If developers support baseskin.xml properly, they wont have to. A "refresh" will only be necessary when baseskin.xml is updated/changed.

And how will they know that?

[Jeff]

I think Old Dog's point is that when creating skins it is much easier for the skinner if changes to skin files are immediately reflected in the plug-in rather than having to shut down and restart GBPVR each time to see how your changes look.

Jeff

[daphatty]

I think Old Dog's point is that when creating skins it is much easier for the skinner if changes to skin files are immediately reflected in the plug-in rather than having to shut down and restart GBPVR each time to see how your changes look.

Jeff

Oh. I guess I didn't interpret his comment that way. I've seen him make that same suggestion before and I am all for it. I'm still trying to figure out you derived that meaning though.

[daphatty]

And how will they know that?

You mean besides sub telling everyone?