[immodule-qt] Re: Question about deletion of the method ofQInputContext

[Daisuke Kameda]

Lars Knoll <lars at trolltech.com> wrote:

> > > And I really curious about that.
> > > Kameda san, let me know how japanese input text usually, and why that
> > > feature is needed.
> > > I don't still understand why :)
> >
> > I don't understand why that is needed either. To the contrary, I find
> > it very annoying when a preedit string is preserved on focus change
> > and an old preedit string is recovered if the widget regains focus.

There is the style which compose a long text, in Japanese input style. 
There are some persons, who compose preedit included about 100 characters, 
change these afterward and commit. This is never a unusual example. 

And, in desktop, there is a case where other applications take a focus. 
In this case, they will be compulsorily committed, while composing the text.

We the Japanese want to often look a word up in a dictionary application at 
the time inputting text. In this case, they are forced to discard the paragraph 
of preliminarily composed text in the input context, or complete it without 
looking the obscure words up in the dictionary.

Therefore, it is very valuable for a Japanese that preedit is preserved.
But, probably, "old preedit string is recovered if the widget regains focus" 
is enough. 


On the other hand, about preedit relocation, I think that it is unnecessary. 
If much form is in one Webpage and I input into one of them by mistake, it is 
convenient for me to enable to move preedit under compose only by moving focus. 
However, I have a feeling that this is not a general example. 


> I thought so as well up to now, as this is the way it works on Windows. I 
> don't have any problem implementing either way, but I would really like to 
> have an answer here at some point. Committing the string on focus change 
> would make the IM handling a lot easier, especially in the text widgets 
> themselves. 
> 
> IMO implementing string reconversion correctly would be the better way of 
> dealing with it.

In order to realize this function only by implementing of input method, 
it is necessary to manage the string of preedit for every widget. 

And if reset() is performed, a string of length zero is committed, after the 
meaning by which reset() was performed is analyzed. What is more, when the 
widget regain focus, it is necessary to display the string of reserved 
preedit string.

I think that the function can be implemented somewhat easily,
if isPreeditPreservationEnabled() exists.

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