settings plugin/class

[reven]

ok when i first starting playing around with making a plugin, i began working on a settings plugin, as gbpvr seems to be missing this, however ran into issues:
- what if the plugin developer completely changes something; then the settings for that plugin no longer work
- only a limited number of plugins will have settings
- what if i buggered off and the settings were no longer maintained
- how do i force the plugins do update these settings?

ok now with auto update, discussion lead to downloading new plugins, skins. if you download a skin in gbpvr you dont really want to quit go into the config and change the skin, thats annoying if you can download it in gbpvr shouldnt you be able to change it in gbpvr? (ok we arent there yet, but im sure we are going to get there, yeah im optimistic).

anyway, i was thinking long and hard (err maybe ten minutes) but what if each plugin had a subclass called "Settings" (or something) and in the class we had a few methods
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">///proccess keyevents
//returns if handled
public bool KeyPress(Keyevent e){
}

//draw method (or is it render?)
//returns err whatever the normal draw method returns
public somethign Draw(){
}

//restarts the settings (eg button positions etc)
public void activate(){
}[/QUOTE]

and the IMenuTask would add this method
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//returns a class of type "SettingsScreen"
public SettingsScreen getSettings(){
return null; //if no settings are needed
return new SettingsScreen();
}[/QUOTE]


now there would be a &quot;Settings&quot; plugin, this plugin would show every plugin in a menu (much like the main menu, even possible display the task images), instead of starting the plugins normal, it would just call the &quot;Settings&quot; class, and pass the keyevents and draw method to this class. if the keyevent returns false (ie the keypress wasnt handled, eg &quot;back&quot; or &quot;home&quot; then the primary &quot;Settings&quot; plugin would handle this, but not by default, incase the plugin wants to process the &quot;back&quot; button internally).

so this means every plugin would handle its own settings screen, every plugin would be aware of the updates and can update itself accordingly, every plugin on the menu could have a settings screen.

the best solution would probably be to let sub make the initial class (since gbpvr seems to have no problem starting plugins, and every other plugin needs the dll to be in the gbpvr root directory (well i think it does), also this should be package with gbpvr itself).

ok i think this is a good idea (well its mine, so course i would), but gbpvr is missing this, its going to need it, and very soon, i often find myself editing the config.xml file and quickly closing and then restarting gbpvr to change a setting, with this you wouldnt need to. its genius!

some what you all think?

[jorm]

I think it would be useful. What about creating a simple/default interface for just creating a settings xml file. That each plugin would specify. The xml file would have

for example theater_settings.xml
&lt;settings&gt;
&lt;setting name=&quot;zipcode&quot; value=&quot;33063&quot;/&gt;
&lt;/settings&gt;

The plugin would get what is in there and show the list.

I would still allow them to do more if they want, but most plugins have a couple of fields that might be easier this way.

[reven]

a little bit of revision, instead of using
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//returns a class of type "SettingsScreen"
public SettingsScreen getSettings(){
return null; //if no settings are needed
return new SettingsScreen();
}[/QUOTE]
put a virtual method in the IMenuTask class, so if the plugin doesnt define one, it still works, and just make the child override it.

things that i would find very useful in here
- turn on/off panels (getting available panels from main menus skin.xml, and alterating visible=&quot;true&quot; in that)
- changing default bit rates
- turning show dvd button on/off
- changing skin (the biggy)
- start window mode on/off
- turn some plugins on/off (only the ones that are supported in all the skins, fm radio, guide, live tv etc).
- changing pre/post show padding
- changing overlay manager (if this is possible)
- turn on/off using ffdshow
- dvd aspect ratio
- use short skip on/off
- prompt for resume

see there is lots of things, i guess this is just my way of asking sub, what do you think? the basic setup would have to come from you, the rest could be handled by plugin developers. we would have to make a few controls (i think the widget library could come in handy here), things like checkboxs etc, and maybe setup a xml schema for the skinning of the settings screen, since using the same controls.

[KingArgyle]

Jason and I had a thread going about possibly redoing the skinning in general. Seems like it would fit into this whole plugin redesign thread as well. I know Jason is looking for help with the Widget library. Unfortunately my programming free time is pretty limited these days, but I can help out with the Schema designs so we have a good idea of what the data structures should look like before we move to the programming aspect.

In the long run, if we can make everything a type of Widget, and then have the skin reference the widgets, I think It'll go a long way in making the Skinning more consistent with the plugins. Same goes for Settings. I'd like to make stuff more descriptive and less like a programming property file. That is one thing I hate about .NET and it's PropertyBag XML files. Doesn't tell you at all what it is from a non programming aspect.

[jasonf]

Just FYI: I'm relatively close (within days, hopefully) to making an alpha release of the widget library. I expect it to be a little buggy, but will serve as a baseline for ongoing development (and input from the community).

It will contain a demonstration of the streamlined xml widget form files which are xhtml-like (that is, something like html that conforms to xml structure syntax, and as such, lends itself to schema validation and all that other stuff that King likes).

[KingArgyle]

Two main reason I like Schemas are:

1. Relieves the programmer or application from much of the data validation. Leaving only business/application rule validation.

2. The application that is processing the XML file nows that it is valid/well-formed XML file and contains everything that it would expect it to according to the rules of the Schema.

Again less data validation that has to be done by the program. And typically it takes only two or three lines of code to validate the XML against a schema.

[jrockintuitive]

I will apoligize for my question because I'm still on my learning curve....

Isn't the config.xml file designed to be used to store genral settings, even for plugins?

I know it would still be usefull to have general settings for all plugins - and a plugin to edit these settings.

[reven]

yeah most settings are stored in the config.xml file, but once gbpvr is loaded, altering these settings wont do anything until gbpvr is reloaded. the settings class would just have the responsibilty of altering the settings for the specific plugin and informing that plugin if some settings have changed and if they have what are these changes, so the can be updated automatically. its useful if you are like trying different decoders, and dont want to restart gbpvr, tweaking gbpvr how you like it, so you dont have to keep restarting gbpvr. the more things that can be handled via a remote the better i think, its a pvr, having to alter settings in the config for every plugin can get annoying especially if the plugins get updated alot and the settings need to be changed (my fault here, im always adding new things, but new things are generally better). just so you can configure gbpvr without the config app would be nice (well most parts of gbpvr, not the capture sources etc).

[jorm]

I wonder if we can get sub to add something like

void propertyChanged(string xmlPath, XmlNode node)
{
}

That would be overridden on each plugin. And provide a hook to alertAllListeners(string xmlPath, XmlNode node) such that when the alert is invoked it would walk the plugin list and inform them that an entry has changed. Most will not care unless it is a setting that some plugins use for example fastfind uses pre/post padding.

I have been talking to jrock about making some of the CDK settings updatable in the application and do not want to develope a plugin specific solution when a generic one can be done in less time.

[jorm]

Actually we can do the plugin side on our own. We create a singleton in a dll called SettingsListener. When plugins start off they register themselves in the activate method. It holds all of the plugins in a list if they are not already in there.

We then create an interface for the plugins to be invoked and put the call to invoke the listeners method on settingslistener.

I can work on this and/or the plugin if people agree and reven is hasnt already started.

This plugin would be very useful.