[immodule-qt] Current Qt 4 status

[YamaKen]

I resend this mail to immodule-qt at freedesktop.org because it had
not been delivered until now. Ignore this mail if you had
already been received.

From: YamaKen <yamaken at bp.iij4u.or.jp>
To: Lars Knoll <lars at trolltech.com>
Cc: immodule-qt at freedesktop.org, Daisuke Kameda <kaminmat at cc.rim.or.jp>, Kazuki Ohta <mover at hct.zaq.ne.jp>, LiuCougar <liucougar at gmail.com>
Subject: Re: [immodule-qt] Current Qt 4 status
Date: Tue, 16 Nov 2004 20:54:41 +0900
Message-ID: <85wtwmypod.wl%yamaken at bp.iij4u.or.jp>

Hi Lars, thank you for the cooperation.

# this mail is Cc:'ed to committers because the list server is down

At Fri, 12 Nov 2004 10:40:23 +0100,
lars at trolltech.com wrote:
> First I'd like to give you an overview over the API as I see it now. I have 
> modified quite some things. My main objective is to make the API as easy to 
> use as possible (both for the people implementing input methods and the 
> people writing IM enabled widgets). 

> /*!
>   \fn virtual QVariant QWidget::inputMethodQuery(Qt::InputMethodQuery query) 
> const
> 
>   This method is only relevant for input widgets. It is used by the
>   input method to query a set of properties of the widget to be able
>   to support complex input method operations as support for
>   surrounding text and reconversions.
> 
>   /sa Qt::ImQueryProperty QInputMethodEvent QInputContext
> */
> 
> The InputMethodQuery enum used above is defined in the Qt namespace as:
> 
>     enum InputMethodQuery {
>         ImMicroFocus,
>         ImFont,
>         ImCursorPosition,
>         ImSurroundingText,
>         ImCurrentSelection
>     };
> 
> We can freely extend this enum later in a binary compatible way if we should 
> find out that the input methods need to be able to query additional 
> properties of the input widget.

I love this design.

Please keep in mind inter-process passing of the query/result
between input context and widget on the client-server input
method model of Qt/Embedded.


> I have removed the setMicroFocusHint() method and instead rely on the input 
> method to query the information it needs using inputMethodQuery() as this 
> makes it a whole lot easier to implement IM enabled widgets.

It will cause a problem in some cases.

For example, some input methods may want to show its auxiliary
widget adjacent to cursor always regardless of existence of
preedit. In this case, the notification from the widget is
required to know cursor moving because no other trigger to
activate the input context will occur. And consider Qt/Embedded
which cannot access to the widget directly from the input
context. So the notification have to be implemented in the
immodule framework.

In addition, what input method developer needs ideally is
acquiring following information to place auxiliary toplevel
widgets appropriately. Please consider it.

- rect of cursor
- rect(s) of selection
- rect(s) of whole preedit
- rect(s) of specified substring of preedit

"rect(s)" means that the case preedit is rendered as multiple
lines of string (i.e. long preedit string with linebreak).


> I have unified QIMStart/Compose/EndEvent into one QInputMethodEvent. Currently 
> we still have the three types (Start, Compose and End), but I was told that 
> this structure is not always sufficient. We also need to add support for 
> deletion of surrounding text and reconversions to it. For that reason I'd be 
> very interested in hearing what kind of data we would have to transmit in the 
> event.

I know some characteristics of ordinary Japanese and Korean
input methods about what events are needed.

- Japanese
  * Compose (update preedit)
  * End (clear preedit and commit a string)

  Current implementation uses Start and End to handle preedit
  relocation mainly for japanese. But it may changed in
  accordance with your new design.

- Korean
  * Compose (update preedit)
  * Commit (commit a string but leave preedit untouched)

  Korean input methods use End-Start-Compose sequence in current
  implementation to emulate single Commit.

I want your new design of context allocation/sharing scheme
(described in next section of this mail) to think proper event
reorganization for Japanese.

And following features should be implemented in the
QInputMethodEvent. Please open the discussion about them once
the basic design of the framework has been fixed.

- rich text capability for preedit string (flexible visual
  modification of preedit)

- language tagging for proper distinguishment of unified han
  characters in CJK texts

- ruby capablity (which Daisuke mentioned). Do you know about
  ruby?


> In QApplication I'd like to see
> 
> /*!
>   \fn void QApplication::setInputContext(const QString &);
> 
>   Sets the application wide input context.
> */
> 
> /*!
>   \fn QInputContext QApplication::inputContext() const
> 
>   returns the application wide input context.
> */
> 
> I would like to get rid of having one input context per top level widget and 
> reduce this to one default context per application. The reason is that one 
> input context per top level doesn't solve any problem (we might have several 
> input widgets within one top level), and this makes the whole IM handling 
> work the same way as e.g. font and palette handling. You have one default for 
> the whole application and can override this for individual widgets.

It's insufficient for Japanese. One input context per top level
widget does make sense for Japanese input contexts.

Although your design is sufficient for almost languages that
deal with ephemeral input contexts, it's insufficient for some
languages that deal with persistent input contexts such as
Japanese. Input methods for such language has additional
requirements. See following scenarios to recognize it.

- scenario 1

  Suppose a multi-window text editor application. The user is
  writing valuable Japanese document in a window with deep
  thinking.

  Then he want to refer another Japanese text file in another
  window while he is composing. He has been finished the reading
  of the text, but he has found a wrong Japanese expression in
  the text and want to modify it.

  Japanese input context often contains a paragraph of text made
  by minutes of thinking and hundreds of keystrokes. The text
  that is being composed by him is such case. He naturally want
  to keep first input context until he has been finished the
  editing of the another text file with another input context.

- scenario 2

  Suppose a tabbed web browser. The user is writing a blog entry
  in Japanese in a tab.

  Then he want to look an obscure Japanese word up by a
  dictionary site in another tab. As similar to scenario 1, he
  naturally want to keep the input context containing a
  paragraph of text in blog tab until he has been finished the
  word lookup which requires another input context to input the
  Japanese word.

The requirements and facts extracted from above scenarios are:

  - The input method requires simultaneous existence of input
    contexts that are shared in appropriate unit

  - Assuming top level widget as the context sharing unit is
    usually better than sharing one context in whole application

  - Top level widget is not always appropriate as the context
    sharing unit, so some mechanism to redefine the sharing
    scheme is required

Your default context allocation and sharing scheme has the
problem that breaks the requirements.

In addition, you know the another feature 'preedit relocation'
relevant to above requirements. But the feature is insufficient
if used without simultaneous existence of input contexts
required as above.

Although your intention about setInputContext() seems only for
widget-local input method overriding (i.e. input method
switching on the widget by context menu), the setInputContext()
itself does not have problem. The default context allocation and
sharing scheme has the problem. Please redesign it with above
requirements.

Since any plugin writer knows whether the type of context is
ephemeral or persistent, QInputContext or the plugin could
indicate the information as a hint for appropriate context
management. The hint may help you to keep the design clean.


> This places some more burden on the people implementing input contexts, as one 
> QInputContext object has to be able to deal with several widgets. However I 
> think this is not unsolvable. For XIM I do for example plan to hold several 
> XIM input contexts internally in the QXIMInputContext class to achieve this.

It's not so heavy, at least for non-XIM input contexts.

If the type of context is ephemeral, proper reset handling on
focus in/out is sufficient for context sharing. The developer is
not required to know the context is shared by multiple input
widgets in the case. See my default implementation in
QInputContext.

On the other hand, if the type of context is persistent, some
input method framework such as uim provides appropriate context
handling facility. The developer is also not required to know
the context is shared by multiple input widgets in the case.


Let's continue the discussion.

Regards,
-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp