[immodule-qt] Current Qt 4 status

[Daisuke Kameda]

Hi Lars.

Thank you for this report.

Lars Knoll <lars at trolltech.com> wrote:

> IMO it is more important to make things easy for the people implementing IM 
> enabled widgets than for the people writing input methods. The reason is that 
> most people that would like to add IM support to their widgets often don't 
> know all the details of how input methods work.

I agree with this opinion.


> /*!
>   \fn void QWidget::setInputContext( const QString& identifierName )
> 
>   This function sets an input context specified by \a
>   identifierName on this widget.
> 
>   \sa inputContext()
> */

I can't understand usage of QWidget::setInputContext().
Please teach us how to use this method concretely.

For example, when some inputs widget share one input context, 
how should the developer set?


> /*!
>   \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 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.

I think that this idea is excellent. Probably, it will be possible to 
deal with the demand to input method which will increase from now on.

For example, it will be able to change again the selected text by input method.



> 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.

I agree with this solution.

> For that reason I'd be very interested in hearing what kind of data we would 
> have to transmit in the event.

If the ruby can be sent, I think that it is better. 


> In QApplication I'd like to see
> 
> /*!
>   \fn void QApplication::setInputContext(const QString &);
> 
>   Sets the application wide input context.
> */

Please also teach us how to use this method concretely.



> 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.

O.K. If there is flexibility about the set of input context, 
I will approve of this proposal.

> 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.

I think that everything but XIM does not become complicated,
since the processing which uses widget internally probably doesn't depend on 
per application or per top level widget.


-- 
Daisuke Kameda <kaminmat at cc.rim.or.jp>