Created attachment 3604 [details]
Disables the custom-rendered IME candidate list, enables/fixes the OS-drawn

The current implementation seems to be incomplete but still activated/initialised. The IME_Present() that is supposed to render the custom-drawn candidate window is never called and contains a FIXME asking for finishing the implementation.

Having a custom-rendered candidate list might be desired in case of some applications (for the consistent visuals) or might be required (because on some older platforms there might be z-fight between a fullscreen app and the IME windows drawn by the operating system).

However, having the OS-drawn candidate list can also be desired by many applications:
- It maintains a consistent look for the candidate list across all desktop apps
- In case of windowed apps the candidate list can easily use more desktop space than the rendered area of the app
- A native candidate list can have better/more features
- On modern windows operating systems (like Win 10) the native candidate list doesn't z-fight/flicker (windowed, windowed-fullscreen, fullscreen)

In my opinion even if SDL adds a functional custom-drawn candidate list implementation for windows in the future it should still give an option to use the OS-default. In case of the custom-drawn candidate list it might be a good idea to give customisation options to the app: let it draw the whole list or at least set a color theme and/or font size.

Since the current UILess IME implementation is incomplete and dysfunctional I've attached a small patch that disables it and makes the OS-default candidate list work. I've tested it on windows 10 with Chinese and Japanese IME.

BTW, how are these features tested on multiple versions of windows considering that SDL2 supports WinXP and later? There have been quite a few IME versions since then and according to various sources there are third-party IMEs that behave in a weird way for example when it comes to finding out the candidate list position.
E.g.: https://bugs.chromium.org/p/chromium/issues/detail?id=62020

The original code that I've replaced (the ImmSetCompositionWindow function call) didn't work on my Win10 with Japanese IME and with Chinese IME it added an Y-offset that was the height of the font set with ImmSetCompositionFont. Since the code didn't set the font the default was the "System" font with a relatively small height.

Since WinXP there is TSF (Text Services Framework) that is a more complex API and newer windows versions use this as a base to implement the old IME API (IMM32). The incomplete UILess mode is also based on the newer TSF and it would probably be a good idea to migrate the whole IME code to it including the version that uses OS-drawn candidate list. Unfortunately I have no experience with TSF.

(In reply to xenotron007 from comment #1)
> Created attachment 3604 [details]
> Disables the custom-rendered IME candidate list, enables/fixes the OS-drawn

It almost works in Windows 10, IME candidate list is being shown, but items are not rendering, but I can choose item.

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

I, as a Japanese user, confirmed that the patch enables IMEs in Kivy apps on Windows.
(I haven't tested it on other platforms yet, though)

With stock SDL-2.0.10, Kivy's TextInput doesn't show any IME information.
Japanese Kivy users have struggled to workaround the situation for *years*.
(I found an article https://qiita.com/dario_okazaki/items/815cdebe91211f2b3826 published in April 2017.)

If you push xenotron007's patch in the code and release 2.0.11 with it, you'll save many many developers and users in Asia. Thanks in advance!

The problem is, this doesn't work for fullscreen games, which have exclusive rendering. We could enable this feature for windowed and fullscreen-desktop games. Any suggestions on how to fix this for all games?

(In reply to Sam Lantinga from comment #7)
> The problem is, this doesn't work for fullscreen games, which have exclusive
> rendering. We could enable this feature for windowed and fullscreen-desktop
> games. Any suggestions on how to fix this for all games?

Oh, I didn't know that. Thanks for your input.
Then why don't you just expose candidate lists, as you are already exposing editing texts?
It seems that SDL currently tries to show candidate lists by itself and fails.

https://wiki.libsdl.org/Tutorials/TextInput#Workflow says, "the application is responsible for drawing the composition." Then why is the application NOT responsible for drawing the candidate list?

It would be fine if you just allowed us to write, for example, https://wiki.libsdl.org/Tutorials/TextInput#Example as following:

    if (SDL_PollEvent(&event)) {
        switch (event.type) {
            case SDL_TEXTEDITING:
                composition = event.edit.text;
                cursor = event.edit.start;
                selection_len = event.edit.length;
                candshow = event.edit.candlist; // <------ bool
                candcount = event.edit.candcount; // <---- int
                candidates = event.edit.candidates; // <-- wchar[MAX_CANDLIST][MAX_CANDLENGTH]
                candsel = event.edit.candsel; // <-------- dword
                break;
        }
     }

Then we would implement some windows or boxes to show the candidates by ourselves, wouldn't we?

if(candshow){
  for(i=0; i<candcount; ++i){
    wchar *s=candidates[i];
    if(!*s)
      break;
    if(i==candsel){
      // render it as selected
    } else {
      // render it as normal
    }
  }
}

TEXTEDITING event struct is already full. So another event for candidate list would be helpful.
Required memory (MAX_CANDLIST * MAX_CANDLENGTH) is quite large and doesn't fit in 56-byte struct. It would need some clever mechanism rather than just adding a few lines.
But a new event would suffice our needs in all cases including fullscreen games, without affecting existing codes.

Created attachment 3950 [details]
textedit event with extra info

This patch implements another event.
I managed to pack necessary information for Japanese IME into 56-byte structure (and a couple of mallocs, though).
With this patch in, I could implement some IME UI in a Kivy app.

Created attachment 3951 [details]
patch for kivy to cope with attachment 3950 [details]

I have confirmed that attachment 3950 [details] works well with Japanese IMEs.
I can input Japanese text on Kivy's on_textedit_event example (with this patch).

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.