Confirm
45
edits
Changes
→Proposed Manifest of a 3rd-Party IME
11 "launch_path": "/index.html#en",
12 "description": "English layout",
13 "typetypes": ["url", "number"]
14 },
15 "English (Dvorak)": {
16 "launch_path": "/index.html#en-Dvorak",
17 "description": "Dvorak layout",
18 "typetypes": ["text", "url", "number"]
19 },
20 "Spanish": {
21 "launch_path": "/index.html#es",
22 "description": "Spanish layout",
23 "typetypes": ["text", "number"]
24 },
25 "number": {
26 "launch_path": "/index.html#numberLayout",
27 "description": "Number layout",
28 "typetypes": ["number"]
29 }
30 }
=== Layout Matching Algorithm ===
When an input field is focused, if it is not an "option", its <code>type</code> attribute will be used to filter a set of candidate layouts (if the input field doesn't provide a <code>type</code> attribute, we will use the default type, which is "text".) A candidate layout means it can handle this input type or is possible to let user input all characters that this input field accepted.
For example, if the type of a input is "url", then a layout with "url" or "text" listing on the "<code>types" </code> on its manifest will be matched. However, if a input field with type "text", then all layouts support "text" will be matched, but those layouts only support "url" are not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. A input type fallback plan is pre-defined as follows:
* "text" is the fallback of "text", "textarea", "url", "email", "password" and "search".
* "number" is the fallback of "number", and "tel"
The matching algorithm of keyboard manager in System app is as following:
