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