Re: XIM key interpretation fix for 2.2.x?
On Sat, 6 Sep 2003 22:34:33 -0700 Ken Deeter [EMAIL PROTECTED] wrote: - it has to be made clear to a person using a im context that they need to override this added method. An ideal solution should not require a creator of a widget that uses an IM context to have to implement a separate method so that the IM will get keystrokes, it should happen automatically I think your opinion is right. I'm noticed adding new method doesn't seem good to solve this problem. I think the spirit of the original snooper patch is more appropriate. The IMContext should be modified so that when it is or becomes active, it tells someone i need keystrokes, and the keystroke handling mechanism should be modified so that when it knows a particular context needs keystrokes, they will get there. I think spirit of original snooper patch is not enough. Because now we are disscussing about IM key event handling, but Gtk+ has another key event handling problem. Another problem is discussed in the last few days on gtk-devel-list. I think gtk+ should have something new keystroke handling mechanism. (So, our conclusion may be same.) Regard, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Fri, 05 Sep 2003 12:13:26 +0900 Takuro Ashie [EMAIL PROTECTED] wrote: To determine whether the state is inputing or not, I think input widgets should have a vertual method like get_im_context or get_active_im_context. If input widgets has such a method, toplevel doesn't always need to have im context variable. Instead, we can determine the state by querying to focused widget through such method. If such change is possible, solving the bug will be easy. But I'm not sure this is good appropirate, too... Regards, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
If such change is possible, solving the bug will be easy. But I'm not sure this is good appropirate, too... Just to keep the discussion going, this patch is surely one way to solve it, but i think it has some disadvantages. - it has to be made clear to a person using a im context that they need to override this added method. An ideal solution should not require a creator of a widget that uses an IM context to have to implement a separate method so that the IM will get keystrokes, it should happen automatically - a bug in behaviour should not reuire an API change to fix, or at least it should not require apps using the library to change their code to fix. - if we add this function, widgets that use an im context but not nec. included in the gtk-2.4 release will not be fixed. They all have to add their own get_im_context-like overriding method I think the spirit of the original snooper patch is more appropriate. The IMContext should be modified so that when it is or becomes active, it tells someone i need keystrokes, and the keystroke handling mechanism should be modified so that when it knows a particular context needs keystrokes, they will get there. This ensures that people who make their own widgets and use an IM context, will get proper behaviour, without having to override any methods. -- +--+ ( Ken Deeter (Kentarou SHINOHARA) ( ) ) ( If only God were alive to see this.. ( ) -Homer Simpson ) +--+ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Wed, 3 Sep 2003 20:43:35 -0700 Ken Deeter [EMAIL PROTECTED] wrote: 1. add active (this means while inputing) im context variable to each toplevel window From a application behaviour point of view (as opposed to the code's point of view) I think we want the im to steal events only when the focus appears to be on a text inputting widget and when the IM is active. I agree with you that IM want keystrokes only when inputting. So active im context variable should set to NULL when focused text input widget loses the focus, I think. Regards, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
Hi all. I'm also considering about this problem. I don't have complete solutions yet, but at least I agree with Tokunaga-san's opinion mostoly. At Fri, 5 Sep 2003 04:37:40 +0900, TOKUNAGA Hiroyuki wrote: I agree with you that IM want keystrokes only when inputting. So active im context variable should set to NULL when focused text input widget loses the focus, I think. To determine whether the state is inputing or not, I think input widgets should have a vertual method like get_im_context or get_active_im_context. If input widgets has such a method, toplevel doesn't always need to have im context variable. Instead, we can determine the state by querying to focused widget through such method. Here is the sample patch: http://www.homa.ne.jp/~ashie/linux/files/gtk+-2.2.4-get_im.diff But, I'm not sure such a change is appropriate or not. Regards, -- Takuro Ashie Mail: [EMAIL PROTECTED] Web: http://www.homa.ne.jp/~ashie/ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Tue, 02 Sep 2003 17:43:20 -0400 Owen Taylor [EMAIL PROTECTED] wrote: I'd suggest looking at: http://bugzilla.gnome.org/show_bug.cgi?id=90082 instead. The problem is not widgets should get all keystrokes before accelerator processing But: Input methods should get keystrokes before accelerator processing The first would be a way of solving the second, but not the only way. I thought the first is good way of solving second, but now I've understood first is not good way. because it's not compatible with the XEMBED spec. In addition, my patch at 111438 does not solve all of the second problem. So the patch is not good at all, I think. To solve this problem, once inputing starts, input method should steal all inputs from the keyboard until inputing ends, I think. (I haven't finished reading XEMBED Spec and haven't understood proper behavior of Client/Embedder, so I cannot say how we should do to solve the problem.) Yes, handling XEMBED is a major problem here. You are saying at Bug 90082, Note that any method involve intercepting key events on the toplevel will not work in the context of embedding, as done with Bonobo. I interpreted this as follows, If client side widget connect signal to the toplevel, it will not work properly, because client has no toplevel or client toplevel is not real toplevel. (I don't know which is correct, but I think intercepting key events will not work in either.) My interpretation is right? Is there still any other problem? Intercepting key events on the toplevel will not work properly, so we have to find a new solution to solve this problem, and I propose a new solution. 1. add active (this means while inputing) im context variable to each toplevel window 2. while active im context exists, keystroke is passed to the im context first. Do you think this good or not good? Such change is easy? Regards, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
1. add active (this means while inputing) im context variable to each toplevel window I'm not sure of all the details so I do apologize if I mis-assume something. I just wanted to make sure, if this happens, then what will be the case when say one activates an IM, but input focus go's off of a text input widget.. will keypresses still be passed to the IM? From a application behaviour point of view (as opposed to the code's point of view) I think we want the im to steal events only when the focus appears to be on a text inputting widget and when the IM is active. I'm not sure if thats what you meant, or whether your proposed solution produces this effect. I only wish to confirm. Ken ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Mon, 1 Sep 2003 16:58:18 -0700 Ken Deeter [EMAIL PROTECTED] wrote: I've been looking through bugzilla for the exact report.. but there was(still is w/ 2.2.x) a problem where when using the XIM based immodule, key events are recieved by the application even when an XIM consumes those keys. It's not a problem about XIM based immodule only. All of immodule has the same problem. I've reported to bugzilla a few month ago, and you can see the report at http://bugzilla.gnome.org/show_bug.cgi?id=111438 Anyhow, I know it has been fixed (i just can't find the report) and was curious if it could be backported to the 2.2.x branch, as it is still quite annoying to deal with (in every gtk+ app). I tried 2.2.3 but the behaviour was still the same. This bug has been fixed? I've tested latest CVS now, but seems this bug isn't fixed yet. To solve this problem, once inputing starts, input method should steal all inputs from the keyboard until inputing ends, I think. (I haven't finished reading XEMBED Spec and haven't understood proper behavior of Client/Embedder, so I cannot say how we should do to solve the problem.) Regards, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
This bug has been fixed? I've tested latest CVS now, but seems this bug isn't fixed yet. My apologies, http://bugzilla.gnome.org/show_bug.cgi?id=90082 was the one I was looking for but apparently there has been some more stuff added since I last looked. To solve this problem, once inputing starts, input method should steal all inputs from the keyboard until inputing ends, I think. (I haven't finished reading XEMBED Spec and haven't understood proper behavior of Client/Embedder, so I cannot say how we should do to solve the problem.) Right, I'm not too sure of the details either, but the input methods definitely need to receive everything before anyone else. I suppose this makes the original request moot. I just hope this is really solved before 2.4 then. Wish I had the time to poke around the code myself :-( Ken -- If only God were alive to see this.. -Homer Simpson ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Mon, 2003-09-01 at 23:10, TOKUNAGA Hiroyuki wrote: On Mon, 1 Sep 2003 16:58:18 -0700 Ken Deeter [EMAIL PROTECTED] wrote: I've been looking through bugzilla for the exact report.. but there was(still is w/ 2.2.x) a problem where when using the XIM based immodule, key events are recieved by the application even when an XIM consumes those keys. It's not a problem about XIM based immodule only. All of immodule has the same problem. I've reported to bugzilla a few month ago, and you can see the report at http://bugzilla.gnome.org/show_bug.cgi?id=111438 I'd suggest looking at: http://bugzilla.gnome.org/show_bug.cgi?id=90082 instead. The problem is not widgets should get all keystrokes before accelerator processing But: Input methods should get keystrokes before accelerator processing The first would be a way of solving the second, but not the only way. Anyhow, I know it has been fixed (i just can't find the report) and was curious if it could be backported to the 2.2.x branch, as it is still quite annoying to deal with (in every gtk+ app). I tried 2.2.3 but the behaviour was still the same. This bug has been fixed? I've tested latest CVS now, but seems this bug isn't fixed yet. To solve this problem, once inputing starts, input method should steal all inputs from the keyboard until inputing ends, I think. (I haven't finished reading XEMBED Spec and haven't understood proper behavior of Client/Embedder, so I cannot say how we should do to solve the problem.) Yes, handling XEMBEd is a major problem here. Regards, Owen ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
