[Mim-devel] Questions about input framework in hildon

[Mu Yang]

你们好!

After reading your e-mail carefully, I think I can give you the answers here:

There is a virtual keyboard and in "full screen" mode (first IM framework) . It's always in landscape mode. It's disabled by default but you can enable it via "Settings" app. 

N900只支持landscape模式 (横放竖放都一样). 只有当电话程序(phone application)被激活的时候, 模式自动变成portrait. 当当前程序不是电话程序时,模式自动转为landscape模式. 如果硬键盘滑出, 任何状态下(包括电话)都是landscape模式.

所以我觉得可以不考虑虚键盘.当用户输入拼音时,只需弹出备选字窗口.

Br,
杨牧

不知我对问题理解是否准确? 如果不是, 请指出. 如果我回答不了,我会去问专家.

> 1. Please provide some info about how the hildon im framework works.
> Any document or web links are appreciated.
> 
> Generally there are two kinds of IM framework in mobile system. In the
> first one, the frame work interact with system-defined text field.
> When a im plug-in is active and a key event is received. The framework
> intercept the event, tell the underlying app an input is triggered.
> Then the underlying app loses its focus. The framework call the plugin
> function to pop up a full screen input window (in most case, although
> sometime a smaller window is allowed but not recommended), fill in it
> with the text  extracted from the current active text field of
> underlying app and set the focus and the cursor. When the input
> finishes, the plugin sends all text back to framework and destroy
> itself. The framework fill the text back to the text filed control and
> the underlying app regain the focus. The standard FEP framework on
> PalmOS adopts this way. I have also checked this page:
> http://live.gnome.org/Hildon/HildonInputMethod. It seems that hildon
> im framework is also designed in this way. But I am not sure if it
> remains so in maemo 5.
> 
我用我的n900验证了, maemo5的虚键盘仍是这种方式.

> Another type of IM design is a bit more complicated but also more user
> friendly. Windows Mobile, iPhone OS and Android 1.5 designed their IM
> framework in this way. When an im plug-in is active and a key event is
> triggered, the framework intercept the event and trigger the plugin to
> seperate the screen into two rectangle areas. Usually the IM occupies
> the lower one, but the underlying app still draw its window in the
> upper one. It should be noted that the underlying apps must be
> explicitly notified that the screen is separated. And it must
> accustoms itself to the shrinked window area, moving the textfield as
> well as the input cursor to appropriate position to make sure they are
> displayed correctly (rather than being shadowed by im plugin window).
> In this case, the plugin does NOT maintain its own text field, it just
> processes the key event sequence and send the result to the underlying
> app. After the input finishes, user explicitly remove the input window
> out of screen. This message is also sent to the underlying app. It
> will regain the whole screen area and of course, it will redraw its
> window to fit in the whole screen. In this way, an user friendly
> on-screen keyboard is much easier to be implemented. And the device
> probably has a built-in one for user to input text and symbols.
> 
> So, please clarify the IM framework on Maemo 5 (N900) works in which
> way? And does it work in both portrait and landscape mode?
> 
> 2. How the system deal with the portrait and landscape mode change?
> Does all UI programs work flawlessly in both mode? Or they can simply
> refuse to respond to a system notification and remains in its
> preferred mode?
> 3. Is there a way for im plugin to know the display mode of the
> underlying app? and how?
> 4. Is screen mode change defined as a system-level event and would be
> broadcasted to all UI apps, or individual app defines the behavior in
> its own way?
> 
> Considering this case. When an im plugin is active in either exclusive
> way or collaborative way as mentioned above, it has it's own window. A
> system notification of screen mode change is coming before an input
> finishes. What will happen and what should the plug-in do? Is there
> any criteria defined by the IM framework to follow for both apps and
> plugins? Could the plugin know that whether the underlying app will
> change it's screen mode or not? If the underlying app decides to
> change its screen mode, how does the im plugin collaborate with it to
> make sure both program fulfil the screen mode change correctly and
> resuming the input? The procedure seems to be something insanely
> complicated.
> 
> 5. Is there a built-in virtual keyboard in Maemo 5? in both portrait
> and landscape mode?

 

--------------------------------------------------------------
Ovi Store: Get free stuff for your mobile phone
http://store.ovi.com/?cid=ovistore-fw-bac-na-acq-na-ovimail-g0-na-1