Wrong IME composition window position.

[theoractice]

This is a common issue for GUI frameworks.

Normally the composition window is placed under the cursor.

But currently in MewUI, the position is wrong:

[Charltsing]

1. Add ImeMode
2. Add IME API

        [LibraryImport("imm32.dll")]
        public static partial IntPtr ImmGetContext(IntPtr hWnd);
        [LibraryImport("imm32.dll")]
        public static partial int ImmReleaseContext(IntPtr hWnd, IntPtr hIMC);
        [LibraryImport("imm32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static partial bool ImmSetCompositionWindow(IntPtr hIMC, ref COMPOSITIONFORM lpCompForm);

        [LibraryImport("imm32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static partial bool ImmSetOpenStatus(IntPtr hIMC, [MarshalAs(UnmanagedType.Bool)] bool fOpen);

        // 获取当前 IME 的转换状态
        [LibraryImport("imm32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static partial bool ImmGetConversionStatus(IntPtr hIMC, out uint lpfdwConversion, out uint lpfdwSentence);

        // 设置 IME 的转换状态（强制英文）
        [LibraryImport("imm32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static partial bool ImmSetConversionStatus(IntPtr hIMC, uint fdwConversion, uint fdwSentence);

        // 常量：IME 转换模式（强制英文）
        private const uint IME_CMODE_ALPHANUMERIC = 0x0000; // 英文/数字模式
        private const uint IME_CMODE_NATIVE = 0x0001;       // 本地语言模式（如中文）

        internal static void SetIMEPosition(HWND handle, D2D_POINT_2F Location)
        {
            IntPtr hIMC = ImmGetContext(handle);
            if (hIMC != IntPtr.Zero)
            {
                // 设置IME窗口位置（这里设置为光标位置下方20像素处）
                COMPOSITIONFORM compForm = new()
                {
                    dwStyle = CFS_POINT | CFS_FORCE_POSITION
                };

                compForm.ptCurrentPos.x = (int)Location.x + 20;
                compForm.ptCurrentPos.y = (int)Location.y + 20;

                // 设置IME窗口位置
                ImmSetCompositionWindow(hIMC, ref compForm);

                // 释放IME上下文
                ImmReleaseContext(handle, hIMC);
            }
        }

        internal static void SetIMEStatusOff(HWND handle)
        {
            IntPtr hIMC = ImmGetContext(handle);
            if (hIMC != IntPtr.Zero)
            {
                try
                {
                    //关闭 IME（禁用输入法）
                    ImmSetOpenStatus(hIMC, false);
                }
                finally
                {
                    ImmReleaseContext(handle, hIMC);
                }
            }
        }
        internal static void SetIMEAlphaNumeric(HWND handle)
        {
            IntPtr hIMC = ImmGetContext(handle);
            if (hIMC != IntPtr.Zero)
            {
                try
                {
                    //强制切换到英文模式
                    ImmSetConversionStatus(hIMC, IME_CMODE_ALPHANUMERIC, 0);
                }
                finally
                {
                    ImmReleaseContext(handle, hIMC);
                }
            }
        }

[aubreychao]

一直在左上角

[al6uiz]

Thank you for reporting the issue.

In Korea, we generally do not use conversion-based IMEs like those commonly used for Chinese or Japanese input. Because of this, I am not very familiar with these input methods, and it is difficult for me to perform extensive testing related to IME candidate positioning.

A fix for this issue has been committed. Feedback from users who actually use Chinese IMEs would be very helpful. If you could share how it behaves in your environment or report any remaining issues, it would help me better understand and improve the behavior.

[lextm]

Works fine for me on macOS 26.3.1, M1 Pro with the system built-in Chinese input method

[theoractice]

Thank you for the fix! Now it's almost perfect except some small adjustments:

Those are from windows notepad:

Those are from MewUI:

Can you spot the difference?

• The text underline goes through character 'j' and makes the ime input text less readable. It should be placed fully under the user input.
• Position of the composition window is incorrect for larger font sizes, there should be a 1px space between the underline and the composition window.

if those system behaviours are hard to replicate, can you simply try draw a half-grey text underline and move the composition window down according to font height? It will help improve the input text readability a lot. Thanks!

Additionally, while Windows / Chrome uses a dashed text underline here, I believe solid line or grey line is totally fine.

[al6uiz]

Please check the v0.14.0 release.

[theoractice]

Thank you for your effort! IME support is hard to be done right. In v0.14.0 there are still 2 issues:

• Certain IME will tell the GUI framework not to draw any preedit text, instead, it draws the text within the composition window itself:
  
  However in MewUI, preedit texts are still drawn (actually this doesn't matter much), and what really matters is that the position of the composition window is incorrect in this situation:
  

• From the GIF above and the image below (I used two fonts to show the difference), you can see that the underline is still placed too high. Could you please move it down a little more?

[lextm]

@theoractice I think,

• Not too much effort should be put into IME solutions that are not shipped with the OS itself (Windows/macOS). Third parties might use a lot of their own ideas, and a UI framework author (especially in MewUI's case) can never have enough time to chase.
• The slight position change request is reasonable. But that remains a low priority, as it doesn't prevent the users from viewing the key contents and the overall input experience is good enough.

[theoractice]

@lextm

• Not too much effort should be put into IME solutions that are not shipped with the OS itself (Windows/macOS). Third parties might use a lot of their own ideas, and a UI framework author (especially in MewUI's case) can never have enough time to chase.

If you are not Chinese then stop talking about things you don't have a clue. The Sogou IME in my image is the No.1 IME in China with more than 600 million monthly active users, the system default IME has much less users compared to Sogou. If support for Sogou IME is broken, then basically it means no developer in China will choose MewUI (believe it or not, that is exactly what happened to Avalonia before v11.0, when their IME support was a total mess). Besides, what I suggested is based on the instructions from MSDN and my experience developing my own IME (redrawing preedit text doesn't matter much, but the composition window position really matters). Calling the standard IME protocol "their own ideas" is ridiculous. You don't know anything about the IME server/client architecture, do you?

• The slight position change request is reasonable. But that remains a low priority, as it doesn't prevent the users from viewing the key contents and the overall input experience is good enough.

Saying the request is "a low priority one” might be reasonable for yourself (although it should be quite easy to fix), but trying to say "the overall input experience is good enough" is clearly not. if you can't even recognize the Sogou IME and its importance for Chinese users, then don't try to advocate on our behalf. This is just to make sure that the level of IME support is on par with the exquisite UI detail and the underlying high standard that MewUI currently exhibits (thank you again, aprillz). I am sure many developers in China are looking for WinForm style GUI solutions with NativeAOT support that can even run on Win7, and just like Avalonia, IME support is the only thing holding them back.

[lextm]

@theoractice

A quick reminder: this is a public discussion, so basic manners still matter.

• The README already makes the purpose of this project quite clear. If you really want to build business applications with it and serve the “hundreds of millions of users” you mentioned, a more meaningful response would be to support the developers who made it possible, rather than repeating raw numbers that prove very little on their own. AvaloniaUI itself only started investing seriously after seeing real business potential in the region and eventually opening an office in China.
• I was clearly giving my own assessment. The actual direction is, of course, for @al6uiz to decide. And this is not an isolated concern either. There are already other reported issues that require more work, such as Styling System #53, Porting AvalonEdit to MewUI (MewvalonEdit) #45, and Add file drag and drop to Window #12.

[Charltsing]

I think this issue should be judged by the project maintainer, and there is no need for you two to argue.
From my personal perspective, I hope for better compatibility with input methods. After all, billions of people are using it