Hi Laura, For Win32a, I added the options of 64-bit chtypes, allowing 21 bits for the character, which covers all of Unicode. (As well as providing the additional bits needed to support attributes such as A_DIM, A_ITALIC, A_OVERLINE, etc. that don't fit in 32-bit chtypes.) I think if you borrowed curses.h, you'd have a decent start on getting full Unicode in your SDL2 version.
Win32a also allows for entry of hex or decimal Unicode via the keypad (though this was only posted about five days ago!), but borrowing from Win32a might be a little more difficult here. Still probably worth checking, though. BTW, I have to agree with you on Wine overhead. Wine is a lovely solution, in the sense that it's enabled me to take a lot of my old Windows code and, with only minor tweaks, get it to run at full speed flawlessly in Linux. But it's a bit large. Understandably so, given what it has to do, but I'm still hoping this SDL2 solution pans out. -- Bill On 01/27/2015 07:23 AM, LM wrote:
I compared the demos using SDL1 and SDL2 with SDL2_TTF support. Results are very similar. Ran the clipboard test in testcurs and it works very nicely with SDL2 clipboard support. The biggest design issue I see is Unicode support. Looking through the code, chtype is set by default to handle 16 bits for the attributes and 16 bits for the character. On Windows systems, wchar_t is also limited to 16 bits. The testcurs ACS test shows some internationalized characters when PDC_WIDE is set true. However, I don't see any code to handle anything beyond the first 16 bits of a Unicode character set. So, for full Unicode support, one would at least need to modify the size of chtype and deal with wchar_t representing UCS-2, UTF-16 or UTF-32, etc. depending on the platform. Also, on Windows (Win32), one can input non-standard characters via the keyboard using Alt and the keypad keys. It would be nice to have a similar mechanism that works with SDL. It's difficult to determine when a user hits Alt and 0 on the keypad whether they want back the keypad character on the key down event or whether they want what the next series of key-presses converts to in a Unicode representation. That makes it difficult to code a solution to inputting Unicode characters that suits every case. Sincerely, Laura
