Etsushi Kato wrote:
> Hmm... It it known that --async option has a side effect (and
> also SCIM's x11 has) in inputting characters into Tck/Tk
> widget.
This is true, unfortunately; I installed tkpaint and no input was
possible. In fact X froze. I had to go to the console to kill
tkpaint. Tcl/tk version is 8.4.12. Without --async, tkpaint works.
> And I think our default behavior (not using --async) is
> suitable for old applications like xfig and tgif.
xfig works 'more or less all right' with xfig -international both
with and without --async. It never works really well, of course;
this old program has no idea of UTF-8, ttf fonts, etc.
> [..] Yes, I can reproduce it. But the bug is very difficult to
> describe and solve. [..] This is why we recommend to abandon
> XIM.
>>> By the way, you seem to like using XIM instead of gtk+
>>> immodule because of the compose sequences in X11.
>> Two reasons:
>> 1 - the compose sequences. [..]
>> 2 - xim always works. [..]
> I see. For 1, I've implemented X11's equivalent compose
> mechanism in uim-xim, so it should work as if it doesn't exist
> :).
Yes; uim-xim apparently uses the actual X compose mechanism (if
that is the right term), including the user's ~/.XCompose file. It
seems SCIM has it own internal version of the Compose file. So
with SCIM, the user's customisations do not work (for instance
things I like to have, such as Compose .- -> …, Compose /\ -> ∧,
Compose \/ -> ∨). But they work with uim.
Mozilla and Thunderbird (and other GTK programs) seem to have
their own 'internal' compose table, which is much smaller than the
X Compose table. Some compose sequences work (like Compose ss ->
ß), but more unusual ones do not (like Compose Uu -> ŭ, which is
an easy test case). This is if you use GTK_IM_MODULE=uim. With
GTK_IM_MODULE=xim, Mozilla handles all Compose sequences.
Unfortunately Mozilla & Co (unlike 'normal' GTK programs like
Bluefish) do not offer an easy way to change between the xim and
uim input methods.
> Also I as noted in previous mail, please test uim's Latin IM
> with uim immodule [..]
The 'Latin' IM can indeed do some things which Mozilla cannot do
by itself, like ŭ. But it still does not offer all the
possibilities of the full X Compose file; only Latin combinations,
e.g. no accented Greek letters (such as these nice things with
three accents, like ᾇ). IMHO it would be a waste to duplicate them
in uim, because they are already a standard feature in X. If you
ask me, the 'Latin' IM can be removed completely.
> For 2, That's true. [..] So, just set GTK_IM_MODULE=uim and
> QT_IM_MODULE=uim environmental variable. And for the rest of
> traditional applications, just run uim-xim at startup of X and
> set [EMAIL PROTECTED] With this setting, you can use uim
> everywhere. It not so complex.
Yes, this is completely true, thanks. Ι had to install uim-qt (not
default in Debian), but then I could indeed use uim 'everywhere',
also with GTK_IM_MODULE=uim and QT_IM_MODULE=uim. But then I had
the problem with Compose in Mozilla.
So now we have three choices:
xim -> may crash Mozilla and X when used in URL field
(because of the automatic 'history' drop-down
box?).
xim --async -> crashes Tcl/tk apps with input fields (until
version 8.4.14?).
uim -> no complete compose mechanism in Mozilla (not even
with uim/Latin). I think this is pretty serious
because many people use Mozilla/Thunderbird as
mail clients. Mail is often very international..
The easiest, apparently, is to wait for Tcl 8.4.14. But for a
fundamental solution, I would say that xim handling in Mozilla
(or libX11?) should be fixed. Something that works across the
whole system is always to be preferred. That way, users do not get
surprises. This is just a non-programmer's opinion of course..
Regards, Jan
http://www.jw-stumpel.nl/stestu.html
