Hi, On 3/10/07, Sébastien PLISSON <[EMAIL PROTECTED]> wrote:
Your patch works great
Thanks :) And please try the revised one.
Can you tell me more about the drawing preedit text and cursor position, I may implement it or maybe you already have a patch for it :-)
I haven't yet started to implemented them ;) Anyway, for example, while inputting "é" with "Option-E" and "E" sequence with US keyboard layout, it shows "´" character with the first key stroke and then commit "é" with the second stroke. In this case, "´" is so-called preedit text. Japanese input method extensively uses preedit text because of its complex behavior. For "é" case, maybe it doesn't matter whether preedit text "´" is shown or not since it requires only two key strokes to input. But for Japanese input method, drawing preedit text does matter since somewhat long text is usually used for the preedit. These text from Input Method is passed with kEventTextInputUpdateActiveInputArea event. Currently my patch only treats committing string (like "é"). Drawing preedit is somewhat complex since it require some character attributes like underline, reverse, and so on. I think an implementation in vcl/unx/gtk/window/gtkframe.cxx will be a good reference for it. For kEventTextInputOffsetToPos event, it is also used for Input Methods. For example, while inputting Japanese text, it uses a "candidate window" to select appropriate word (Kanji) from inputting characters (Hiragana). So candidate window should be positioned just below the inputting Hiragana preedit. HandleOffsetToPos() is the function to send x and y points of the current display for the Input Method. Offset means the precise position about the current word in a preedit text. It will be great help if you could tell me how to get x and y position of the cursor in a salframe. Cheers, -- Etsushi Kato [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
