My vote goes to <pluginname>_settings.skin system. There is already Enforcer's RRUpd8, RRGrid, El Camino's RRWifiMan, Youtube and chevyn8's MediaLaunch using this system.
Works great and simple. Plugin manager settings sounds exotic, but perhaps too complicated and those standards hmm.
5 settings skins files, none of which are uniform, is simple where 1 uniform skin file for all plugins is exotic?
Originally Posted by Dartman_71
I guess i'm looking at it from different perspectives. The existing way isn't easy because developers either create a settings skin for carwings (which is the default, but not the most common skin) or dont skin settings at all and depend on the user using text editors to manually configure the plugin.
The alternative is to have one settings button which brings up all plugins and all of their respective settings. Doing it this way means developers have time to develop (Less skinning time) and users (experienced or novice) only have 1 way to set up RideRunner (RRConfig AND plugin settings could all be in one, touch-friendly location)
I think Sonic's right. Having to have a skin file for each plugin for each skin will kill this. Its hard enough to get skins for a plugin without needing config ones as well. One screen that can show any kind of variable would be easy to skin and the complexity is hidden in the code which is allways a good thing :)
Jeez, you guys are making this complicated.
The above images are used as a base.
Like CF you have settings which are text based, you make the image a button command, clicking this brings up the OSK to type in a value, or if there is something more exotic required like a browser then that will need to be coded by the plugin writer.
At the bottom you have numeric values which can be increased or decreased.
On the right you can set up boolean options using the true or false indicators.
It will be up to the skinner to do the graphics for their skin
The carwings is already done so aplugin writer as normal does their plugin, does a settings.skin for it (all they have to do is copy one that is done and change the button codes).
Settings2.skin can be added or settings3 if necessary.
A button can be added the the plugin mgr screen that selects the highlighted plugin and loads a <pluginname>.skin file.
This is what I am using in my iDrive skins and what my plugins will support.
The settings for nay plugin can all be called from one place, the plugin manager.
The skin images only have to created once.
And just a _settings.skin file has to be copied.
see one thing sonicx your missing, with CF Everyone(generalization) uses the same skin
with RR, Everyone(generization) uses a different skin
E has it right, adding a "settings" button to the skin's plugin manager screen, which will load the settings skin file for that selected plugin, is the right way to do it
E, can i see what you did with the carwings plugin manager screen...
my guess is a settings button on the right side, with some skincode...
button code one post up ;)
Whoops that's what I use in my idrive skin.
Hang on let me see if I have just skin code.
Ok, I know what I have done now.
That is the correct button code
What this does is creates a command pluginname_settings
now my plugins will intercept the command and load the settings screen and do any necessary processing required.
for wifiman I put a translation in exectbl.ini
So, if the plugin has a <pluginname>_settings command, then that will be handled by the plugin, if not then a translation in exectbli.ini is required.
Originally Posted by mitchjs
i'm not missing that.. i'm making a point that its better to go THIS route because people use different skins. I absolutely think this is the way to go