[Uim] Determine the semantic of reset

[TOKUNAGA Hiroyuki]

On Mon, 06 Jun 2005 10:54:29 +0800
James Su <suzhe at tsinghua.org.cn> wrote:

> Hi,
>   I don't think introducing such complex behaviour for reset()
> semantic is worth and practical. Only the applications, which don't
> want to retain the preedit string for an input area when focusing
> out, will call reset (). Otherwise reset() shouldn't be called when
> focusing out (no matter focus move or focus out). So just implement
> the reset() as truely reset behaviour (clear preedit string and put
> input method into original state) should be good enough. The preedit
> string should only be committed within reset() if it's really
> necessary to be committed. Users should always let input method
> engine commit the preedit string or clear the preedit string before
> moving the focus. Otherwise the default behaviour implemented in
> input method's reset() method should be invoked if the appliation
> wants to clear the preedit string. For the applications which don't
> call reset() at all, input method should not commit the preedit
> string when focusing out and should re-display the preedit string
> when focusing in again. It's the user's responsibility to finish the
> input segment before moving the focus. So I think any additional
> property like committable-when-focus-out etc., are completely not
> necessary. reset () is enough.

Ok, let me split the problems.

At fisrt, semantics of reset is not complex, which remove preedit and
return to initial input state only. I think there is an agreement for
this.

Second, there is a request from user side, so 'just implement reset' is
not enough. The requist is especially important for uim because I am
the demander ;-)

Third, we need comittable property because all of preedit strings
should not be committed. For example, in uim-skk, there is a word-
learning mode, which shows auxiliary strings as a preedit. To be exact,
we need a way to know/get commitable strings at the point, committable
property is one way to solve. I think m17n-lib will adopt it, uim will
not adopt it (because it wil need high cost refactoring in the case of
uim.)

Hmm, maybe I couldn't split problems appropriately, but the most
important is third, "all of preedit strings should not be committed" is
the main reason of existence of committable propery. If you prove
'reset is enough', you have to prove the way to know 'currently
commitable strings' without this property or an equivalent feature.


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp