Is there any possible way to have a "settings" option on skins so that a configuration dialog could be popped up to allow the admin to adjust features of a skin/module?  If not, it sure would be a handy addition to DNN!

The reason I ask is that I am building a skin that has a number of options which can be controlled via CSS.  I know that the styles can be adjusted on a portal or page level, but it sure would be a lot easier to have a configuration option that could also apply per portal / page.  For a novice, entering style statements can be a problem.  The only other option is to have a ton of variations to the same skin which could be pain.

This same thing applies to panes on a page.  It seems that many people releasing skins put out various versions of the same skin to allow of different numbers or placement of panes.  Of course for panes, it would probably be better if a pane splitter/grid functionality could be added to the dnn core so skin developers do not have to worry about the varations.

Modules have a settings dialog that can be called up to configure a module, but with skins there is nothing a user can set unless they set them in CSS.  It would be great if skins has the same ability, that the designer could have a configuration for the skin where the could list options which typically the configuration dialog will set in CSS for the site, but would not be limited to just that. 

It would make it a lot easier on the end user than having to hunt up documention to see what values they might want to change in CSS or modifications to the skin itself.  They would just click on a configuration dialog and have a list of things they can easily change.

At the least, it would be great to have a configuration dialog for skins built into the system that could be driven by an xml file where designers could list out options in CSS the end user can change on a page/portal level along with maybe the option (specificed in the xml file) to show alternate CSS files for the skin allow for one single skin but many variations.

Well, if you have a skin that is very flexible via CSS, it could force dozens if not hundreds of possible combinations in a skin pack which could easily be handled by a configuration menu.  For an example, if you have a skin that is easy to change the color theme via CSS, you might make eight different versions for eight base color combinations.  Next, you might want to have a two panel version, three panel version and maybe one that has a head/foot panel.  That is another 8 possible combinations.  Add the layout to the color choices and you have 64 different skins in a skin pack that could easily be handled by a configuration window to select layout and color (although layout selection would have to be handled by skin modification or something like that since CSS would not be able to enabel or disable panels since in admin mode they would automatically be enabled again, in a worse case there would up to eight layout combinations for the skin and a configuration window for color choice).

You would want the user to be able to change anything or choose from a few prepared skinvariations?

If we are talking about predefined settings (such as I mentioned in an xml file) actaully, it would probably be both. Some settings may have a limited number of options while others, such as color, may be unlimited.   For example, you might have a color choice option that swaps image urls in the CSS for the different predefined colors, while another setting might be to change the the alignment of the header or logo which would have a predefined list of options, but you might have a setting to change the color of a text item or URL link color, which would be unlimited as the user would just enter a value for it.

In the xml file it could be something like

<group name="Color and Shape Settings">
   <setting name="Header Text Color" type="CssValue" css=".headerTextColor" />
   <setting name="Header Top Corners" type=CssList">
       <csslistitem name="Round Corners" value=".headerLeftCorner { background-image: url(%skinpath%HeaderLeftRoundConer.jpg);} .headerRightCorner { background-image:url(%skinpath%HeaderRightRoundCorner.jpg); }" />
       <csslistitem name="Square Corners" value=".headerLeftCorner { background-image: url(%skinpath%HeaderLeftSquareConer.jpg);} .headerRightCorner { background-image:url(%skinpath%HeaderRightSquareCorner.jpg); }" />
   </setting>
</group>
<group name="Alternate Themes">
   <setting name="Theme" type="cssIncludeList" >
       <cssincludeitem name="Maroon Theme" includefile="%skinpath%MaroonTheme.css"/>
       <cssincludeitem name="Blue Theme" includefile="%skinpath%BlueTheme.css"/>
       <cssincludeitem name="Green Theme" includefile="%skinpath%GreenTheme.css"/>
   </setting>
</group>

 In this example, it would display a configuration window with two tabs called "Color and Shape Settings" and "Alternate Themes".  In the first tab it would show two options, the first would be labeled "Header Text Color" and have an input next to it to enter the color.  The next option would be called "Header Top Corners" and have a dropdownlist containing the options: "Round Corners" and "Square Corners".

The other tab would contain a single settng labeled "Theme" and would have next to it a dropdownlist with the options "Maroon Theme", "Blue Theme" and "Green Theme".

It is probably obvious what the configuration manager would do when options are selected, but here it goes.  On the Css value and Css list types, it would simple add in the css statements in given in that setting to the current page/portal css override settings, much like you would do manually to override a CSS value for a given page/portal.  The CssIncludeList would make dnn add the css file that was selected to the page/portal thus overriding any previous settings.

Just this one feature of having a configuration manage would be a great help in building skins without having to dump out large volumes of skins in skin packs or heavy documention on how to change the flexible portions of a page.  Another example that comes to mind is for full width or fixed width skins.  Currently, most people provide different versions.  Often it could be handled through a CSS setting which such a configuration manager would be easy to select, thus the skin developer only has to show one skin, but in the skin configuration, they could select the width and/or full width/fixed width.

 Personally I wouldn't like my customers to be able to change everything they want.

 It depends on what you mean by "customers".  I am only suggesting this configuration manager for "admin"s to be able to use not people visiting a site.  If you have the ability to change a skin you would have the abiltiy to configure it. 

Of course, this brings up another point I would love to see in DNN someday and that is role/user based settings an virtually every option in DNN.  Often, I want to give the end user (person who owns the portal) the ability to see traffic logs (in the past that is, always have them use Google monitoring system now) or to configure a specific module without having other admin rights.  It is kind of dangerous to turn portal over to a client after the initial design :)