Key composition

SDL Development
1

Greetings,

I am currently working on the widgets for my UI in my game, and I
came across a little problem.

On my macosx keyboard, if I do ^ and e I have ?. This is a normal
composition.

In sdl, I have no composition, if I press ^ I got keysym for ^ and no
unicode value, then if I press e, I have just e as unicode value
(when I want ?).

Under windows, composition is working, if I press ^ then e, I have ?
as unicode value.

I use sdl 1.2.11

Any idea? Hope I was clear in my explanation.

Regards–
Kuon

"Don’t press that button."
http://goyman.com/

2

I’ve had the same problem. As far as I know, there is no portable way
to use input composition. It’s far from ideal, but I’m just using a
table
with the Unicode combinations. The code is here:
http://dev.csoft.org/agar/trunk/gui/keycodes.c

This is what I was about to do, but I have a problem, on my keyboard,
if I press ^ I got ^ if I press ALT+^ I got ? (to compose ? ?..)
and SHIFT+^ I got ` for ? ?..

In SDL, I always get ^ no matter if I have ALT or SHIFT pressed.

So, I cannot implement a keymap independent composition, I would need
to test for modifier, this with a keymap, on swiss keyboard, ALT+^ do
? but on french keyboard, ALT+^ do ?. This is a problem.

RegardsOn 10 Jun 2007, at 5:38 PM, Wilbern Cobb wrote:

On Sun, Jun 10, 2007 at 04:48:19PM +0200, Kuon wrote:

–
Kuon

"Don’t press that button."
http://goyman.com/

3

After digging a little bit in the code of SDL, I think there is a
problem own the NSEvent is handled for the keyboard.

Usually, if you press Option-e on US keyboard, then e, you get ? in
the NSEvent. In SDL you get e, I think having ? is normal behavior,
so I don’t know why, maybe threads?

Perhaps the macosx maintainer can help me on this? Before I start
debugging code myself.

On windows 32, this is working as expected, I was unable to test on
linux.

Regards–
Kuon

"Don’t press that button."
http://goyman.com/

4

Can you provide a testcase? I could test on GNU/Linux, XOrg, german
keyboard/layout.

–Dennis
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070611/d8ee70d0/attachment.pgpAm Montag, 11. Juni 2007 schrieb Kuon:

After digging a little bit in the code of SDL, I think there is a
problem own the NSEvent is handled for the keyboard.

Usually, if you press Option-e on US keyboard, then e, you get ? in
the NSEvent. In SDL you get e, I think having ? is normal behavior,
so I don’t know why, maybe threads?

Perhaps the macosx maintainer can help me on this? Before I start
debugging code myself.

On windows 32, this is working as expected, I was unable to test on
linux.

5

Perhaps the macosx maintainer can help me on this? Before I start
debugging code myself.

Go ahead and dig into it and let us know what you find. I don’t think
anyone working on Mac OS X has international input set up.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

6

Perhaps the macosx maintainer can help me on this? Before I start
debugging code myself.

Go ahead and dig into it and let us know what you find. I don’t think
anyone working on Mac OS X has international input set up.

Ok, I dug into it, and I found a mermaid, and… no, not the right
story.

So, I found out that you need to process the event into NSText to
have correct key composition.

It is now working correctly with this patch:

1.2.11 (patched on website distrib)

SDL_QuartzEvents.m

around line 255, add 4 lines

static void QZ_DoKey (_THIS, int state, NSEvent *event) {

 NSString *chars;
 unsigned int numChars;
 SDL_keysym key;

  if(state == SDL_PRESSED) {
          NSText *fieldEditor = [qz_window fieldEditor:YES

forObject:nil];

          [fieldEditor interpretKeyEvents:[NSArray

arrayWithObject:event]];

  }

I would appreciate comments from cocoa programmer out here, I’m not
experienced enough with cocoa to know if this is the right thing to
do (but, again, it is working). I read the doc and the NSText is only
instanced once, overhead should be minimal.

Calling [event characters] after NSText interpreted the event will
result in a correct composed character. Only the keyDown
(SDL_PRESSED) event should be processed, because the keyUp event
would reset the composition.

I looked at the source for 1.3, and I think the same patch can be
applied (at least, the same technique), except for the window
(qz_window), as 1.3 has multiple windows support.

Best regardsOn 13 Jun 2007, at 8:49 AM, Sam Lantinga wrote:

–
Kuon

"Don’t press that button."
http://goyman.com/

7

I forgot to wrap the code in SDL_TranslateUNICODE, this is the
correct version.

if (SDL_TranslateUNICODE) {
chars = [ event characters ];
numChars = [ chars length ];

if(state == SDL_PRESSED) {
NSText *fieldEditor = [qz_window fieldEditor:YES forObject:nil];
[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
}
} else {
numChars = 0;
}

Regards–
Kuon

"Don’t press that button."
http://goyman.com/

8

I really have to be tired or something, I posted the wrong code
again, this should be correct

if (SDL_TranslateUNICODE) {
if(state == SDL_PRESSED) {
NSText *fieldEditor = [qz_window fieldEditor:YES forObject:nil];
[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
}

chars = [ event characters ];
numChars = [ chars length ];
} else {
numChars = 0;
}

Regards, sorry for mailing list pollution–
Kuon

"Don’t press that button."
http://goyman.com/

9

To have correct composition with international keyboard, the
following patch should be applied:

for SDL 1.2.11

in
SDL_QuartzEvents.m

at
static void QZ_DoKey (_THIS, int state, NSEvent *event) {######

if (SDL_TranslateUNICODE) {

if(state == SDL_PRESSED) {
NSText *fieldEditor = [qz_window fieldEditor:YES forObject:nil];
[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
}

chars = [ event characters ];
numChars = [ chars length ];

} else {
numChars = 0;
}

After some tests, this patch does not seems to cause any problem at
all. I only tested on 1.2.11

In SDL 1.3, I can’t find the right way to get the current NSWindow,
it’s the only thing I miss to make the patch.

I need to access the current NSWindow in

SDL_cocoakeyboard.m

in function

void
Cocoa_HandleKeyEvent(_THIS, NSEvent *event)

Best regards

–
Kuon

"Don’t press that button."
http://goyman.com/

10

To have correct composition with international keyboard, the
following patch should be applied:

I tried this patch and tried option-e e and got the following:
Key pressed: 308-left alt modifiers: LALT
Key pressed: 101-e modifiers: LALT
Key released: 308-left alt modifiers: (none)
Key released: 101-e (?) modifiers: (none)
Key pressed: 101-e (?) modifiers: (none)
Key released: 101-e (e) modifiers: (none)

In TextEdit it composes an accented e. Is there something more we should be doing?

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

11

In SDL 1.3, I can’t find the right way to get the current NSWindow,
it’s the only thing I miss to make the patch.

I tried using [event window], but that didn’t seem to work…

Also in 1.3 the key repeat rate of the SDL application is very high
for some reason. Does NSWindow filter some of them based on the keyboard
repeat rate preferences?

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

12

To have correct composition with international keyboard, the
following patch should be applied:

I tried this patch and tried option-e e and got the following:
Key pressed: 308-left alt modifiers: LALT
Key pressed: 101-e modifiers: LALT
Key released: 308-left alt modifiers: (none)
Key released: 101-e (?) modifiers: (none)
Key pressed: 101-e (?) modifiers: (none)
Key released: 101-e (e) modifiers: (none)

In TextEdit it composes an accented e. Is there something more we
should be doing?

Did you add SDL_putenv(“SDL_ENABLEAPPEVENTS=1”); ?

This is needed for the input server to grab the events and build the
composed char.

Also in 1.3, I noticed super high key repeat, I did not look into it.

RegardsOn 16 Jun 2007, at 6:14 AM, Sam Lantinga wrote:

–
Kuon

"Don’t press that button."
http://goyman.com/

13

To have correct composition with international keyboard, the
following patch should be applied:

I got:

Keysym: 308, Scancode: 0, Unicode: 0
Keysym: 101, Scancode: 14, Unicode: 0
Keysym: 101, Scancode: 14, Unicode: 233

With:
while(!done) {

/* Check for events */
while(SDL_PollEvent(&event)) {
	switch (event.type) {
		case SDL_KEYDOWN:
			printf("Keysym: %d, Scancode: %d, Unicode: %d\n",

event.key.keysym.sym, event.key.keysym.scancode,
event.key.keysym.unicode);
break;
}
}
}

And I pressed Option-e e with US keyboard layout.

That way, I have ? as unicode value (of course, unicode should be
enabled with SDL_EnableUNICODE(1);).

Also, about what I said for SDL_putenv(“SDL_ENABLEAPPEVENTS=1”);,
this is not needed, it’s only needed to have Command-q or think like
that to be forwarded to the NSApp. It works without it, but I thought
that was the problem because I tried without and it did not work, but
for some reason, I changed my keyboard layout to something else and
did not notice immediately.

For the high repeat rate in 1.3, I will have a look.

RegardsOn 16 Jun 2007, at 6:14 AM, Sam Lantinga wrote:

–
Kuon

"Don’t press that button."
http://goyman.com/

14

Also in 1.3 the key repeat rate of the SDL application is very high
for some reason. Does NSWindow filter some of them based on the
keyboard
repeat rate preferences?

About this, I found the problem, line 668 of SDL_keyboard.c should be

keyboard->repeat.timestamp = timestamp;

instead of
keyboard->repeat.timestamp = 1;

And [event window] works:

 case NSKeyDown:
     if ([event isARepeat]) {
         break;
     }
     SDL_SendKeyboardKey(data->keyboard, SDL_PRESSED, (Uint8)

scancode,
data->keymap[scancode]);

	NSText *fieldEditor = [[event window] fieldEditor:YES  forObject:nil];
	[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
     text = [[event characters] UTF8String];
	
     if(text && *text) {
         SDL_SendKeyboardText(data->keyboard, text);
     }
     break;

This is working for me.

RegardsOn 16 Jun 2007, at 6:51 AM, Sam Lantinga wrote:

Kuon

"Don’t press that button."
http://goyman.com/

15

For 1.2.11 the following:

 if (SDL_TranslateUNICODE) {
	if(state == SDL_PRESSED) {
		NSRect r;
		NSText *fieldEditor = [[NSTextView alloc] initWithFrame:r];
		[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
	}
     chars = [ event characters ];
     numChars = [ chars length ];
 } else {
     numChars = 0;
 }

is window independent (eg, works in full screen, I noticed the other
did not), the fieldEditor don’t need to be instanced at each key
press, it should be cached somewhere.

Regards–
Kuon

"Don’t press that button."
http://goyman.com/

16

Also in 1.3 the key repeat rate of the SDL application is very high
for some reason. Does NSWindow filter some of them based on the
keyboard
repeat rate preferences?

About this, I found the problem, line 668 of SDL_keyboard.c should be

keyboard->repeat.timestamp = timestamp;

Of course! Thanks! Ryan and I had just been talking about how to handle
keyboard repeat, and I had forgotten that there was still some 1.2 code in
there. :slight_smile:

-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment> On 16 Jun 2007, at 6:51 AM, Sam Lantinga wrote:
17

For 1.2.11 the following:

 if (SDL_TranslateUNICODE) {
  if(state == SDL_PRESSED) {
  	NSRect r;
  	NSText *fieldEditor = [[NSTextView alloc] initWithFrame:r];
  	[fieldEditor interpretKeyEvents:[NSArray arrayWithObject:event]];
  }
     chars = [ event characters ];
     numChars = [ chars length ];
 } else {
     numChars = 0;
 }

is window independent (eg, works in full screen, I noticed the other
did not), the fieldEditor don’t need to be instanced at each key
press, it should be cached somewhere.

Thanks! I’ll work something like this into 2.1.12.

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

18

Thanks! I’ll work something like this into 2.1.12.

Just thought about it, it would be cleaner to initialize the NSRect,
with

NSRect r = NSMakeRect(0.0, 0.0, 0.0, 0.0);

RegardsOn 16 Jun 2007, at 5:01 PM, Sam Lantinga wrote:

–
Kuon

"Don’t press that button."
http://goyman.com/