930371 - Use "inputs" instead of "entry_points" to expose multiple layouts/input methods in a keyboard (IME) app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

entry_points might fade out according to Fabrice, so we may use a custom property here for keyboard app, I would suggest "input_methods".

With this change, we need to look into keyboard_helper and what we store the enabled layouts in mozSettings, and the build time config about keyboard layouts. See the dependency bugs for details,


** For Triage **
Nominate this as koi+, since this is an important part of 3rd-party IME framework.

Comment 1

[Ivan Tsay (:ITsay)]

Rudy,

Plus it base on your commment. Please help to assign the target milestone for this one. Thank you!

Comment 2

[David Flanagan [:djf]]

A static list of layouts in the manifest file will never support runtime configurability of the keyboard, so we will need (in 1.3 or 1.4) to add something like DataStore support for listing keyboards.

And if we are going to do that, do we need to change from entry_points to input_methods now?  I don't know if there is or will be a way to create a build where the DataStore of hte keyboard is already initialized, so maybe we will need to continue to support the manifest-based solution for built-in layouts.  But if we can do all the layouts in a DataStore, I think that would be much better than using the manifest.

If we go ahead with this bug, I don't think that "input_methods" is the right name, especially since we imagine that most 3rd party apps will have a single input method, but may support multiple keyboard layouts.  Since this is a keyboard-specific feature that we are proposing, I think the property name should include "keyboard" in its name.  I'd suggest "keyboard_layouts" or just "keyboards".

Comment 3

[Corey Frang [:gnarf]]

+1 to "keyboards" or even "layouts" since it's already a type: keyboard app, "layouts" makes sense.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Rudy Lu [:rudyl] from comment #0)
> ** For Triage **
> Nominate this as koi+, since this is an important part of 3rd-party IME
> framework.

I don't understand why this bug should block...

Comment 5

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #4)
> (In reply to Rudy Lu [:rudyl] from comment #0)
> > ** For Triage **
> > Nominate this as koi+, since this is an important part of 3rd-party IME
> > framework.
> 
> I don't understand why this bug should block...

v1.2 is the first version we will ship 3rd-party IME framework, I just hope that we won't have 2 different properties for defining layouts (input methods) in a keyboard app.

I want to make this property "input_methods" because an app could have different input methods not just layouts in it, this term input method is different from what we used in the built-in keyboard app for latin engine. (https://github.com/mozilla-b2g/gaia/tree/master/apps/keyboard/js/imes/latin)

The main reason for this is that an app might include voice input or hand-writing, so it is not just about "layouts".

We should refine role=keyboard to role=input and we already have a bug for that, Bug 915570.

Comment 6

[Preeti Raghunath(:Preeti)]

3rd party keyboard issues will be fixed by the first week of Nov.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I have a question while attempt to work on this bug: I don't think we have a clear choice to replace entry_points to for now.

1) "layouts", "keyboards", "keyboad_layouts": we probably shouldn't call a voice input or handwriting input a "layout". It's to specific.
2) "input_methods": as djf previously mentioned, this term is not really understandable and for me, too vague to specifically state the abstraction we are talking about here.
3) Lastly, "entry_points" is not a good enough name to stay as-is -- because it's was intend to used in certified apps with multiple entry points, and each of these entry points contains a subset of the original manifest. We ask keyboard app ("input" apps now) to use "entry_points" to expose their "layouts" even if there is only one layout.

(noted that we have purged all mentions of "keyboard" permission and application role in bug 915570 and replaced it with "input")

I was going to propose "input_modes" but there is already an <input type="text" inputmode="..." /> ...

We should probably avoid any names with the work "keyboard" because of (1) above.

Other possible terms from Android documentation including View, Subtype; "subtype" is maybe the equivalent between AOSP and B2G, but that's really an ugly name -- it is unclear to me the "type" it is referring to.
https://developer.android.com/guide/topics/text/creating-input-method.html 

So, any suggestion?

Comment 8

[Corey Frang [:gnarf]]

"inputs": { "en": ..., "number": ... } ?

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am going to submit a patch that renames "entry_points" to "inputs".

Comment 10

[Yuan Xulei [:yxl] (Leave from May 18)]

I'd like the name "inputs" or "input_methods".

"Keyboards" cannot cover voice input or handwriting input as Tim mentioned. "layouts" is similar to "keyboards" and cannot cover voice input or handwriting input either. Also "layouts" is too general that we use it for all kinds of layouts other than keyboard layouts.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/timdream/gaia/tree/keyboard-entry-point

WIP. Will file for review after test passes and manual testing.

Comment 12

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

Attachment: mozilla-b2g:master PR#13418

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 827895 [details] [review]
mozilla-b2g:master PR#13418

I don't think I missed anything and I can rule out test failure are not result of this patch... so I am filing review for this one.

It's better to have more people to look at the patch, feel free to unset that if you don't want to look at the patch.

Comment 14

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 827895 [details] [review]
mozilla-b2g:master PR#13418

Looks good to me.
Thanks for patching this up.

Comment 15

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

Comment on attachment 827895 [details] [review]
mozilla-b2g:master PR#13418

looks good to me.
thanks.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 827895 [details] [review]
mozilla-b2g:master PR#13418

I am rebasing and landing this patch now.

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/1e9aba68e8e6556d40ae2c414e9404047ec26bb8

Comment 18

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 1e9aba68e8e6556d40ae2c414e9404047ec26bb8 to:
v1.2: e9fe1f60bd18cddbcee4baf4caea520254bfb355

Comment 19

[Axel Hecht [:Pike]]

This changed strings exposed to l10n, is that on purpose?

Notably, it regressed our ability to localize the Number keyboard string.

Comment 20

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Axel Hecht [:Pike] from comment #19)
> This changed strings exposed to l10n, is that on purpose?

No, I didn't realize that. Sorry. Do I need to do anything to fix this?

> Notably, it regressed our ability to localize the Number keyboard string.

Ouch....

Comment 21

[Axel Hecht [:Pike]]

Background: Any data that needs to be exposed to l10n needs to be in a place and format I know. If one's moving data from A to B, it's lost, unless the l10n ecosystem happens to support B as well.

inputs in manifest.webapp were not among the supported data locations, and now all updates to our trees for l10n are stuck.

I filed and dealt with this in bug 938112 to get l10n unstuck, and reran the latest migrations.

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Axel Hecht [:Pike] from comment #21)
> Background: Any data that needs to be exposed to l10n needs to be in a place
> and format I know. If one's moving data from A to B, it's lost, unless the
> l10n ecosystem happens to support B as well.
> 
> inputs in manifest.webapp were not among the supported data locations, and
> now all updates to our trees for l10n are stuck.
> 
> I filed and dealt with this in bug 938112 to get l10n unstuck, and reran the
> latest migrations.

Right, sorry about that.