This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_windowevents.c patch to fix dead keys (dead-keys-fix.patch, text/plain, 2015-01-06 00:32:50 +0000, 1466 bytes)

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

Comments on the original bug report:

On 2015-01-06 00:32:50 +0000, Elisée Maurer wrote:

Created attachment 1984
SDL_windowevents.c patch to fix dead keys

When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.

Using a French AZERTY keyboard, when I type the ^ key followed by e key to compose the ê character, I erroneously get two SDL_TEXTINPUT events, one with the ^ character and one with the e character.

I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:

• r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.

• But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).

• It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.

The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.

On 2015-02-10 09:50:10 +0000, wrote:

*** Bug 2747 has been marked as a duplicate of this bug. ***

On 2015-02-17 22:55:59 +0000, wrote:

Comment on attachment 1984
SDL_windowevents.c patch to fix dead keys

Shouldn't the conversion of the wParam in WM_CHAR be optional?

On 2015-02-19 11:44:37 +0000, Elisée Maurer wrote:

Optional? Based on what?

On 2015-02-19 14:13:13 +0000, wrote:

Well, for example the original jedi knight games pre-SDL used the raw wParam directly so that it could support other languages (Not full unicode) down the line. And I'm not sure if translating them to utf8 here will break that or not.

https://github.com/JACoders/OpenJK/blob/master/codemp/win32/win_wndproc.cpp#L470

On 2015-02-21 13:59:23 +0000, Elisée Maurer wrote:

Would any games developed with SDL2 still want to do anything other than Unicode these days? Maybe I didn't understand what you're suggesting.

On 2015-02-21 14:32:55 +0000, wrote:

Of course there are, think of the many old games or source ports that use SDL. They would still be using char not wchar_t for compatibility.

On 2015-02-21 16:43:44 +0000, wrote:

Maybe it will still work, I'm not sure. Just trying to keep the old compat with languages that the original JKA does support when this does get fixed in SDL2.

On 2015-02-21 18:45:09 +0000, Elisée Maurer wrote:

Can you build SDL2 with the patch and try it with one of the games you think might break and report?

Or are you concerned about possible future SDL2 ports? If that's the case, then IMHO it's best to worry about that when those ports do happen. The porter can ship their own build of the library (like I'm doing until this patch lands) and submit another patch to make the conversion optional if it is indeed required, right? It'd be premature to add some kind of way to switch now if there's no confirmed use case.

On 2015-02-22 03:26:35 +0000, wrote:

Unfortunately I will not be able to do so, going to be on vacation for next couple of weeks. (I imagine this might be resolved by then?) Even so, I don't actually have hg, so unless there's a git mirror of the most up to date main repo I probably wouldn't even be able to do so anyway.

Also, I am a US Keyboard user so I wouldn't be able to exactly test the Russian layouts etc other than windows-1252 alt codes.

On 2015-03-11 14:45:40 +0000, wrote:

This does work in terms of fixing alt codes on Windows.

Needs slight modification with recent patch to check return value of the convert function.

I had someone say they still cannot input russian with it though. (We convert back to utf32 same as ioquake3)

On 2015-04-07 04:57:58 +0000, Ryan C. Gordon wrote:

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

On 2015-05-28 16:04:33 +0000, Sam Lantinga wrote:

Unicode text support has been fixed/broken so many times... This patch is how the code used to work, but there were bugs that caused us to change it to the current code.

After 2.0.4 is released, let's hammer this out once and for all. We'll reopen all the Unicode text entry bugs, get everyone involved who can test it, and let them duke it out. :)

On 2015-06-25 18:58:48 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL/rev/02273530b7bf

We tested Russian on Windows 7 and it worked here.

We'll have to come back to bug 1876 with Khmer in the future.