1074653 - (keyboard-render-refactor) [meta] Rearchitect IMERender, LayoutRenderingManager, AlternativesCharMenuView & Manager

Status: RESOLVED WONTFIX

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

Description

[John Lu [:mnjul][Please NI or I'll miss]]

As we were doing bug 1044525 it began to be apparent that we could re-architect IMERender, LayoutRenderingManager, AlternativesCharMenuView, and AlternativesCharMenuManager (and possibly some other modules if needed).

We're currently observing these issues or smelly codes, at least:

1. IMERender is globally referenceable and everyone is free to poke it around. It probably should be known to LayoutRenderingManager only, and anything talking to the view should explicitly go to LayoutRenderingManager (also, does this mean that moving the management of the AlternativesCharMenu instance to the rendering manager is reasonable and/or architecturally sound?)

2. Following 1., what is the best way we expose the forward DOMElem-to-KeyObj and reverse KeyObj-to-DOMElem maps? (and other views such as AltsCharMenuView?)

3. We have a few inner (yet long) functions in IMERender, and the IMERender itself is quite huge. We should dissect it. Also, CandidatePanelManager pokes into IMERender heavily -- we probably want a CandidatePanelView if extracting that from IMERender reasonably allows responsibility separation.

4. Following 3., we're also generating business logic objects directly in IMERender, such as [1]. Coincidentally, those objects are all related to CandidatePanel... so there could be some interplay with separating CandidatePanel logics out.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/keyboard/js/render.js#L421

Comment 1

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

John, thanks for filing this bug.
I'd like to start keyboard rendering refactoring with this as a meta bug.

Comment 2

[howie [:howie]]

This is the preparation work for Emoji bug 993888, 2.2+

Comment 3

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

IMERender expose a method, setInputMethodName(), which for the client code to add 'latin' as a className to the candidate panel. 
I think we should normalize this into a general case, e.g. define a candidatePanel section in each layout definition file, and specify the className there.
===
candidatePanel: {
  className: 'latin'
}

Comment 4

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

Mass-unassign feature-b2g: 2.2+ to re-scope 2.2 features.

Comment 5

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

Marking 2.2 features for 3.0 considerations.

Comment 6

[BMO Automation]

Firefox OS is not being worked on