Confirm
478
edits
Changes
→Proposed Manifest of a 3rd-Party IME
== Proposed Manifest of a 3rd-Party IME ==
Just like any other apps, keyboard apps register themselves in the same apps registry. We extend the manifest syntax here to describe layout(s) available in a given keyboard app. Gaia will be paring the manifest. There are 3 special fields to distinguish and describe a 3rd-party IME:
* [Line 4] a "role" field with value "keyboard" declares it's an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})
* [Line 6-8] a "permissions" field that requests "keyboard" permission. All IME apps need this permission for sending input keys and updating the value of a input field.
* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])
** The allowed value in "types" field is a subset of [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type input type attributeof input element]: 1 text 2 , search 3 , tel 4 , number 5 , url 6 , email. Other types will be ignored by FxOS Gaia in the initial version because at this point UI for <select> and <input type=date> (called "value selectors") are not open for 3rd-party implementation.
=== IME App Manifest Example ===
=== Layout Matching Algorithm ===
When an input field is focused, if its <code>type</code> attribute is one of the allowed value values stated above, the <code>type</code> it 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 can accept.
For example, if the type of a input is "url", then a layout with "url" or "text" listed in the <code>types</code> of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. An input type fallback plan is pre-defined as follows:
* "text" is the fallback of "text", "textarea", "url", "email", "password" , "search", and "searchcontenteditable".
* "number" is the fallback of "number" and "tel".
The matching algorithm of keyboard manager in System app is as follows:
# Get focused input With the given type, find all layouts claims to support the said typeand put it into the list.# Get Next, if fallback input exists for a given type# Find out all , find layouts that claims to support either focused input type or the fallback input typeand put it into the list. Layouts do not get duplicated listing even if it supports both types.After step 3, keyboard manager will sort # Present the user with the choice of the list and display layouts available to handle the first matched layoutinput field. The sorting criteria order of presenting list is defined by depend on UX design and/or user preferences in Settings.
== Proposed API ==
