[Mono-winforms-list] patch for enabling primitive XIM text input

[Atsushi Eno]

Hello,

Very nice to know that there was another attempt to work on XIM support :)

Doug Rintoul wrote:
> 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.
>
Ah, good point! It should be fixed too. But I somewhat doubt if your change
especially that KeyRelease event is always passed works fine.
It could result in inconsistent key event processing (KeyPress could be
filtered and KeyRelease always isn't) and such inconsistency trapped me
couple of days. So, IMHO there should be some condition to determine
whether to filter KeyRelease or not.

> 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.
>
I'm not sure what you meant here. Do you mean such event processing like 
below
could happen? :

    - KeyPress for 'A' occurs, and then it is stored in X event queue 
... well, "stack" ...
      as pending.
    - KeyPress for 'B' occurs, and then it is stored as pending.
    - XNextEvent() is called, and X returns KeyPress 'B' because it is 
not FIFO.

Gtk and Qt of course have different event processing model from 
winforms, so it
could be just that the issue with kfml does not occur. I'm not sure your 
change is
valid from our perspective (UpdateMessageQueue() may have to lookup every X
events; I have no idea as I'm just digging into winforms only for XIM 
support ;).

Besides I'm not sure why giving up processing pending event immediately in
UpdateMessageQueue() could fix the situation. To my understanding, events
are anyways retrieved as LIFO (if I believe you) and if kfml anyways 
regenerate
other messages as a result of KeyPress, they will be retrieved immediately
anyways, won't they?

> 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.
>
Hmm, I don't think Windows Forms allow such input method switching.
It just controls whether IM could be enabled (default) or not. Of course
it is possible to have different XICs for each window but I doubt we have
any configuration point (other than custom configuration, environment
variables or whatever).

> I am attaching a patch to fix the first two issues. Please considering 
> integrating it with your patch if it meets with your approval.
>
I'd wait for your reply but thanks a lot :)

Atsushi Eno