[Uim] Determine the semantic of reset

[TOKUNAGA Hiroyuki]

Sorry for my late replying...

On Thu, 12 May 2005 08:40:38 +1000
Paul TBBle Hampson <Paul.Hampson at anu.edu.au> wrote:

> On Sun, May 08, 2005 at 06:34:51AM +0900, TOKUNAGA Hiroyuki wrote:
> > Park Jae-hyeon reported as follows:
> 
> >   If I click at a location within the text area of gedit, different
> > from the location of the preedit area, when a syllable (or
> > character) is under composition, then this preedit area jumps to
> > the point at which I clicked.  I found that the hangul2 input
> > method included in uim also shows this behavior.
> 
> > That is a known problem of uim, but I've left this problem in the
> > past. In this mail, I want to clear up our requirement and look for
> > the solution.
> 
> > In this mail, I'll explain in case of GTK+, but it would be
> > applicable in case of Qt (and good old XIM) too.
> 
> 
> > The Problem
> > ===========
> 
> > When a location within the text area was clicked, preedit strings
> > moves to the clicked point.
> 
> 
> > What's happening?
> > =================
> 
> > When a location within the text area was clicked, GTK+ calls 'reset'
> > function of focused IMContext. In the reset function, input method
> > can do anything. So, in this function, uim can commit preedit
> > string and erase preedit string. But, carrent implementation is
> > calling reset- handler of each input module, so the behavior
> > depends on each input module implementation.
> 
> 
> > In general, what we imagine with the word 'reset'
> > =================================================
> 
> > So, what we should do in reset function would be described as
> > follows,
> 
> >  1. commit current preedit string (if exist)
> >  2. then erase preedit
> >  3. return to initial input state
> 
> > But, I feel odd with the 1st item. Why we should commit in reset
> > function? For example, if we push the reset button of our family
> > computer (in proper English, Nintendo?), game will start from the
> > beginning.
> 
> Is this the only time GTK+ calls 'reset'? Because moving within a
> text string is very different from changing window focus, or clicking
> on buttons and other things. Or at least I think it is.

Though I'm not confident in, no. When focus is moved to other window,
Japanese tend to prefer preedit is still be there as 'pre'edit, but
Korean tend to prefer preedit is commited where cursor exists.
(Unfortunatelly I don't know preference of people in other countries...)

So some of Japense would say yes, some of Korean would say no.

> > I'm uncomfortable with the side effect. Reset function should change
> > only status in the InputContext, ourside of InputContext (such as
> > text widget) should not be changed with the reset function.
> 
> I guess it also matters how GTK+ deals with the text widget's text
> changing between click and action (during reset for example ^_^). If
> you end up on the text you clicked on, even if that text has shifted,
> then this can be seen to be expected behaviour. If you end up at the
> screen position you clicked, no matter what the text underneath, then
> you're correct about the semantics of Reset, and any disagreement I
> have is with the GTK+ developers, not uim's implementation.
> 
> > I want to leave the name 'reset' for 'real' reset feature. (i.e.
> > erase preedit and return to initial input state only.)
> 
> > So, if we want to commit before erase the preedit string, we should
> > provide appropriate name for the feature. But now I don't have good
> > idea.
> 
> > If you have a good name, or if you have an objection to my opinion,
> > please reply to this mail.
> 
> I think the name of the function is possibly less important than what
> the user expects. I think GTK+'s calling of "reset" is really only
> referring to the step 3 above, plus whatever else the IM wants to do.

No, as a developer, the name of the function is important enough ;-) (Of
course I agree with you that real behavior is more important!)

> As a user, I would expect the text in the pre-edit to be comitted at
> that point, else I would have hit 'esc' (or whatever the cancel key
> happens to be) before moving off the find the mouse.
> 
> ie. as far as I am concerned, the preedit area is a projected part of
> the text, not a piece of text waiting to be inserted. (Same way I
> expect that if I focus away from a window and focus back, the pre-
> edit will be sitting there still, neither comitted nor cleared.)
> 
> I don't know if this is the general feeling of users though. ^_^

As mentioned above, I think some people would prefer preedit-commit-
when-focus-out style, other won't. So it should be configurable.

To achieve this purpose, obviously we have to added API.

I propose that adding two handlers to uim's language module's interface.

 a. focus-in-handler
   This handler is called when focus is moved to the widget.

 b. focus-out-handler
   This handler is called when focus is moved from the widget.

 c. focus-move-handler
   This handler is called when focus is moved within the widget.


Problems:

 1. These handlers are enough for uim-fep?
 2. These handlers are OK when IM context is shared between plural test
    widgets?
 3. Semantic of focus-move-handler is unclear a bit.


Anyway, it wouldn't be included in the next release...


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp