[Mim-devel] Questions about input framework in hildon

[UGlee]

Dear Yang:

We are considering the UI feature of MiM, especially it's interaction
with the user. Here is a quesition list:

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.

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?

Looking forward to your kindly reply.

Tianfu Ma (UGlee)