No IME Candidate List visible

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Disables the custom-rendered IME candidate list, enables/fixes the OS-drawn (windows_ime.patch, text/plain, 2019-02-07 23:55:00 +0000, 2295 bytes)
• textedit event with extra info (SDL_editx_20190904.diff, text/plain, 2019-09-04 07:50:25 +0000, 16631 bytes)
• patch for kivy to cope with attachment 3950 (kivy_editx_20190904.diff, text/plain, 2019-09-04 08:00:36 +0000, 11238 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2016-09-09 17:27:29 +0000, Tim Walters wrote:

After enabling IME support with SDL_StartTextInput() there is no visible IME candidate list despite the TEXTEDITING events functioning properly.

Tested on Windows 7 and Windows 10 in windowed mode with Chinese and Japanese layouts.

On 2019-02-07 23:55:00 +0000, wrote:

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

On 2019-02-07 23:57:27 +0000, wrote:

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.

On 2019-02-08 01:02:33 +0000, wrote:

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.

On 2019-07-19 04:11:20 +0000, Andrey wrote:

(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.

On 2019-07-30 17:49:35 +0000, Ryan C. Gordon wrote:

(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.

On 2019-08-30 15:46:21 +0000, tamo wrote:

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!

On 2019-08-30 18:29:08 +0000, Sam Lantinga wrote:

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?

On 2019-08-31 03:14:11 +0000, tamo wrote:

(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
}
}
}

On 2019-09-02 15:37:47 +0000, tamo wrote:

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.

On 2019-09-04 07:50:25 +0000, tamo wrote:

Created attachment 3950
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.

On 2019-09-04 08:00:36 +0000, tamo wrote:

Created attachment 3951
patch for kivy to cope with attachment 3950

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

On 2019-09-20 20:47:37 +0000, Ryan C. Gordon wrote:

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.

On 2019-09-20 20:48:40 +0000, Ryan C. Gordon wrote:

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.

[ericoporto]

Hi, I am trying to understand, what is and what isn't implemented, from the comments that were migrated above. From what I can tell it can show a candidate list using the OS native ui, but forwarding the candidate list so you can render as you wish in-game, is not supported yet. Is this correct?

I am trying to understand

• Can you show OS native candidate list when the game is in full-screen?
• Is this list available for retrieval? (it looks like it's somewhere in the code:

  SDL/src/video/windows/SDL_windowskeyboard.c

  Line 902 in ff735b3

  IME_GetCandidateList(HWND hwnd, SDL_VideoData *videodata)

  )
• There's a very minimal doc here, but it's not clear if the candidate list is in the event
• Is there a list that is rendered by SDL2 instead?

[slouken]

SDL 2.0 is now in maintenance mode, and all inactive issues are being closed. If this issue is impacting you, please feel free to reopen it with additional information.