[Uim] Determine the semantic of reset

[Paul TBBle Hampson]

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.

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

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

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Anu.edu.au

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/uim/attachments/20050512/3c5e543d/attachment.pgp