I need anyone proficient with any IME that is willing/able to test my Windows input method support.
I especially need anyone familiar with Chinese or Korean IMEs.
I have tested Japanese myself but if you are willing to test it out some more, please do.
Using the language bar to switch input languages does /not/ work while
this program is running. Using left-alt+left-shift to switch input
languages also does not work. Both of these methods work under Windows
with other Windows programs.
I was unable to enter Japanese input mode with this program. Therefore
I was unable to test how this program interacts with the Japanese IME.On 7/28/2010 14:27, dewyatt wrote:
I need anyone proficient with any IME that is willing/able to test my
Windows input method support. I especially need anyone familiar with
Chinese or Korean IMEs. I have tested Japanese myself but if you are
willing to test it out some more, please do.
Using the language bar to switch input languages does /not/ work while
this program is running. Using left-alt+left-shift to switch input
languages also does not work. Both of these methods work under Windows
with other Windows programs.
I was unable to enter Japanese input mode with this program. Therefore
I was unable to test how this program interacts with the Japanese IME.
Hi.
You didn’t mention your Windows version.
I have tested Japanese input on XP and 7 and it works fine.
You should be able to alt+shift or use the lang bar as usual.
Could you give me your exact Windows version by running winver (example: Version 6.1(Build 7600)).
Thanks.
My only guess is that you’re on 2000 or an older version of XP than I tested on.
I’m going to call “false alarm”. I rebooted and now both the language
bar and alt-shift both work.
Japanese input seems to work within the described limits (i.e. no
candidate window). Chinese input also seems to work within the
described limits. Umlaut composition with the US International keyboard
layout works, and Arabic text seems to be input correctly. (Arabic text
is /not/ rendered correctly, but that’s an entirely separate issue.)
I am running Windows XP Professional, SP3.On 8/11/2010 20:26, dewyatt wrote:
Hi.
You didn’t mention your Windows version.
I have tested Japanese input on XP and 7 and it works fine.
You should be able to alt+shift or use the lang bar as usual.
Could you give me your exact Windows version by running winver (example: Version 6.1(Build 7600)).
Thanks.
My only guess is that you’re on 2000 or an older version of XP than I tested on.
Since there is no candidate window showing up, how do I select between
candidates?
JiangOn Wed, Jul 28, 2010 at 10:27 PM, dewyatt <Daniel.Wyatt at gmail.com> wrote:
I need anyone proficient with any IME that is willing/able to test my Windows input method support.
I especially need anyone familiar with Chinese or Korean IMEs.
I have tested Japanese myself but if you are willing to test it out some more, please do.
Here is the compiled testime:
Download
Let me know if you experience any problems.
I want to know if you think it is usable, unusable, buggy, etc.
Some things to note:
You will need the Visual C++ 2008 Redistributable Package from here.
It should work on XP, Vista, and 7. (Windows 2000 may or may not work right now).
The candidate list is not drawn right now (you can still use to go through candidates).
Reading strings (Chinese IMEs) are not drawn right now.
Try both windowed and fullscreen modes.
Use to exit
Use to clear text
Use to move cursor in composition string (but not in committed text)
All of the IME windows should be hidden in fullscreen mode (except language bar). Let me know if you see otherwise.
Hey Jiang.
I didn’t see your post before.
You can use to go through the candidates one by one (and accept one with ).
The problem is the OS can’t always draw the candidate list correctly in fullscreen mode (flickers in certain renderers).
We know this cuts down on usability a bit so Sam and I have discussed drawing a custom candidate list but it will take some time.
Update:
I uploaded the new testime (linked in top post).
Reading strings are now drawn in the composition.
So, for example, with the Changjie input method you can type OH and see ?? and hit to get e.
In OS X this seems to be how things are handled by default, the reading is handled just like the composition.
In Windows the reading is usually shown in a popup window but since we can’t let the IME render these things in fullscreen mode, we just add the reading to the composition at the cursor position.
Hey Jiang.
I didn’t see your post before.
You can use to go through the candidates one by one (and accept one with ).
There is something missing in the above sentence. What can I use to go
through the candidates and accept with?
The problem is the OS can’t always draw the candidate list correctly in fullscreen mode (flickers in certain renderers).
We know this cuts down on usability a bit so Sam and I have discussed drawing a custom candidate list but it will take some time.
I don’t use Windows very much, I suppose that’s how World of Warcraft
handle the candidate list?
Update:
I uploaded the new testime (linked in top post).
Reading strings are now drawn in the composition.
So, for example, with the Changjie input method you can type OH and see ?? and hit to get ?.
In OS X this seems to be how things are handled by default, the reading is handled just like the composition.
In Windows the reading is usually shown in a popup window but since we can’t let the IME render these things in fullscreen mode, we just add the reading to the composition at the cursor position.
JiangOn Thu, Aug 12, 2010 at 1:24 PM, dewyatt <Daniel.Wyatt at gmail.com> wrote:
There is something missing in the above sentence. What can I use to go
through the candidates and accept with?
Oh, it’s spacebar and enter, sorry about that.
Jjgod Jiang wrote:
I don’t use Windows very much, I suppose that’s how World of Warcraft
handle the candidate list?
I think Sam mentioned to me that they actually implemented a pseudo-fullscreen (maximized windowed mode) mode because one of the popular Chinese IMEs didn’t support custom application drawing.
I don’t know if it draws a custom candidate list with other IMEs, I haven’t played the game.
Nevermind, I take it back.
It seems the CHS IMEs (at least) are very different when it comes to this.
There is no good way to use them without a candidate list.
Here (http://www.sendspace.com/file/9ya2i7) is a version that allows the IME to draw the candidate list, etc:
It will even work in fullscreen with the default renderer.
That’s more usable but I will still likely have to draw a custom candidate list in the future.
I don’t have Windows box at hand so I will try it tomorrow.
However, I think rendering custom candidate list can be specific to
certain applications, you can consider adding a public API to SDL for
retrieving the candidate list, then let the apps to decide how they
are going to draw it. (For platforms that you can’t or don’t need to
get such candidate list like Mac OS X, simply return an empty or
invalid value)
Then you can make use of this API to draw candidate list in sample
program like testime.
JiangOn Thu, Aug 12, 2010 at 10:17 PM, dewyatt <Daniel.Wyatt at gmail.com> wrote:
Nevermind, I take it back.
It seems the CHS IMEs (at least) are very different when it comes to this.
There is no good way to use them without a candidate list.
Here is a version that allows the IME to draw the candidate list, etc:
It will even work in fullscreen with the default renderer.
That’s more usable but I will still likely have to draw a custom candidate list in the future.
I don’t have Windows box at hand so I will try it tomorrow.
However, I think rendering custom candidate list can be specific to
certain applications, you can consider adding a public API to SDL for
retrieving the candidate list, then let the apps to decide how they
are going to draw it. (For platforms that you can’t or don’t need to
get such candidate list like Mac OS X, simply return an empty or
invalid value)
Then you can make use of this API to draw candidate list in sample
program like testime.
That is pretty much what I suggested to Sam but he said:
"Having entirely opposite APIs on both platforms is something I’d like
to avoid if possible."
I can certainly understand what he means.
However, it would make sense to allow the app to draw the candidate list.
That way it could draw with whatever font/styling it wanted (and match the composition which it already draws).
In windowed mode, candidate list shows correctly in all three IMEs I tried.
So I guess what’s missing is the fullscreen mode support.
JiangOn Thu, Aug 12, 2010 at 10:50 PM, dewyatt <Daniel.Wyatt at gmail.com> wrote:
That is pretty much what I suggested to Sam but he said:
"Having entirely opposite APIs on both platforms is something I’d like
to avoid if possible."
I can certainly understand what he means.
However, it would make sense to allow the app to draw the candidate list.
That way it could draw with whatever font/styling it wanted (and match the composition which it already draws).
Yes, fullscreen mode is the whole problem.
Specifically I think the d3d renderer is the problem.
You can try:
set SDL_VIDEO_RENDERER=d3d
testime --fullscreen
And go through the candidate list to see what I mean.
In a program like testime that only redraws when necessary, it’s unusable.
In a program that redraws as much as possible, it will flicker constantly.
With the gdi renderer, it’s not a problem.
I even got it to work properly in the opengl renderer in my test code.
(I think the opengl renderer is broken in my repo so SDL_VIDEO_RENDERER=opengl will not work)
But I guess the d3d renderer does not want to cooperate with any GDI rendering.
It’s a shame to have to draw a custom candidate window because of one renderer but it seems necessary.
I’m running under Windows 10 and using SDL2 for general windowing/inputs but raw OpenGL for rendering, and I can’t find a way to get any IME to render under this setup (even in Windowed mode).
IME_Present() (which calls IME_Render()) is never called anywhere in the SDL codebase (checked 2.0.7, 2.0.8) I don’t quite understand how this can work at all. It is broken under Windows? Am I missing something?
void IME_Present(SDL_VideoData *videodata)
{
if (videodata->ime_dirty)
IME_Render(videodata);
/* FIXME: Need to show the IME bitmap */
}
But the code that disable the regular Windows IME runs so effectively as I understand it, any form of IME is totally broken under Windows (hope that I am wrong!). This is pretty severe.
For such a complex and tricky piece of code, I also find it surprising that there is seemingly no way to disable SDL IME implementation at runtime, shall the application decide they want to use the regular path or their own.
SDL_CreateWindow() + SDL_ShowWindow() leads to a WM_ACTIVATE message which lead to the message handler calling SDL_SetKeyboardFocus() which calls StartTextInput() which under Windows starts the SDL IME code.
The IME inputs are received by SDL_TEXTINPUT but no IME is visible, no candidate list is visible (neither the native Windows one, neither the one that seems implemented in IME_Render but never called anywhere).
Any ideas? If anyone successfully using SDL under Windows with a visible IME?
