[Uim] Focus and cursor position shift handlings (bug #7729)

[YAMAMOTO Kengo / YamaKen]

Hi Etsushi,

At Wed, 22 Nov 2006 04:07:48 +0900,
ek.kato at gmail.com wrote:
> 
> On 11/20/06, Etsushi Kato <ek.kato at gmail.com> wrote:
> > However, again, I don't think emitting "move_cursor" is suitable in
> > this case.  If we use "move_cursor" for GtkEntry/GtkTextView to notify
> > button_press in toolbuttons, it will break your model about
> > distinguishing focus-in/out and place/displace.  "move_cusor" handlers
> > in GtkEntry/GtkTextView are off course used for real cursor move by
> > keyboard, and this should use place/displace model.  Or you intended
> > that call fix_im_context_weakly() only if count of "move_cursor" is 0,
> > and call displace_im_context() and place_im_context() when count != 0?
> >  This seems to be a pretty dirty hack for me.
> 
> How about "interrupt-im-context" signal,
> gtk_entry_interrupt_im_context(), and
> gtk_text_view_interrupt_im_context()?
> 
> > And as noted above, to revise im reset code in
> > gtkentry.c/gtktextview.c, it requires preedit displace/place handlers
> > in GtkIMContext.  Do you intended that this also shouldn't be touched
> > at the moment?

It seems that I had failed to explain my two-phase patching
scheme for GTK+. Sorry for my unclear and implicit
meanings. Please read the plan described below.


As I said and you agreed with before as follows, we should not
revise GTK+ API for now.

At Mon, 6 Nov 2006 23:34:25 +0900,
ek.kato at gmail.com wrote:
> 
> > At Sun, 15 Oct 2006 11:35:18 +0900,
> > yamaken at bp.iij4u.or.jp wrote:
> > > 4. Scenario #4 and #5 requires appropriate support of the GUI
> > >    tookit. But since I am not confident with the 'place' and
> > >    'displace' API about the note 5. (see below), API revision
> > >    suggestion for GUI toolkits should be deferred for now.
> >
> > Oops, what I intended was scenario #5 and #6.
> 
> Hehe, I understand the meaning of 'API revision suggestion' now :)

My principle on this issue is that "Since an API change costs
many outsider people unwanted tasks, it requires a reasonable
value as an exchange". And since the values of place/displace
model introduction are only "proper way" itself and resolving
some Japanese-specific minor problems, it is not reasonable if
we are not confident with the model yet.

In contrast with it, resolving the Korean input method problem
is obviously valuable, and in addition to the value, it requires
only a little workaround hack without API changes although it is
not so clean.

So I supposed this two-phase patching plan of GTK+, and always
told you based on it (such as the "A first-phase patch for GTK+"
phrase of the recent "What's going on" message). Sorry, that was
unclear for you.

 phase | patch type      | API/ABI | resolves  | involves
-------+-----------------+---------+-----------+-------------------------------
 1     | workaround hack | kept    | kr,cn,etc | GTK+ developers
 2     | proper solution | broken  | ja        | GTK+, each IMs and distros

The phase 1 is supposed to take few months, and it resolves the
Korean IM problem by replacing reset() with
fix_im_context_weakly(). Since this method uses preexisting
focus-out/in interface to notice the contexts to be fixed,
nothing is needed to follow this change by each IMs. This also
resolves the corrupted reset() use of GTK+ which assumes that
all input contexts are ephemeral. It is beneficial for Japanese
IMs too and sufficient for now.

And the phase 2 introduces place/displace model to the immodule
API. But as I described above, this change considerably costs
outsider people unwanted tasks/discussions. So we should
actually prove its properness and effectiveness before suggest a
patch to GTK+ project. I suppose maintaining our own modified
and experimental version of GTK+ for the phase. And since it
breaks current immodule API, this development is an opportunity
to revise all complaints about the immodule API. In other words,
we should write a candidate of next-generation immodule API
rather than a 'patch'. There are a lot of issues we want to
revise. For example, key filtering, commit/update interfaces,
text acquisitions, field-specified input mode hints, mouse
events, string injection and so on other than the place/displace
interface. I think that such experiences based on an actual code
will endorse its properness and increase persuasiveness.

But since it obviously be a heavy work, I suppose that the phase
2 will be a fun-based long-term development. i.e. It is not
required for now. We should develop it only when it is felt as a
fun.

I'll read your patch later. But please let me know your opinion
about the development scheme before discussing the actual
implementations again.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick