A couple of changes

[reven]

ok, just an idea.

[Old Dog]

This whole concept should be enabled/disabled via the config program, don't want kids breaking anything.

Also, all settings should be configurable via the config program.

[sub]

This whole concept should be enabled/disabled via the config program, don't want kids breaking anything.

It'll be just like any other screen, and able to be disabled in the plugins screen of the config app.

Also, all settings should be configurable via the config program.

I have no plans to provide a similar framework thing in the config app, so it'll just be as it is today (ie, depend on developers making their own configuration forms).

[Old Dog]

I have no plans to provide a similar framework thing in the config app, so it'll just be as it is today (ie, depend on developers making their own configuration forms).

Of course!

[gruskada]

reven - that page looks awesome. Is that part of a skin you're working on, or is that already released somewhere?

gruskada

[sub]

reven - that page looks awesome. Is that part of a skin you're working on, or is that already released somewhere?

gruskada

Its a screenshot from XBMC, a media player for the xbox.

[Old Dog]

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

Somehow this part didn't sink in for me the first time around. This is good and makes my comments on the UI moot.

[DaveC]

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

1) Using the default skin.xml files
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.


2) ISettings
I’m adding a new interface called ISettings which plugins should implement.

Thoughts? Comments?

Hi Sub ... fine thoughts, thanks for asking ...

My thoughts are simple:
1) Excellent ... a much nicer constructor than the current one. Also provides the default-to-blue behavior, like that.

2) Suberb idea, skin changes on the fly, I LIKE it ... although ... this would be an optional thing for the plugin then? I see half of them doing it and half not, maybe that's not an issue. Would you see this being mandatory at some point (although it would break all the old plugins)? If so, assume we would get some notice before the release?

As always, some ndocs-type thing would be useful ... dc

[sub]

2) Suberb idea, skin changes on the fly, I LIKE it ... although ... this would be an optional thing for the plugin then? I see half of them doing it and half not, maybe that's not an issue. Would you see this being mandatory at some point (although it would break all the old plugins)? If so, assume we would get some notice before the release?

I probably wouldnt make it mandatory, since it'll take a while for all plugins to support it. Instead I'd work on a shame scheme, were plugin authors are eventually hounded in to implementing it by users. I'd of course implement it for all the built in screens.

[DaveC]

I probably wouldnt make it mandatory, since it'll take a while for all plugins to support it. Instead I'd work on a shame scheme, were plugin authors are eventually hounded in to implementing it by users. I'd of course implement it for all the built in screens.

HA!! I like that scheme ... noob question ... could you just wrap it into IMenuTask as an optional method? If the plug did not implement, put something in the log to increase the shame level?