[Uim] Determine the semantic of reset

[James Su]

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.

Regards
James Su

TOKUNAGA Hiroyuki wrote:
>On Thu, 02 Jun 2005 20:52:02 +0900
>Kenichi Handa <handa at m17n.org> wrote:
>
>  
>>>To allow such behavior, I couldn't think of any idea except adding
>>>new 'committable-when-focus-move-only' property.
>>>      
>>The committable property is a piece of reasonable
>>information an im-module can determine and attach, but
>>'committable-when-focus-move-only' is not.
>>
>>If we really need different behaviour on focus-move and
>>focus-out, different APIs are necessary for an im-engine as
>>you wrote, and a user should be able to customize each
>>behaviour as below:
>>
>>  o commit only the committable text (default)
>>  o commit nothing
>>  o commit all of the predit text
>>
>>So, still an im-module must give the committable property
>>(or the equivalent information) to an im-engine because such
>>information can't be decided by an im-engine.
>>    
>
>I have another question now. If I remembered correctly (Sorry, I don't
>investigate APIs), we can't edit preedit strings from application side
>in m17n-lib. So must we add a new API for teaching 'comittable text was
>comitted' to im-module?
>
>Anyway, in the case of uim, commitable property is difficult to adopt,
>I think. But if m17n-lib adopt commitable property, I approve.
>Because corresponding such property would not be so difficult for
>uim-m17nlib.
>
>
>Regards,
>
>