Bug#377808: Re : uim can cause crash of X
On 7/18/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote: Etsushi Kato wrote: On 7/18/06, Etsushi Kato [EMAIL PROTECTED] wrote: I committed the changes for gtk+ and Qt immodule on freedesktop's svn repository while ago. Now you can use all compose sequences and ~/.XCompose with gtk+ (Mozilla, Firefox, Thunderbird, Gedit and so on) and Qt (Kate, ...) immodules of uim as well as XIM. Unless I am mistaken, in the present version (1.1.0) I can already input all Compose sequences in Qt programs (with the uim input method). Only in GTK programs and Mozilla do I have to use the xim input method with 1.1.0. Qt immodule patch has its own compose table internally based on X11's Compose file, but it doesn't support ~/.XCompose and changing Compose file depending on working locale. It is just a static table compiled with in the library. I think this change would make the Latin IM superfluous, doesn't it? Because all Latin (and also all other) accented letters will be available with all input methods when conversion is switched off (shift-space). Completely right. But it has one advantage that it can show preedit while inputting accented letters. Cheers, -- Etsushi Kato [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
Etsushi Kato wrote: On 7/18/06, Etsushi Kato [EMAIL PROTECTED] wrote: I committed the changes for gtk+ and Qt immodule on freedesktop's svn repository while ago. Now you can use all compose sequences and ~/.XCompose with gtk+ (Mozilla, Firefox, Thunderbird, Gedit and so on) and Qt (Kate, ...) immodules of uim as well as XIM. Unless I am mistaken, in the present version (1.1.0) I can already input all Compose sequences in Qt programs (with the uim input method). Only in GTK programs and Mozilla do I have to use the xim input method with 1.1.0. You can download source code and try them from svn://anonsvn.freedesktop.org/svn/uim/trunk/ using svn. Or wait 1.2.0-alpha release. I'll try if I can compile it, and if not I'll wait. Thanks very much for this quick work. For Debian this would mean -- making the uim input method the default -- including uim-qt in the uim metapackage. I think this change would make the Latin IM superfluous, doesn't it? Because all Latin (and also all other) accented letters will be available with all input methods when conversion is switched off (shift-space). Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
On 7/16/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote: I'm one of the developer of uim. As far as I can tell, you can avoid this complete freeze of X by using --async option of uim-xim. Thank you!!! This indeed works. In Debian Sid, I set XIM_ARGS=--async in /etc/X11/xinit/xinput.d/uim-systray, and indeed it works now exactly as you said: CPU usage goes to 100% when I 'mis-hit' keys, but this is temporary and X does not freeze. If no side effects are expected, I would vote for async to be the default. I just wonder why Omote-san could not reproduce this. Hmm... It it known that --async option has a side effect (and also SCIM's x11 has) in inputting characters into Tck/Tk widget. We cannot input any character in Tcl/Tk version below 8.4.13. And I think our default behavior (not using --async) is suitable for old applications like xfig and tgif. I think this bug is caused from invalid use of filter key event in mozilla in the address bar widget. So you agree it is a bug? Can you reproduce it? If it is a bug in Mozilla/Firefox, somebody should report it, but I'm afraid I do not have the technical knowledge about 'filter key events' to describe it exactly. Yes, I can reproduce it. But the bug is very difficult to describe and solve. IMHO, It can be said that the bug is in mozilla's complex use of filter key event (how to handle key event) in term of XIM, but it is indeed a problem in libX11's XIM protocol. With gtk+ immodule other than XIM (i.e. other than im-xim.so), this cannot be said a bug in mozilla and it works perfectly. X11's XIM protocol is not well defined and not suitable for such a complex use of key filter event like mozilla. 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. With uim default method = direct, it is as if uim does not exist. There is just the arrow symbol in the systray. All the xkb/compose stuff works (not so with SCIM, that ís why I like uim better!). But if I want to use uim, it is there, and I can activate it by right-clicking on the arrow. 2 - xim always works. When I activate uim, I can use it everywhere: xterm programs, openoffice, qt programs, gtk programs, mozilla, even in xfig. Very simple, very neat. I see. For 1, I've implemented X11's equivalent compose mechanism in uim-xim, so it should work as if it doesn't exit :). In gtk+ (Qt), maybe you can ask developers of gtk+ (Qt) directly to support all the compose sequences of X11's. Or maybe I can implement uim's immodule to support them. Also I as noted in previous mail, please test uim's Latin IM with uim immodule (if you can find a bug or request to it, please file a bug in uim's bugzilla at freedesktop.org). For 2, That's true. But as I described above, XIM protocol is not very easy to implement in a application properly (because XIM is not well designed IMHO), and gtk+ or qt's immodule is more robust in complex use of inputting mechanism. So if a application support immodule and uim or SCIM immodule is available, we recommend use uim (SCIM) immodule. 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. Cheers, -- Etsushi Kato [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
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
Bug#377808: Re : uim can cause crash of X
On 7/17/06, Jan Willem Stumpel [EMAIL PROTECTED] wrote: 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. Right. 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. Yep, Latin IM is still experimental one. But it is easily extensible as it is just a compose table in a text file, as you can see in $prefix/share/uim/latin.scm. Also user can modify it in ~/.uim. Still, I agree with you that using X Compose file depending on working locale and ~/.XCompose is more consistent in X11 environment. 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. See below. 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.. 4) uim - implement X's equivalent compose mechanism in uim's gtk+ immodule and Qt immodule. It is fairly easy since we already have it in uim-xim. And I just tested to port this in uim's gtk+ immodule, it works pretty well. We have a release plan of uim-1.2.0 in this month, and this feature can be put into it. If so you will be able to use uim all the environment and all the X's compose input with it. What do you think? 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.. IMHO, XIM protocol is badly designed, and no one seems to fix it. Cheers, -- Etsushi Kato [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
On 7/18/06, Etsushi Kato [EMAIL PROTECTED] wrote: 4) uim - implement X's equivalent compose mechanism in uim's gtk+ immodule and Qt immodule. It is fairly easy since we already have it in uim-xim. And I just tested to port this in uim's gtk+ immodule, it works pretty well. I committed the changes for gtk+ and Qt immodule on freedesktop's svn repository while ago. Now you can use all compose sequences and ~/.XCompose with gtk+ (Mozilla, Firefox, Thunderbird, Gedit and so on) and Qt (Kate, ...) immodules of uim as well as XIM. You can download source code and try them from svn://anonsvn.freedesktop.org/svn/uim/trunk/ using svn. Or wait 1.2.0-alpha release. Cheers, -- Etsushi Kato [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
Etsushi Kato wrote: I'm one of the developer of uim. As far as I can tell, you can avoid this complete freeze of X by using --async option of uim-xim. Thank you!!! This indeed works. In Debian Sid, I set XIM_ARGS=--async, and indeed it works now exactly as you said: CPU usage goes to 100% when I 'mis-hit' keys, but this is temporary and X does not freeze. I think this bug is caused from invalid use of filter key event in mozilla in the address bar widget. So you agree it is a bug? Can you reproduce it? If it is a bug in Mozilla/Firefox, somebody should report it, but I'm afraid I do not have the technical knowledge about 'filter key events'to describe it exactly. Even if you use uim-xim --async (or maybe SCIM's x11 module), CPU usage may increase to 100% while inputting some characters with completed addresses below address widget popup, but in this case mozilla won't freeze at all. By the way, you seem to like using XIM instead of gtk+ immodule because of the compose sequences in X11. I think you can try uim's gtk+ immodule with latin IM (selecting Latin characters from toolbar) enabled. It support most of the sequence in X's compose sequence using Compose key (bug dead key is not supported yet). You can modify this table if you like. Please check the table in /usr/share/uim/latin.scm. Cheers, -- Etsushi Kato [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377808: Re : uim can cause crash of X
(Sorry, hit the send button too soon) Etsushi Kato wrote: I'm one of the developer of uim. As far as I can tell, you can avoid this complete freeze of X by using --async option of uim-xim. Thank you!!! This indeed works. In Debian Sid, I set XIM_ARGS=--async in /etc/X11/xinit/xinput.d/uim-systray, and indeed it works now exactly as you said: CPU usage goes to 100% when I 'mis-hit' keys, but this is temporary and X does not freeze. If no side effects are expected, I would vote for async to be the default. I just wonder why Omote-san could not reproduce this. I think this bug is caused from invalid use of filter key event in mozilla in the address bar widget. So you agree it is a bug? Can you reproduce it? If it is a bug in Mozilla/Firefox, somebody should report it, but I'm afraid I do not have the technical knowledge about 'filter key events' to describe it exactly. [..] 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. With uim default method = direct, it is as if uim does not exist. There is just the arrow symbol in the systray. All the xkb/compose stuff works (not so with SCIM, that ís why I like uim better!). But if I want to use uim, it is there, and I can activate it by right-clicking on the arrow. 2 - xim always works. When I activate uim, I can use it everywhere: xterm programs, openoffice, qt programs, gtk programs, mozilla, even in xfig. Very simple, very neat. Thanks again, Jan
