The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi list,

I am trying to port my application from SDL to SDL2, and I got stuck on
one ugly detail. The application is controlled via the keyboard, mostly
using left/right/up/down keys, but it also allows the user to start
typing text right away (if the user presses 'LEFT' it's considered a
control action, while if he presses 'c' it starts typing a string on the
screen).

On SDL it was pretty easy, since I was receiving SDL_KEYDOWN events, and
I looked into event.key.keysym.sym for handled control keys, and if it
was something non-control, I was simply fetching the ascii/unicode
character from the event.key.keysym.unicode field.

The problem is that in SDL2 the whole event.key.keysym.unicode field
disappeared (more specifically - got replaced by an "uint32_t unused").

Now, using SDL2, how do I need to proceed to fetch ascii values from
SDL_KEYDOWN events? I already tried handling this myself with a huge
switch() statement that maps sym values into ascii values, but it means
I have to handle specifically every possible character, AND keep track
of caps lock/num lock/shift etc to issue correct codes. This seems
unrealistically convoluted to me, so I am pretty sure I must have missed
something obvious here... I shall add that I do know about the
SDL_TextInputEvent family, but unless I misunderstood it, this seem to
be designed for exclusive text input (while I need to be able to receive
KEYDOWN events all the time).

Any hints please?

cheers,
Mateusz

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is a difficult but necessary transition to make. The idea that each key represents an ascii value originates from 8-bit computing, so SDL2 finally let go of this.

Look at SDL_TEXTINPUT event, and event.text.text field. It will most of the time give one character, but may give more. Use this to build up the string that's typed to the screen and it should give what you're looking for?

This link explains this transition: https://wiki.libsdl.org/Tutorials/TextInput

You probably need to call SDL_StartTextInput() first, which brings up the on-screen keyboard on touch devices (Android, etc). I can't immediately think how you can receive input without the on screen keyboard, or if you can hide the keyboard or prevent it coming up, but hopefully this is a start in the right direction.

Hello AntTheAlchemist,

Thank you for pointing me back to the SDL_TEXTINPUT events family, this
was indeed where the solution was.

In fact, SDL_TEXTINPUT is the very first thing that I found while
searching for information about my problem, but the SDL manual left me
with the incorrect understanding that once I run SDL_StartTextInput(), I
will stop receiving SDL_KEYDOWN events, and SDL will switch into some
kind of 'text editor' mode.

This proves to be totally wrong - my error that I didn't tested it in
the first place.

Now I run SDL_StartTextInput() at the very begin of my program, and I
listen to both SDL_KEYDOWN and SDL_TEXTINPUT events, picking up
whichever suits me best for a given action.

Thanks!

Mateusz



On 25/07/2015 13:36, AntTheAlchemist wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2015-07-25 8:36 GMT-03:00, AntTheAlchemist:

Eh, actually not the real issue since SDL1 was handling Unicode. The
problem was more assuming that a keystroke would generate a single
character, when IMEs normally generate entire sentences at once - on
top of the fact that IMEs need to know where the text field is (to
show their interface), and you need to be able to display the
placeholder text while it's being entered.

Even then SDL2's method isn't perfect yet afaik. You can't type in Ж
properly, because it's typed as ZH but the Z already generates a
character, the H is supposed to replace it but SDL2 has no way to tell
this to the program (so you end up with both of them). No idea how to
fix this in a backwards compatible way, though (short of just assuming
old programs will ignore the flag and keep their current behavior).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 07/25/2015 05:21 PM, Sik the hedgehog wrote:

You don't even need IMEs to break that assumption, it already fails with
dead keys.

Cheers,
Daniel
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2015-07-25 12:34 GMT-03:00, Daniel Gibson:

Was gonna say that I never saw them generate multiple characters, but
then I remembered that when you enter an invalid combination, you just
get both characters separately. Whoops.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 07/25/2015 07:04 PM, Sik the hedgehog wrote:

Even for valid combinations, did it actually work like you'd expect
(like [`] and [e] generatinge keydown event without a unicode value and
one with the 'é' unicode value), or did you get the chars separately
anyway (e.g. '`' and 'e')?

Either "single keystroke == single character" was untrue because some
keystrokes don't generate a char at all (even it it wasn't arrow-keys
or other non-char-keys), or it was broken because you couldn't get
composed characters.
Both kinda sucks.

And yeah, for IME it's probably even worse and SDL2 textinput events are
a lot better :-)

Cheers,
Daniel
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2015-07-25 15:17 GMT-03:00, Daniel Gibson:

Last I checked you just got è (in fact, it's recommended to normalize
when possible). But now you got me wondering what does OSX do about
this (I know they use denormalized characters in filesystems, I guess
they probably do it everywhere else too).


Eh, if you didn't get a char because nothing was generated then it was
technically the correct thing after all, right?

In any case given the situation of IMEs and such it's pretty obvious
the old system wasn't good enough anyway (and not providing the
individual codepoints when possible is good because it discourages
programmers from trying to use that instead and not handling IME
input).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If someone has a demo app I can quickly compile, I can test Mac OSX Yosemite output for these events.

On Sat, Jul 25, 2015 at 5:15 PM, Sik the hedgehog wrote:

I’m trying to fix the bug that causes underlining not to work, but I get stuck on compiling SDL_TTF because the freetype framework won’t include :


ld: warning: ignoring file ~/SDL2.0/SDL_ttf/Xcode/Frameworks/FreeType.framework/FreeType, file was built for unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 ) which is not the architecture being linked (x86_64): ~/SDL2.0/SDL_ttf/Xcode/Frameworks/FreeType.framework/FreeType
Undefined symbols for architecture x86_64:

and then a bunch of functions can’t be linked of course

I tried changing the SDL_ttf framework build settings to 32 bit, but that won’t help. In fact i don’t WANT to change that since I need my app to be universal but I figured it was worth a try to isolate the issue

is there an xcode project somewhere for freetype ? I downloaded the sources from freetype.org but their makefiles are stil for MPW or codewarrior, both of which are long dead on mac


can anyone provide a working FreeType.framework that can be used in the latest XCode, or a compilable tarbal for freetype on osx ?

help would be much appreciated !
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 7/26/15, jeroen clarysse wrote:



I seem to get stuck building FreeType for Mac or iOS every few years
and reinventing the build system.

Here is one of my repos from a few years back:
https://www.assembla.com/spaces/freetype_ios_xcode/mercurial/source

I think I was working on this SDL_ttf at the same time:
https://www.assembla.com/spaces/sdl_ttf-ios-xcode/mercurial/source

-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

thanks !



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org