Re: XIM key interpretation fix for 2.2.x?

On Tue, 02 Sep 2003 17:43:20 -0400
Owen Taylor <otaylor redhat com> wrote:

> I'd suggest looking at: 
> 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

 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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]