I too have been working on a patch for adding XIM support to winforms. I
had something working last December, but due to a number of factors was
not ready to submit it for review. However comparing your patch to mine,
I see we have come up with very similar solutions. There are however a
couple of problems I found with your patch which can be very easily fixed.
The first problem has to do with the tracking of the control, shift, and
alt key. These keys will currently get "stuck" because if FosterParent
filters the key release event, a key release event for these keys are
never put on the hwnd Queue. For example, if you press CTRL-space to
enable an IM, winforms still thinks the control key is still pressed,
even after you release it. Using the left and right cursor keys to move
around a input field will move a word at a time, rather than a letter at
a time.
The second issue has to do with the way that IME compose messages are
handle. A bit of background is required here. I am one of the authors of
KMFL (kmfl.sourceforge.net), which provides Tavaultesoft Keyman services
to Linux. The way KMFL is designed is that KMFL can generate multiple
compose messages in response to a single key stroke. The problem is that
XIM does not use a FIFO to queue XIM compose messages, but a stack. So
unless XIM compose events are processed immediately upon receipt, the
recipient window will receive the XIM compose messages in the reverse
order that they are generated. The fix is rather easy to implement. We
just allow the application to process the keypress messages upon receipt
rather than queuing a whole bunch and then returning. Note that the GTK
XIM connector and the QT XIM interface work correctly with KMFL, so they
implement a similar solution.
There is a third issue, the importance of which is debatable. For other
frameworks (QT, GTK), each window in an application gets its own input
method, independent of the other windows in an application. For example,
in a text editor, even though you enable the input method, for the main
editor, the IM is not enabled for the search box. This may not seem
important at first, but it can be an issue for multilingual application
where different fields can have different input methods associated with
them. The patch I created last November did support this feature;
however it does add a lot of complexity to the mix.
I am attaching a patch to fix the first two issues. Please considering
integrating it with your patch if it meets with your approval.
Thanks,
Doug Rintoul
SIL Intl.
Index: System.Windows.Forms/X11Keyboard.cs
===================================================================
--- System.Windows.Forms/XplatUIX11.cs 2008-03-19 13:09:35.000000000 -0700
+++ System.Windows.Forms.new/XplatUIX11.cs 2008-03-19 13:19:30.000000000 -0700
@@ -1561,15 +1561,18 @@
XNextEvent (DisplayHandle, ref xevent);
- if (xevent.AnyEvent.type == XEventName.KeyPress ||
- xevent.AnyEvent.type == XEventName.KeyRelease) {
+ if (xevent.AnyEvent.type == XEventName.KeyPress) {
if (XFilterEvent(ref xevent, FosterParent)) {
// probably here we could raise WM_IME_KEYDOWN and
// WM_IME_KEYUP, but I'm not sure it is worthy.
continue;
}
}
-
+ else if (xevent.AnyEvent.type == XEventName.KeyRelease)
+ // Allow the Input Method to process key releases but also pass them on to the
+ // keyboard event processing because certain states (Shift, Control) are not
+ // correctly if we don't.
+ XFilterEvent(ref xevent, FosterParent);
else if (XFilterEvent (ref xevent, IntPtr.Zero))
continue;
}
@@ -1727,6 +1730,10 @@
}
case XEventName.KeyPress:
+ hwnd.Queue.EnqueueLocked (xevent);
+ /* Process KeyPresses immediately. Otherwise multiple Compose messages as a result of a
+ * single physical keypress are not processed correctly */
+ return;
case XEventName.ButtonPress:
case XEventName.ButtonRelease:
case XEventName.EnterNotify:
_______________________________________________
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
