A couple of changes

[sub]

Just before christmas I mentioned in a post that was going to provide guidelines for developing plugins. As part of this, I want to address a couple of common problems, by implementing a few minor changes.

I’m trying to minimize disruptions to existing plugins, so the changes I propose allow for compatibility with the existing methods.

I've not got too much time I can commit to this, so appologize if this doesnt go as far as some might hope...providing an ultimately flexible perfect skinning engine could be a project by itself, let alone trying to implement the other GB-PVR features and provide user support at the same time. :eek:

Anyway, two initial changes I'm looking at are:

1) Using the default skin.xml files
A common cause of problems is using 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.

I’m proposing a change will take advantage of the fact that all plugins support the default (blue) skin. I’m intending to change the SkinHelper 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.

I intend to implement support for this functionality through the use of an additional constructor to SkinHelper. The existing constructor to SkinHelper did not provide all the information that would be required to implement this.

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

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

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.


ISettings
I’m adding a new interface called ISettings which plugins should implement. It is being added for two main purposes.

1) The first of these reasons is to provide a mechanism for dynamically changing the skin without restarting the application. GB-PVR will call the plugin’s ISettings.Reload() method when the plugin needs to reload there settings. In response to this, the plugin should reinitialize their SkinHelper instance, and reload and settings it requires.

2) This new ISettings interface will also be used to allow settings to be changed directly within the application, rather than having to use the Config app. Using this interface, plugins will expose a list of settings they support, each with a name, type, and their current values. A likely list of types includes:
• String, free text
• String, select from plugin specified list
• Boolean
• Number, with minimum and maximum values

To use this new settings information, there will be a new system configuration screen within GB-PVR. It’ll allow the user to view the list of plugins with settings. On selecting a plugin the user will see a list of settings the plugin supports and the current values, which were obtained by GB-PVR calling ISettings.getAllSettings(). On selecting a setting, the user will be able to edit the setting (using a screen based on the setting type). If the user changes the value, ISettings.setSetting(…) will be called.

Thoughts? Comments?

[povarotti]

Number, with minimum and maximum values

Maybe provide a step as well, so things like once a week (step = 7), etc, could be implemented.

(sorry to use VB speak, but that's the term that came to mind)

[reven]

will the ISettings interface use a "Settings" type plugin which will control the settings for all plugins that support this interface?

if so could you publish a Control interface to allow extra controls to be added in the future (so you dont have to program them yourself), eg someone might want to create a file browser control so you can add folders etc to a list from within gbpvr. of course the source for the new control might have to be added as part of the gbpvr core.


also a lot of the time a skin file will be found, but say if someone is using a "My Videos 4" skin that mightnt work when they are using a "My Videos 5" skin, even though the same elements are found (ive switched to relative values for a few things), can you make it standard to add a "Version" tag and check that to ensure the skin version they are using is compatible with the skin and if it isnt they fall back to the "blue" skin.

[sub]

will the ISettings interface use a "Settings" type plugin which will control the settings for all plugins that support this interface?

Yes, thats the intention. It'll also allow you to change the skin and couple of other things.

[sub]

if so could you publish a Control interface to allow extra controls to be added in the future (so you dont have to program them yourself), eg someone might want to create a file browser control so you can add folders etc to a list from within gbpvr. of course the source for the new control might have to be added as part of the gbpvr core.

I probably wont make a plugin type interface for this, but would accept donations of code if you want to see new types supported.

[sub]

also a lot of the time a skin file will be found, but say if someone is using a "My Videos 4" skin that mightnt work when they are using a "My Videos 5" skin, even though the same elements are found (ive switched to relative values for a few things), can you make it standard to add a "Version" tag and check that to ensure the skin version they are using is compatible with the skin and if it isnt they fall back to the "blue" skin.

I have been thinking about this, but I havnt decided yet exactly how a version should be incorporated. I'll have to get back to you on this one.

[Old Dog]

Yes, thats the intention. It'll also allow you to change the skin and couple of other things.

Just to make sure I'm following correctly.

Except for Reload()...

The Isettings interface allows changes to a plugins settings. Currently plugin settings have to do with functionality, for example, an mp3 directory path for a music plugin. So when you think of Isettings, at least initially, you're not really thinking of skin changes. Right?

[reven]

I probably wont make a plugin type interface for this, but would accept donations of code if you want to see new types supported.

yeah i didnt mean a plugin type interface, just an interface, i have started doing settings in a few of my plugins, and have just a simple interface for (well so far)
- checkbox
- slider
just a basic interface that those two controls implements. errr so what im asking for is just publish what a control would need to implement for it to work, like a render method, onkeydown etc. but im getting ahead of myself....

[Jeff]

Have you thought about display order? It would be nice to have a way to specifiy that a group of options belong together, kind of like you can do by putting elements onto a tab panel or in group box. I can also imagine times when the values of one options might depend upon the value of another option. Maybe some form of callback to the plug-in asking it to validate a propossed setting would be helpfull, like bool ISettings.validateSetting (string SettingName, object propossedValue).

Jeff

[reven]

when i was toying around with a "Settings" plugin idea i thought of using a "Page" system, where each plugin that implements the ISettings interface, would specify "Pages" and these pages held settings. the "Page" name would be displayed on a menu button and then the content for the current page would be on the right (err middle/right).

something like