A couple of changes

[Old Dog]

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

The user interface for these setting would definatly need some pretty good clues.

[Old Dog]

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).

This is good, each plugin provides their own UI for their settings.

[reven]

This is good, each plugin provides their own UI for their settings.

not there own ui, just a a 2 dimensional array of controls,
the first dimension = the pages
the second dimension = the controls

the controls would implement a common interface so drawing, controlling etc would be a piece of piss

foreach(Control c in page.controls)
c.draw();

etc.

but hey, theres probably a better way to do it, thats just what i first came up with.

[Old Dog]

revens screen shot is pretty.

At least initally it might be wise to suggest that the UI be plain and simple and all have a common appearance. Maybe not even be skinable. This would keep the initial workload down for everyone, avoid a skinning competition, allow time to breath before moving on.

[Old Dog]

not there own ui, just a a 2 dimensional array of controls,
the first dimension = the pages
the second dimension = the controls

the controls would implement a common interface so drawing, controlling etc would be a piece of piss

foreach(Control c in page.controls)
c.draw();

etc.

but hey, theres probably a better way to do it, thats just what i first came up with.

I really did like it.

[sub]

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?

When I call Reload(), I want the plugin to reload everything...settings, skin etc.

On all of my screens, I've created an initialize() function, which load any settings it needs, creates the instance of SkinHelpers, loads any position information from the skin files etc. My intention for the built-in screens is just to call this initialize function again when reload() is called.

The other methods on ISettings would be for things like MP3 directories etc.

[sub]

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....

I could do this, but I really want things to look consistent, so I'm tempted to only allow for set types initially, and we can look at adding other types down the track. ie, I only want to see one implementation of a checkbox, rather than everyone implementing their own slightly different one.

[reven]

I could do this, but I really want things to look consistent, so I'm tempted to only allow for set types initially, and we can look at adding other types down the track. ie, I only want to see one implementation of a checkbox, rather than everyone implementing their own slightly different one.

yeah thats what i meant, instead of letting each plugin draw the screen, handle key presses etc, just get a list of controls from each plugin. a control would be defined in the GBPVR.Public (or GBPVR.SettingsControls or something) namespace. that way all the controls would look exactly the same, and skinning would all happen in one place.

also it would mean less work for each plugin since all it really needs to do is pass back an array of controls.

[sub]

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

These are good ideas, but probably take it further than I wanted to. I dont really want to get into grouping settings or inter-setting relationships etc at this stage.

The display order would be based on the order of the list returned from getAllSettings()

[sub]

yeah thats what i meant, instead of letting each plugin draw the screen, handle key presses etc, just get a list of controls from each plugin. a control would be defined in the GBPVR.Public (or GBPVR.SettingsControls or something) namespace. that way all the controls would look exactly the same, and skinning would all happen in one place.

also it would mean less work for each plugin since all it really needs to do is pass back an array of controls.

Thats not quite what I meant. I hope to abstract things a little further. ie, you can say you have a called 'blah blah enabled' of type BooleanSetting, and I would decide what control to show based on that type.