Messages

1

Window / Re: dead keys on Mac OS not working properly

« on: April 20, 2013, 01:49:53 pm »

Thanks a lot for your efforts!
And looking forward to the fix

2

Window / Re: dead keys on Mac OS not working properly

« on: April 19, 2013, 10:48:07 pm »

Dear Hiura,

thanks for picking up on this. Here is a minimal example:

#include <SFML/Window.hpp>
#include <unistd.h>

int main(int argc, char** argv) {
        sf::Window wnd(sf::VideoMode(800, 600), "test window");
        for (; ; usleep(10000)) {
                sf::Event event;
                while (wnd.pollEvent(event)) {
                        if (event.type == sf::Event::KeyPressed)
                                printf("[KeyPressed]  key code: %u\n", event.key.code);
                        else if (event.type == sf::Event::KeyReleased)
                                printf("[KeyReleased]  key code: %u\n", event.key.code);
                        else if (event.type == sf::Event::TextEntered)
                                printf("[TextEntered]  unicode: %u   character: '%c'\n", event.text.unicode, event.text.unicode);
                }
        }
}
 

and here the output when pressing first forward quote '´' and then 'e':

[KeyPressed]  key code: 55
[KeyReleased]  key code: 55
[KeyPressed]  key code: 4
[TextEntered]  unicode: 101   character: 'e'
[KeyReleased]  key code: 4
 

I'd rather expect the following:

[KeyPressed]  key code: 55
[KeyReleased]  key code: 55
[KeyPressed]  key code: 4
[TextEntered]  unicode: 233   character: 'é'
[KeyReleased]  key code: 4
 

I must correct my previous post; as a cheap workaround I had already added a selfmade text event replacement that gave me the forward quote. At the moment forward+backward quote ´ `, hat ^ and tilde ~ don't generate any text events, also not in conjunction with other keys (such as e, n, also space).

3

Window / dead keys on Mac OS not working properly

« on: April 15, 2013, 11:10:55 pm »

Dear developers,

I am using SFML 2.0 on Mac OS 10.6.8.

I am experiencing problems receiving text events for composed characters, such as French 'é'. Instead I get two separate text events '´' and 'e' (this is how I type é on my German Macbook keyboard). Am I right that the intent of SFML is to supply me with the single text event 'é' instead? If so then this is a bug, otherwise I'd be happy to learn that the observed behavior is intended.

I am not a COCOA expert, so I am kind-of searching in the dark, but the following thread seems relevant to my problem:

   http://stackoverflow.com/questions/8263618/convert-virtual-key-code-to-unicode-string

I have checked the code

   https://github.com/SFML/SFML/blob/master/src/SFML/Window/OSX/HIDInputManager.mm

based on the above thread, and indeed in lines 403-412 I find:
   error = UCKeyTranslate(m_layout,                    // current layout
      virtualCode,                 // our key
      kUCKeyActionDown,            // or kUCKeyActionUp ?
      0x100,                       // no modifiers
      LMGetKbdType(),              // keyboard's type
      kUCKeyTranslateNoDeadKeysBit,// some sort of option     <--- this could be the bad guy!?
      &deadKeyState,               // unused stuff
      maxStringLength,             // our memory limit
      &actualStringLength,         // length of what we get
      unicodeString);              // what we get

Could someone with more cocoa knowledge validate whether this is a bug in SFML?

Thanks a lot,
Tobias