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?
> > 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?
> > 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
XIM key interpretation fix for 2.2.x?
Hi, 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. For example, in gedit, if one uses the skkinput method, hitting Ctrl+G in the appropriate context will always trigger a gedit dialog box, though in skkinput, it means to cancel the current conversion. The bug is particularly annoying when "Enter" means different things to the IM and the application. 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. 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
