[EMAIL PROTECTED] wrote:
> Let me explain the problem with the attached screenshots.
>
> 1. On CJK-LyX main window, "shift-space" from the keyboard changes
> the blinking cursor to stand-still cursor, indicating local input
> method is on (screenshot0.png).
>
> 2. input method is composing characters inputting from the keyboard
> (screenshot1.png).
>
> 3. "space" from the keyboard now puts the composed characters on the
> lyx main window (screenshot2.png)
Oh, this is even nicer than I thought. So we just need a new xforms
input widget that has 'normal' and 'local input' states. State can be
toggled as you describe. No need for extra windows at all. I'm sure
we can do this.
> These are how CJK characters are inputted on the CJK-LyX main
> window.
>
> Now pop-up the "Find & Replace" box from Edit->Find & Replace menu.
> Then,
>
> 4. "shift-space" does not change the blinking cursor and instead
> moves the position on step forward, indicating local input method is
> not on (screenshot3.png)
>
> So There is no way of inputting CJK characters on that pop-up box.
> This is what I called the "linking problem".
>
> 5. Now what will happen if you copy CJK characters from somewhere
> else and try to paste them on that box ? You will get some garbage
> pasted (screenshot4.png).
>
> 6.If you properly introduce XmbDrawString in the xforms source, you
> get the correct CJK characters pasted on the box (screenshot5.png).
Excellent. Why don't you send this patch to the xforms list too. That
means you've fixed two of the three problem areas. All that remains
is the XmbLookupString mess and the 'linking problem'.
> So the linking problem remains.
Yes, we need to "introduce" some of the code in XWorkArea.C into
xforms. The code in the KEYPRESS part of XworkArea::handler up to and
including the call to
lyxim.LookupString(ev, s_r, 256, &keysym);
really belongs in xforms. Thereafter, we have to find a way to pass
(ev, s_r, num_bytes, keysym) from xforms' do_keyboard routine to
xforms' fl_keyboard routine which passes the event to a particular
widget. Either an xforms input widget or LyX's XWorkArea widget.
Maybe we should store s_r and num_bytes and make them retrievable by
the xforms input widget or by LyX's XWorkArea widget.
Ie, the code in XWorkArea would become:
// Moving lyxim.LookupString into xforms means that we
// don't have to interrogate the raw XEvent any more.
case FL_KEYPRESS:
{
KeySym keysym = event;
int num_bytes = 0;
char str[256];
if (keysym == 0)
// New xforms routine.
fl_fill_composed_string(&num_bytes, str);
if (!keysym && num_bytes)
area->workAreaCJK_IMprocess(num_bytes,str);
...
}
The xforms input widget would now do something similar to
area->workAreaCJK_IMprocess. Incidentally, in the case of the
XWorkArea widget, we should really pass (num_bytes,str) to
workAreaKeyPress and let /it/ call workAreaCJK_IMprocess, rahter than
the current code:
area->workAreaKeyPress(LyXKeySymPtr(xlk),
x_key_state(ret_state));
Retuning to the xforms' input widget, this doesn't look too
complicated. I'm sure we can do the xforms equivalent.
+#ifdef I18N
+ void LyXFunc::CJK_IMprocess(int num_bytes, char * s_r)
+ {
+ // this function should be used always [asierra060396]
+
+ if (num_bytes !=0) {
+ s_r[num_bytes]='\0';
+ string wstring(s_r);
+ LyXText * text = view()->getLyXText();
+ view()->hideCursor();
+ view()->beforeChange(text);
+
+ text->insertStringAsParagraphs(view(), wstring);
+ text->selection.set(false);
+
+
view()->update(text,BufferView::SELECT|BufferView::FITCUR|BufferView::CHANGE);
+
+ text->selection.cursor = text->cursor;
+ moveCursorUpdate(text,false);
+
+// return 0;
+ }
+ }
+#endif
Does this make sense?
--
Angus
