[immodule-qt] Current Qt 4 status

[Lars Knoll]

Hi,

On Tuesday 23 November 2004 04:05, YamaKen wrote:
> 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.

Thanks :)

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

This is in the platform independent part of Qt, so it doesn't touch this 
problem directly. We'll have to find a solution here, but I'd first like to 
get a design that's as clean as possible outside of QInputContext.

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

I see the problem, and we'll add a notification method again.

> 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

Ok, we can easily add these to the imQuery method.

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

Do you really want relocation? 

We currently have XIM implemented in a way that QInputContext has one XIC per 
input widget. Like that you can keep a preedit string in every input widget 
even when you switch focus within one toplevel. At least to me this looks 
rather natural.

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

That means we need some way to commit only part of the preedit string?

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

It's currently only implemented for XIM. How about if I keep the event 
structure as it is for now? We'll have a Qt version with the code out in 
about a week from now, and we can then try to develop the event structure 
that is needed.

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

Possible, but that would only work in QTextEdit. QLineEdit has no rich text 
capabilites.

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

Would a QLocale object be enough?

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

I'm not sure what you mean here? You're not talking about the programming 
language are you?

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

The way we have implemented QXIMInputContext now is that it can handle several 
X input contexts at the same time (one per input widget). That solves both 
scenarios below.
>
> - 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

I think the main problem here is what we define QInputContext should be able 
to do. In you view it can only handle one input widget, as I see it it should 
be able to deal (at least for languages as japanese) with several input 
widgets at the same time.

What I am talking about is moving the complexity of handling several widgets 
into QInputContext. If you have one input context per application this one 
instance has full control over all input widgets and can do whatever is 
needed. 

Maybe the name QInputContext is then misleading, as it's not a context for a 
widget, but for several widgets (usually the whole application).

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

This brings me back to the question if the "relocation" is something you 
really want (I can't really imagine that) or if it is just a trick that you 
used because we were not able to have several input contexts per top level 
before.

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

If the default context can handle multiple input widgets, I don't really see a 
problem here. 

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

If you have one input context per application, we don't need to do anything in 
Qt as the input context can handle this itself. If the input context is 
ephemeral, it can send an IMEnd event to the old widget when focus changes. 
If it is persistent, it doesn't send an IMEnd event on focus change and when 
focus returns to the widget, it simply continues the composition.

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

That is the idea. Since the input context gets called on focus change it can 
to the right thing for both types of input methods.

Best regards,
Lars