On Wednesday 29 January 2003 4:42 pm, [EMAIL PROTECTED] wrote:
> On Tue, 28 Jan 2003, Angus Leeming wrote:
> > Of course, I don't know what I'm doing when it comes to the nitty gritty
> > of creating an input context,

> I don't know about the input context any more than you don't, but somebody
> has to deal with it to solve the CJK-LyX problem,....sigh...

> >but can't you create and then destroy a new one
> > each time you toggle the input method? That's what my patch to input.c
> > does.

> Well, my test shows that your input.c still does not change the input
> context, i.e., preedit position, etc.  The code looks fine to me but it
> does not function as expected.

This is with my note about setting location.x = ob->x etc?
Perhaps you have to
        if (flcontext->xic)
                XDestroyIC(flcontext->xic);
before you create a new one.

Also, a quick 'grep xic' of the xforms sources comes up with
    case FocusIn:
        if (fl_context->xic)
        {
            M_info("Focus", "Setting focus window for IC");
            XSetICValues(fl_context->xic,
                         XNFocusWindow, st_xev.xfocus.window,
                         XNClientWindow, st_xev.xfocus.window,
                         0);
        }
        break;

If you re-create the IC, then presumably you have to do this too?

> > The code compiles and DOES NOT CRASH when I use it, so that's a start.

> In your "trial" xforms box, I can link with the input method. That is I
> can compose CJK-characters through input method, but when I hit
> "space-bar" on the keyboard, the composed CJK-characters disappear from
> the box.

I'm getting confused. This is using an unmodified xforms1.0 or using the 
changes you've made already to fl_initialize? Presumably it's not with my 
suggested change to input.c because that doesn't create a IC at all? 

Anyway, for the present problem, it doesn't really matter whether you create 
an IC just once, in flinitialize, or if you do it dynamically in input.c.

You tell me that you have created a pre-edit area and can use it successfully. 
Your problem lies in the final step when returning to 'nornal' mode? But, my 
question to you is: how does the code know what 'normal' mode is? At present 
'space' means nothing special to the xforms code. Are you not still in 
preedit mode and have just typed a space in your preedit area?

Why not test this hypothesis with a little
        if (key == XK_Space)
                return 0;
in input.c (since you're not yet manipulating the IC using Shift-Space and 
Space) before any change to the widget is made.

> > assume that you'll have to move the code in lyxim into the xforms
> > library to actually proceed from here (input CJK) but that was the
> > point of the excercise wasn't it?

> Yes, that was my intention.

Being generally ignorant of all this, I'm actually amazed that you can get 
anything at all before merging this code into the library. What will the code 
in lyxim give you once you have resolved your problems with the IC?

> Oh, by the way, the "DUMMY_FONT_NAME" is
> #define DUMMY_FONT_NAME       "-*-*-*-r-normal--14-130-75-75-*-*"

Ok.

Am I correct in saying that I can't actually test things at all from this end 
because the input method is actaully a daemon process running in the 
background. I have vague memories of helping a Japanese visitor to the lab 
set up his machine so that he could use emacs in this way.

I also seem to remember that he used it as a two step process. in step 1 he 
created a symbol from a number of key presses and then in step 2 he used 
arrow keys to toggle between several possible kanji characters. Is this 
second part the external input method?

It seems to me that you should post a question to some eastern mailing list 
where you're more likely to find experts at this sort of thing.

Sorry I can't be of more help.
Best wishes,
Angus

Reply via email to