Re: [AD] Allegro 4.2 planning |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Allegro 4.2 planning
- From: Elias Pschernig <allefant@xxxxxxxxxx>
- Date: Mon, 18 Oct 2004 22:55:45 +0200
- Domainkey-signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=D0Oh5kFCe2RhIQ8BUfRCZwlmNzqDdDIOcovpJ6fuCwizAEzfCffYFdkMoWu+BMV5XJC6NBuEmCH5OwhSpw5iG4egjyf/s2y+LPYw2eAlQr0kS3m9B0zg3OUNX3AcgoDaYBxBx2gDoBfDthjXMMNsys0KMNxy358A8vB1kLpvB0s
>
> Ok, I understand the problem now. Do you know how SDL handles the same
> issue? Or have they just side-stepped it?
>
Well, the first problem they handle by simply not using positional
keys in X11. SDLK_a means, the key with "A" printed was pressed, no
matter where it was.
The issue of getting the proper unicode isn't really working in SDL as
well, that's the code I found:
" /* If UNICODE is on, get the UNICODE value for the key */
keysym->unicode = 0;
if ( SDL_TranslateUNICODE && xkey ) {
static XComposeStatus state;
/* Until we handle the IM protocol, use XLookupString() */
unsigned char keybuf[32];
[...]
/* Look up the translated value for the key event */
if ( XLookupString(xkey, (char *)keybuf, sizeof(keybuf),
NULL, &state) ) {
/*
* FIXME,: XLookupString() may yield more than one
* character, so we need a mechanism to allow for
* this (perhaps generate null keypress events with
* a unicode value)
*/
keysym->unicode = keybuf[0];
}
}"
So, according to that first comment, they also plan on using IM. And
then, they simply use XLookupString, which only returns Latin1:
http://xfree86.org/4.4.0/XLookupString.3.html
So, the only way seems to be using XIM, which adds this:
http://xfree86.org/4.4.0/Xutf8LookupString.3.html
Just what would be ideal for Allegro - simply get the UTF8 for they
keysym directly from X11.
>
> > Probably could add it also for X11, along with some heuristic [xkeymap]
> > sections for every language, as was discussed here a while back.
>
> Sounds good! :)
I'll look into this. It's simpler than trying to change the complete
locking mechanism.. I have a modified version of Allegro here which
creates two displays, but when running, it simply locks up :P Probably
would just need some debugging. Another possibility mentioend by Peter
would be to use only one display, but replace the XLock calls by
pthread locks. I think I actually might try this first in case it's
simple. If it doesn't work out, I'll look into a simple way to detect
the keyboard likely being used (like that code does for Windows), and
just include my German [xkeymap] somehow, as well as the French one
sent by someone some time ago. Then we could ask people using X11 with
other keyboards to send [xkeymap] mappings for the other languages
recognized by Allegro currently. Would still be not perfect, since
even my own [xkeymap] mapping needed to be changed when switch X11
versions. The same key simply started producing another KeySym - I
think it was the AltGr key.
[..]
>
> Well, my idea was to merge the new_api_branch with 4.2, clean up a bit,
> then release a first WIP - based on the assumption that it's in proper
> working order right now. If it isn't though, well, there's no rush really.
>
Yes. Actually, I confused 4.3.0 with 4.4.0. So after 4.2 is out, we
definitely should make new_api_branch the new WIP (4.3.0) ASAP :)