[immodule-qt] Current Qt 4 status

[Lars Knoll]

Hi,

I've been doing quite some work and would like to present the current status 
of IM support for Qt 4 to you. I might repeat some of the things I already 
wrote in some other mails.

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

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.

In QWidget we have:

/*!
   \fn QInputContext *QWidget::inputContext()

    This function returns the QInputContext for this widget. By
    default the input context is inherited from the widgets
    parent. For toplevels it is inherited from QApplication.

    You can override this and set a special input context for this
    widget by using the setInputContext() method.

    \sa setInputContext()
*/

/*!
  \fn void QWidget::setInputContext( const QString& identifierName )

  This function sets an input context specified by \a
  identifierName on this widget.

  \sa inputContext()
*/

/*!
  \fn virtual void QWidget::inputMethodEvent(QInputMethodEvent *e)

    This event handler, for event \a e, can be reimplemented in a
    subclass to receive Input Method composition events. This handler
    is called when the state of the input method changes.

    The default implementation calls e->ignore(), which rejects the
    Input Method event. See the \l QInputMethodEvent documentation for more
    details.

    \sa event(), QInputMethodEvent
*/

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

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.

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 have not changed the QInputContext class a lot until now, as I'd like to 
discuss this as we go along.

Cheers,
Lars