(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

When this is implemented, will it be a themeable component?

It will be really useful, thanks

(No comment was entered for this change.)

I agree! We really need this feature.
Do you think about solutions with JSON options file which
is some kind of manifest, and automatically render to options page?

@gbawo... That's an interesting idea, I suggest you open a separate bug for that though.

Maybe it can turn options too limited. If you need a non-default option type you don't will do. In otherside, maybe be possible to define a custom-option. Example: http://jsfiddle.net/HqYtu/

@david7... That looks like a great place to start. 
For a large percentage of cases, default input types would probably be sufficient. Those requiring custom options are harder to satisfy, especially when extension sync is brought into the picture. 

Some sort of theming for the options pages would allow extension authors to provide continuity of experience between their popups, their icons, and their options page. This wouldn't be necessary for the initial release though. 

It would be nice if extensions had a subpage under the tabbed options page. It could be generated with some configuration specified in the manifest. Extension options would also become searchable then.

If you are using Chromium 11.x you can open Options and see how works currently. It's exactly how you suggest.

I suggest adding this to an extension's manifest.json:

{
    /*...*/
    "options": {
        "title": "My extension's settings" /*should be inserted into page title*/
        "tabs": { /*list of tabs for the left side*/
            "My tab": { /*tab name*/
                "Alert \"Hello\" on startup": "checkbox",
                "Say something after \"Hello\"": "text",
                "Password for example.com": "password"
            }
        }
}

Where the name is the label and the value is the input type (for selects, an array should be used instead)
Then when we need to get a value, in JavaScript:

if (chrome.extension.options.getTab("My tab").getValue("Alert \"Hello\" on startup") == true) {
    alert("Hello world!\n" + (chrome.extension.options.getTab("My tab").getValue("Say something after I say \"Hello\"") ? chrome.extension.options.getTab("My tab").getValue("Say something after \"Hello\"") : "Click OK to close..."));
}

Where getTab's first argument is the tab's name and getValue is the label chosen above. 

Need to be less 'workarrounded'. Need supports locale too. Then your example is inconsistent for the case.

@addydmasi: while david7...@gmail.com's comments may be valid, your general idea is along the lines of what I was thinking. This would allow:
 a. MUCH more consistant UI for options pages
 b. easier facilitation for extensions to back up/sync there settings across browsers (as the browser now know how to "read" the options and there values)

We once discussed this ages ago on one of the mailing lists, cant find it right now though. Either way, we concluded (or more appropriately they, as I only voiced my opinions twice or so) that a manifest option page would be too limited for more complicated options pages (e.g. take a look at the all mangas reader option page) or would require a lot of thinking on how to implement it. Personally I would suggest an xml approach would be far better. The structure would be fairly similar to html when it gets down to styling, but it would have to follow a basic structure which would be defined. Most importantly it would not allow e.g. style attributes. It would however be possible to dynamically through javascript add or remove input elements (e.g. to add or remove a list of server). And whatever would be the content of these input elements would always be saved and could be called upon by an JS API.  

@websiteb...@gmail.com: True, this would be too limited for advanced options. But for simple options it would make things MUCH easier. There would also be an option to use an html file for options, just as it works today. As far as styling: it would be trivial to specify classes/id's in the mainfest, you can also add a stylesheet making styling trivial. 
But that misses the point - the idea is to eliminate the needs for styling! Anyone that wants/needs styling can use the current build-your-own method.

@david7: totally agree!
@websiteb: I agree that it should be optionally.
In 99% cases simple options manifest will be sufficient - in others you may overwrite options page.
In this approach we can even integrate extension options with Browser Options page!

@qbawo...: I have already implemented just that for my own extensions, see for instance my video zoom extension:
https://chrome.google.com/webstore/detail/mpgjeecnfhippncndbojafcnpocpekcj/
Source code available here:
http://code.google.com/p/chrome-window-zoom-extension/

Options structure definition in json:
http://code.google.com/p/chrome-window-zoom-extension/source/browse/trunk/options_structure.json

Automatic rendering of options page based on this structure:
http://code.google.com/p/chrome-window-zoom-extension/source/browse/trunk/options/page.html

Forgot to mention these two:
http://code.google.com/p/chrome-window-zoom-extension/source/browse/trunk/background/load_options.js
http://code.google.com/p/chrome-window-zoom-extension/source/browse/trunk/background/save_options.js
The background page is the only page that does loading and saving of options; the extension script and options page ask the background page for the options or tell it to save them.

Ok, sure, thought it would work pretty well, as it would still be fairly simple in comparison to the current system. So lets thinking about the problems which we would need to solve with a json structure;
 - An array cant be the value, so something along the lines of
  "varName" : {
    description: "bla bla bla",
    defaultValue: "",
    type: "text"
  }
 would work far better, as it would then also be possible to have
  "varName" : {
    description: "bla bla bla",
    defaultValue: "",
    options: ["a","b","c"],
    type: "select/option"
  }
 - Labels in between
 "labelAAA" : {
   description: "bla bla desc",
  type: "label"
 }
  Problem with this approach is that every label would need to have a unique name...
 - You couldn't have subgroups as the ones you have on the current preferences page.
 - Should be possible to change descriptions dynamically... I think... or in some other way have dynamic values. 
 - Localization, not sure... easiest approach would be to be able to have properties like 
 description: {
  EN: "bla bla", 
  NL: "bla bla"
 }
 but I dont have a lot of experience in this field.

Just saw the new comment by skylined which also follows approximately a similar structure as I was thinking about now.

@skylined@chromium.org
it looks really great!
I think this should be available for all extensions - and still I have chrome://settings/extensions in my mind ;)

Oh and, I forgot to mention that no matter what will be created, a general css should definitely be available for the custom option pages. Possibly these could be even iframed into a chrome://settings/extensions page.

@websiteb...@gmail.com:
I like your i18n description approach, but shouldn't labels be stored in messages.json (like this http://code.google.com/chrome/extensions/i18n.html)?
The unique name of labels are necessary if we want store values in localStorage.
Another idea: when we have simplified options and storage maybe then we can sync extension's localStorage between browser's instances?

Here's an update to my original comment, with javascript events:

{
    /*...*/
    "options": {
        "javascript": "path/to/options.js" /*a JavaScript file for scripting events*/
        "my tab": [
            {"label": "my label","description": "example select box","type": "select","values": ["one","two","three"]},
            {"label": "another label","description": "a text box with JavaScript applied","type": "text","onkeydown": "myfunction" /*where myfunction is a javscript function*/}
        ]
    }
}

The strings that are shown to the user should be checked for i18n strings as usual. 
In options.js, javascript can be used to read the value, for example:

function myfunction(event){
 alert(event.target.value);
}

@qbawo...@gmail.com:  Yeah, you're probably right about the incorrectness of the localization implementation, as I mentioned I dont have a lot of experience in this field (most of my apps are unlocalized) and for the only app which did have localization I had to create my own version due to all the libraries being to limited for my dynamic approach, so you might be right about that.
 As far as localStorage... labels shouldn't be stored there as far as I know.
 And yeah mbre...@gmail.com was also already mentioning the options of syncing.

 @addydmasi; Wait, with your suggestion, would labels be what I would call variablenames? Aside of that, the idea of having functions is interesting, especially for custom validation, but preventing the javascript from having too much access would be hard (I think). Or wouldn't it have any DOM access... :S? That would do the trick probably.

@websiteb...@gmail.com
1. Not sure exactly what you mean, but I assume you mean giving the label an id so it can be edited via the DOM. I think an extra (optional) "label_id": "mylabel" should be added to the required object for this. 
2. I think DOM access should be granted unlimited access to anything dynamically generated in the script, plus limited access to only elements on the current tab (removeNode, for example, wouldn't be allowed), e.g.:

function mymouseover(event){
 try{document.getElementById("someTextboxOnAnotherTab").value = "this will throw an error";}catch(error){}
 event.target.value = "This will always work"; //sets the value of the input the event was executed on
 var inputs = document.querySelectorAll("input"); //will return input elements only on the current tab
}

Probably the easiest way to disallow DOM access to everything but the current tab would be to set the DOM functions to call, e.g., document.getElementById("whateverTheTabIdIs").getElementById("myinput") when the user runs document.getElementById("myinput"). 

@addydmasi:

I would like to add an id property to each setting:
{
  "id": "mySetting",
  "label": "my label",
  "description": "example select box",
  "type": "select",
  "values": ["one","two","three"]
},

And reference it as:
chrome.extensions.settings.mySetting.value

And I wouldn't use the function you propose but do something like: 
chrome.extensions.settings.mySetting.addListener('change', onchange);
And use this event to validate the setting or update something in the extension.

Also I think it is a good idea to define the settings in a separate json file so the extension manifest doesn't get cluttered

@addydmasi: 1. I was referring to the implementation of the variable access, e.g.
 chrome.extension.options.getTab("My tab").getValue("Alert \"Hello\" on startup")
 Where the "Alert \"Hello\" on startup" would be the variable name. And thats why I was asking whether the label name would be the variable name. 
 2. The danger of this would be of course that I can imagine users running havoc quite quickly, though it could work fairly well and would fairly complicated tabs. So overall I think it would be a really good thing you are proposing.

@potoms...:
It is better to store options as array or object?
{
 "options1": {
    "label": "My label"
 }
}
or:
[
 {
    "id": "options1,
    "label": "My label"
 }
]
in second approach we have order of options under control...

I agree that options options.json is good idea, but in manifest file we should can make a decision: define options in manifest file or put a string with options file name

@qbawo...@gmail.com
I think using arrays would be better because stuff like labels wouldn't normally need an id, and also so it is always in the order they are in inside the JSON file. 

You also might want to thing about grouping of settings, separated by horizontal lines or behind a popup. Similar to what is present in the tabbed settings today.

@qbawo...@gmail.com: Personally I think 
 {
 "options1": {
    "label": "My label"
 }
}
would be better, as it is *a lot* easier to have an overview. The disadvantage is of course that you should lose the order according to the specification, but I dont think that anybody would kill you for using the order as described in the object. 

Secondly I think it shouldn't be directly inside the manifest, as it can become quite lengthy.

@potoms...@gmail.com
We could just use {"type":"hr"} for that:

{
    /*...*/
    "options": {
        "title": "example",
        [
            /*...*/,
            {"type":"hr"},
            /*...*/
        ]
    }
}

@potoms....@gmail.com: Yeah, thats what type:label would be for in the implementation I was suggesting. You could then have a type:label with description:"<hr>", or even simply have type:seperator which would be even easier/better. The tabbed approach should also give enough grouping options to not need the popups. Reminds me, which HTML would be allowed in the descriptions? I would go for strong, i, bold, hr, maybe tables and that would probably be it. And another thing, it should also be possible to have buttons to link to other parts of the extension (e.g. type:button). Though this could alternatively be handled by the javascript implementation.

Gentlemen, though I appreciate the effort you are showing, this is not the right location to have a design discussion :). If you are serious about designing something, might I suggest you start a Google Code project and take the discussion there? Please cc me.

I'd just like to throw this out into the mix, to see what kind of response I'd get.

Suppose Chromium provided JS and CSS files for a developer's options page. The CSS would add default, customizable styling for an options page, and the JS would handle other styling and events, as well as a option-syncing API. For example,

<div class="-cr-tab"> creates a div that the JS and CSS recognize, and format as a tab. Then individual options could be styled as <input id="foo" class="-cr-textvalue">bar</input>, and then, similar to localStorage, the extension could use something like syncStorage.foo, which returns 'bar'. All of the syncing would be handled by Chromium's default JS file. A class like '-cr-nosync' could be applied to indicate that an element should be styled, but not synchronized.

It sounds simple to me. Developer choice is king, and nothing is synced or styled unless the developer wants it to be.

Now that DOMUI is Stable, could this issue be addressed by adding a section for Extensions to Options?  Searchable Extension settings would naturally follow from that.

Does this relate to  issue 52447  at all?  Perhaps as a dependency?

(No comment was entered for this change.)

Hey guys! I just finished my project called "Fancy Settings".
It does exactly what you all want! Create settings from a manifest!

It has tabs, groups, search, and looks similar to Chrome's HTML settings.
You can create many types of settings, e.g. text, popupButton, radioButtons, button, etc.

It's of course open source and well documented, and you can get it here:
https://github.com/frankkohlhepp/fancy-settings

This is perfect.

Awesome, Thanks.

@frnkkpp thank you that is really useful! You even added grouping/tabbing.

@frnkkpp: Awesome work, wow :) Are you planning to add a color chooser?