view CREDITS @ 4384:6800e2560310 SDL-1.2

Fixed bugs #882 and 865, re-opening bug #634 Ronald Lamprecht to SDL Hi, Sam Lantinga wrote: The problem with that fix is that it breaks IME events again. Maybe we can handle keyboard events differently to prevent this issue? Spending an hour reading MSDN, analysing SDL and another hour testing the reality on XP I am really wondering how patch r4990 could have ever worked in any situation. It's main effect is to break the unicode translation and causing spurious activation events! Why does TranslateMessage(&msg) nothing useful? Simply because it does not affect "msg" at all! All keyboard events are dispatched without the slightest change (see MSDN). TranslateMessage() just appends additional WM_CHAR, WM_DEADCHAR, WM_SYSCHAR, WM_SYSDEADCHAR event messages to the queue. But I could not find any SDL event handling routine that catches these events and transforms them to proper SDL keyevents while eliminating the corresponding WM_KEYDOWN, etc. events. Thus any IME input like the '@' generated by "Alt + 6(Numpad) + 4(Numpad)" is simply lost. But the situation is even worse! Up to r4990 the TranslateKey()/ToUnicode() calls did evaluate dead keys and did deliver proper key events for subsequent key strokes like '´' + 'e' resulting in 'é'. ToUnicode() needs proper key state informations to be able to handle these substitutions. But unfortunatly TranslateMessage() needs the same state information and eats it up while generating the WM_CHAR messages :-( Thus the current 1.2.14 breakes the partial IME support of previous releases, too. The key state race condition between ToUnicode() and TranslateMessage() requires to avoid any ToUnicode() usage for receiving proper WM_CHAR, etc. messages generated by TranslateMessage(). (Yes - the '@' and 'é' appear as WM_CHAR messages when unicode is switched off). The spurious SDL activation events are *not* caused by additional WM_ACTIVATE Windows messages! Besides DIB_HandleMessage() SDL_PrivateAppActive() is called by another source which I am not yet aware of - any hints? Thus I do strongly recommend the deletion of the TranslateMessage(&msg) call as a quick fix. A proper support of unicode and IME requires a clean SDL keyboard input concept first. Which SDL keyboards events should be transmitted to the app when the user presses '´' + 'e' ? Within the current unicode handling the first key stroke is hidden. Even though ToUnicode() delivers the proper key SDL does ignore it in TranslateKey(). Just the composed key event is transmitted to the app. That is what you expect for text input, but the app can no longer use keys like '^' as a key button because it will never receive a key event for it! With a given concept it seems to be necessary to regenerate SDL key events out of the WM_CHAR, etc. events and to drop all related direct WM_KEYDOWN, etc. events while the remaining basic WM_KEYDOWN, etc. events would still have to result in SDL key events. Anyway the source of the spurious WM_ACTIVATE should be located to avoid future trouble. Greets, Ronald
author Sam Lantinga <slouken@libsdl.org>
date Tue, 17 Nov 2009 04:59:13 +0000
parents 72a00fe65ffe
children
line wrap: on
line source


Simple DirectMedia Layer CREDITS
Thanks to everyone who made this possible, including:

* Cliff Matthews, for giving me a reason to start this project. :)
 -- Executor rocks!  *grin*

* Scott Call, for making a home for SDL on the 'Net... Thanks! :)

* The Linux Fund, C Magazine, Educational Technology Resources Inc.,
  Gareth Noyce, Jesse Pavel, Keith Kitchin, Jeremy Horvath, Thomas Nicholson,
  Hans-Peter Gygax, the Eternal Lands Development Team, Lars Brubaker,
  and Phoenix Kokido for financial contributions

* Gaëtan de Menten for writing the PHP and SQL behind the SDL website

* Tim Jones for the new look of the SDL website

* Marco Kraus for setting up SDL merchandise

* Martin Donlon for his work on the SDL Documentation Project

* Ryan Gordon for helping everybody out and keeping the dream alive. :)

* IBM R&D Lab for their PS3 SPE video acceleration code

* Mattias Engdegård, for help with the Solaris port and lots of other help

* Max Watson, Matt Slot, and Kyle for help with the MacOS Classic port

* Stan Shebs, for the initial Mac OS X port

* Eric Wing, Max Horn, and Darrell Walisser for unflagging work on the Mac OS X port

* Patrick Trainor, Jim Boucher, and Mike Gorchak for the QNX Neutrino port

* Carsten Griwodz for the AIX port

* Gabriele Greco, for the Amiga port

* Patrice Mandin, for the Atari port

* Hannu Viitala for the EPOC port

* Marcus Mertama for the S60 port.

* Peter Valchev for nagging me about the OpenBSD port until I got it right. :)

* Kent B Mein, for a place to do the IRIX port

* Ash, for a place to do the OSF/1 Alpha port

* David Sowsy, for help with the BeOS port

* Eugenia Loli, for endless work on porting SDL games to BeOS

* Jon Taylor for the GGI front-end

* Paulus Esterhazy, for the Visual C++ testing and libraries

* Brenda Tantzen, for Metrowerks CodeWarrior on MacOS

* Chris Nentwich, for the Hermes assembly blitters

* Michael Vance and Jim Kutter for the X11 OpenGL support

* Stephane Peter, for the AAlib front-end and multi-threaded timer idea.

* Jon Atkins for SDL_image, SDL_mixer and SDL_net documentation

* Peter Wiklund, for the 1998 winning SDL logo,
  and Arto Hamara, Steven Wong, and Kent Mein for other logo entries.

* Arne Claus, for the 2004 winning SDL logo,
  and Shandy Brown, Jac, Alex Lyman, Mikkel Gjoel, #Guy, Jonas Hartmann,
  Daniel Liljeberg,  Ronald Sowa, DocD, Pekka Jaervinen, Patrick Avella,
  Erkki Kontilla, Levon Gavalian, Hal Emerich, David Wiktorsson,
  S. Schury and F. Hufsky, Ciska de Ruyver, Shredweat, Tyler Montbriand,
  Martin Andersson, Merlyn Wysard, Fernando Ibanez, David Miller,
  Andre Bommele, lovesby.com, Francisco Camenforte Torres, and David Igreja
  for other logo entries.

* Bob Pendleton and David Olofson for being long time contributors to
  the SDL mailing list.

* Everybody at Loki Software, Inc. for their great contributions!

 And a big hand to everyone else who gave me appreciation, advice,
 and suggestions, especially the good folks on the SDL mailing list.

THANKS! :)

  -- Sam Lantinga			<slouken@libsdl.org>